Я бы сделал такой проект на Drupal, тем более что реализуется без каких-либо проблем и кастомных модулей...
Довольно часто, решить проблему железом дешевле, даже на длительной перспективе, чем производить оптимизацию приложения. В вашем случае, неплохо было бы сделать профилирование, найти узкое место и там уже решать, насколько трудоёмким будет процесс оптимизации.
Отпишитесь в личку или в скайп, расскажете подробнее о том, как сконфигурирован сейчас VPS, и что происходит в момент загрузки страницы второго сайта с нагрузкой - возможно смогу дать вам несколько полезных советов.
Это совершенно не так. Наличие шаблонизатора !== MVC
Минусы
Цена совершенно неадекватная качеству - код хуже я видел только на разных самодельных велосипедах.
Разработка от которой хочется плеваться, поработав с любой другой распространённой CMS и сравнив.
Битрикс - высоконагруженное??? =)))) На ферме серверов, вместо одного на нормальном движке? Жутко прожорливый и криво написанный движок.
Распостранён только у нас, и настолько широко только из-за хорошего маркетинга.
Плюсы
Проще продать решение клиенту, т.к. разрекламирован по самое немогу.
Документация на русском (хотя довольно спорное достоинство для разработчика умеющего более чем потыкать мышкой в админке).
В общем прежде чем выбрать битрикс надо хорошенько подумать и посмотреть на него поближе.
По поводу выбора:
Если именно ОOP подход и MVC, то посмотрите сайты различных фреймворков, везде есть CMS на их основе, разной степени готовности и навороченности, а вообще, часто имеет смысл просто использовать фреймворк и свои/чужие наработки на нём.
Drupal весьма гибкий, OOP применяется мало. Чёткого разделения MVC нет. Концептуально отличается весьма принципиально от OpenCart. Но как универсальное решение очень хорош. Хотя на простеньких сайтах, возможно, имеет смысл выбирать что-то более лёгкое.
Livestret это довольно специфичное решение, для всего чего угодно подходит даже меньше чем Wordpress не для блога.
-Невозможность апгрейда, что в условиях офиса не такая принципиальная проблема.
-Невозможность замены отдельных узлов. При нормальной гарантии и нормальной постановке работы(иметь минимальный запас), это опять же не проблема.
Работают в среднем не хуже ноутов той же марки, средней ценовой категории. При выборе конкретной модели, конечно, стоит отзывы почитать, т.к. всякое бывает.
Пользуются этим как самым простым, доступным и дешёвым методом, понимая его проблемы.
Что там поставить, зависит от количества памяти, которые вы планируете отдать apache и объёма памяти на процесс apache. Какой-то определённой цифры на все случаи жизни нет.
Если у вас apache работает с mod_php, то использование nginx сильно уменьшит необходимое кол-во процессов apache, кстати, и вы сможете потратить память на более полезные вещи.
2012/03/14 14:42:08 [error] 21671#0: *1270 open() "/usr/share/phpmyadmin/pma/themes/original/img/s_notice.png" failed (2: No such file or directory), client: 92.252.140.114, server: site.ru, request: "GET /pma/themes/original/img/s_notice.png HTTP/1.1", host: "site.ru", referrer: "http://site.ru/pma/phpmyadmin.css.php?token=05e05d69e723a6ce54a6ae5255098f65&js_frame=right&nocache=3894986086"
Тогда так попробуйте:
location ~* ^/pma/(.*)\.(jpg|jpeg|gif|png|css|ico)$ {
root /usr/share/phpmyadmin;
try_files $1.$2 =404;
access_log off;
expires max;
}
Боюсь, что FAQ по Drupal, не слишком полезен. =)
У Drupal довольно высокий порог вхождения, и довольно сильно отличная от большинства CMS идеология. Минимальный объём информации для освоения слишком большой, чтобы представить его в рамках какого-нить FAQ.
Если планомерно изучать, лучше всего пойти на drupal.org там информация довольно хорошо структурирована, и естественно наиболее полная.
Ну не судьба. =) Я поэтому и сказал, что возможно, т.к. сам не пробовал simple_page_title именно в этом варианте использовать.
Вообще говоря, взятль словарик и перевести, не так сложно. Сложно понять, что это всё значит и как интерпретировать, и мануал по Munin тут никоим образом не поможет, потому, что всё привязано к пониманию работы OS или определённых приложений. Что конкретно значит тот или иной параметр, и как его интерпретировать, вам тут вот так с ходу на форуме вряд-ли кто объяснит, т.к. это будет очень длинно - по каждому параметру статью неплохую написать можно.
В краце где-то так:
Evictions - зависит от контекста, вытеснение чего-то из кеша например.
Items - зависит от контекста
MySQL threads - количество потоков(нитей) mysql
MySQL throughput - объём данных принимаемых/отдающихся mysql в ед. времени
Firewall Throughput - количество пакетов проходящих через firewall в ед. времени
Nginx requests - количество запросов принимаемых nginx в ед. времени.
NGINX status - количество соединений nginx в различных состояниях (передающих данные nginx, принимающих от него данные, в ожидании)
Postfix bytes throughput - объём проходящих через почтовый сервер писем в единицу времени.
Postfix Mailqueue - размер очередей postfix - ожидающие обработки, отклонённые и.т.п.
Fork rate - частота порождения новых процессов в системе.
Number of threads - количество потоков (нитей)
VMstat количество работающих/ожидающих в данный момент процессов.
Available entropy - насколько качественно работает генератор случайных чисел (точнее клоичество событий, на основе которых он работает)
Individual interrupts - количество различных прерываний в ед. времени.
Interrupts and context switches - общее количество прерываний и переключений контекста в ед. времени.
NTP kernel PLL offset (secs) - Смещение локального времени относительно NTP серверов.
