А что плохого по вашему в бесплатной CMS? Платная, а кстати какая, чем-то лучше будет? =)
При большой нагрузке напильник нужен будет для любой....
По сути вопроса:
Джумлу бы я не рассматривал бы - будут проблемы и при разработке, и большие проблемы при поддержке...
На Drupal делают высоко нагруженные проекты, есть даже соответствующий usergroup на drupal.org.
Но раз вы уж думаете о такой посещаемости, вполне возможно, разумнее будет писать сервис под конкретную задачу на каком-нибудь фреймворке. И заложить хорошие возможности масштабирования, которых в CMS общего назначения в общем-то нет...
CentOS вполне хороший выбор, ещё можно было бы рассмотреть Debian.
Из BSD в принципе можно использовать FreeBSD, но зачем?
Поясню немного почему "сама идея - жесть"... =)
Большинство пользователей имеет динамические ip которых при этом у каждого провайдера для этой цели не так много используется, т.е. во-первых, ip пользователя со временем меняется, во-вторых совершенно другой пользователь того же провайдера с немалой вероятностью имеет тот же ip.
Т.е. способ идентификации пользователя по ip адресу катастрофически не надёжен - толку в такой проверке нет, и она только создаст лишние проблемы.
ModX это конечно CMF, если говорить о Revo - внутри довольно развитый фреймворк xPDO, в принципе, можно сделать довольно сложное приложение, но есть много проблем:
-Фреймворк весьма неудобный, и не слишком функциональный, если сравнивать с любым популярным php фреймворком, типа СI, Yii, Kohana, Symfony.
-Большинство расширений, прямо скажем, не блещет качеством реализации, что не удивительно - профессиональный разработчик выберет что-нибудь более удобное...
-Документация довольно слабая, если рассматривать с точки зрения разработки чего-то сложного, особенно на основе того же xPDO.
-Комюнити небольшое, и не слишком профессиональное, толкового ответа на более-менее сложный вопрос можно не дождаться... Например, мне пришлось перелопатить массу кода, чтобы разобраться с некоторыми тонкостями работы кеширования.
-Сейчас можно хранить код снаружи, и для этого даже не обязательно писать расширения, но изначально предполагается хранение большей части кода в БД, что является ОЧЕНЬ плохой практикой.
-Структура шаблонов/снипетов/чанков это ад. Сразу видно, что создатель изначально дизайнер, а не программист. Для быстрого прототипирования и натягивания дизайна удобно, в продакшене - тихий ужас.
Мои соображения по поводу выбора:
Если разрабатывать сайт самому, то не стоит использовать ModX, если сайт не совсем элементарный, но и в этом случае стоит подумать о выборе другого инструмента...
Evo довольно убог, Revo не слишком хорошо документирован, довольно неудобный фреймворк в основе, не слишком качественные расширения в массе.
Если заказывать сайт, то тоже вряд-ли стоит:
ModX не самый популярный движок, соответственно, разработчиков не так уж и много, сменить в случае чего будет не так просто. Разобраться новому разработчику в мешанине шаблонов/чанков/снипетов/TV будет непросто.
Плохо с поддерживаемостью - всё в куче, код в шаблонах.
Профессиональные разработчики, скорее всего, выберут что-нибудь более удобное. И, соотвественно, сайт будет, с немалой долей вероятности, не тем, что вам нужно, или не совсем тем, или не так быстро и просто... =)
Если делать что-то сложное, где ModX использовался бы как CMF, лучше выбрать, например, Drupal, или даже какой-нибудь фреймворк в зависимости от того, насколько нестандартна задача и насколько важно потребление ресурсов.
Если что-то очень простое, то в принципе можно делать на любой популярной CMS, и ModX тут опять же возможный, но не лучший кандидат.
Копировать в один файл, выбрать дописать в конец(append). У большинства таких программ есть такая опция.
Можно в командной строке(cmd):
copy /b file1+file2+...+fileN target_file
И, на всякий случай, если файлов более 2х, в вашем случае, раздел должен быть не fat32, из-за лимита на размер файла.
Batch API вам в помощь...
Также, как prefork, основное отличие ITK в смене пользователя, после разбора запроса.
Процесс не порождается на каждый запрос а живёт определённое конфигурацией количество запросов... Это время кеш актуален.
Вы пририсовали очень много лишних нулей. На разбор php скрипта необходимы ресурсы процессора. А на его считывание ещё и неспешный дисковый ввод/вывод - без кешера он не будет гарантированно лежать в кеше файловой системы, к тому же обработанный скрипт куда компактнее. Всё это не только занимает определённое время, но и кушает ресурсы, которые могли бы быть потрачены на обработку запросов mysql. И в условиях наличия конкурентных запросов это вполне себе заметно.
Кеширование же данных на уровне приложения или веб сервера это уже совсем другое дело. Одно другого не заменит. Кстати, APC умеет и данные пользовательские кешировать, и работает в этой ипостаси быстрее того же memcached...
Кто вам такую глупость сказал?
Кеширование опкода заметно прибавляет производительность. На скриптах без сложных запросов к БД, файлового ввода/вывода, интенсивных вычислений разница может быть даже на порядок. И в любом случае она будет.
В этом случае будет один общий кеш.
Будет отдельный кеш у каждого процесса php.
Это конечно бОльшие накладные расходы, но всё равно может быть полезно, при разумном размере кеша конечно.
Есть ещё модуль mod_fastcgi, который порождает один или более процессов php(maxClassProcesses за это отвечает), и его дочерние процессы в нужном количестве(PHP_FCGI_CHILDREN). Вот тут у всех дочерних процессов будет общий кеш, и количество отдельных кешей будет задано количеством мастер процессов(например по одному на сайт или пользователя), и если всё правильно настроить не будет оверхеда по потреблению памяти, просто вместо одного общего кеша будет несколько отдельных такого же суммарного размера.
Ещё есть php-fpm, который нынче официальный fastcgi менеджер php. И там тоже проблемы с кешерами опкода нет.
Собственно именно его и надо бы использовать - он наиболее функционален... Для работы с ним Apache нужен будет proxy_fcgi_module.
Кстати, apache + mod_php, при прочих равных, несколько более производительное решение - там нет необходимости во взаимодействии по fastcgi, и соответственно немного меньше оверхед. И если нет необходимости разделения прав, то это наилучший вариант если смотреть с точки зрения времени выполнения скриптов.
if(soundManager.canPlayLink('/sites/all/modules/rmodule/audio/Zwitter.mp3')){ alert("да"); }else alert("нет");
А вы научитесь отлаживать Javascript, и не будут возникать такие вопросы. =)
Если зайти к вам на сайт, и заглянуть в консоль, можно увидеть вот такую ошибку:
Uncaught Error: soundManager: Fatal: JavaScript file build "V2.97a.20120318" does not match Flash SWF build "V2.97a.20121104" at http://trucontent.org/sites/all/modules/rmodule/player/soundmanager2.swf. Ensure both are up-to-date.
Думаю, это поможет вам решить проблему. Ну и конечно дело-то тут не в Drupal. =)
Если имеется в виду вёрстка шаблона, то из большой картинки можно сделать маленькую в процентах, передав пользователю заведомо большую и свойствами css задав ей размер на стороне пользователя, и собственно к Drupal это отношения имеет мало...
А вот отмасштабировать миниатюру генерируемую на стороне сервера в процентах естественно нельзя - нет привязки (от чего проценты-то брать?) и возможности перегружать и нарезать картинку при изменении размеров окна, например...
