25 января 2011 в 16:57
В последнее время мой портал набирает до 20000 уникальных посетителей, не считая ботов, и сервер работающий под Debian Lenny на Intel Core i7 CPU 975 @ 3.33GHz с 12 GB RAM в пики нагрузки начинает притормаживать.
У меня установлен Nginx перед Apache с mod_php который обслуживает только php и настроен согласно этим рекомендациям, весь реррайтинг берет на себя Nxinx. Стандартный Drupal кеш заменен на memcached и APC для PHP op-code cache.
Среди пары модернизаций, сделал два простых теста.
Оставлю для потомков:
No PHP op-code caches
Home Memory used at: devel_init()=4.77 MB, devel_shutdown()=114.71 MB.
Tracker Memory used at: devel_init()=4.77 MB, devel_shutdown()=121.99 MB.
APC ON
Home Memory used at: devel_init()=4.43 MB, devel_shutdown()=112.95 MB.
Tracker Memory used at: devel_init()=4.43 MB, devel_shutdown()=119.4 MB.
eAccelerator ON
Home Memory used at: devel_init()=1.48 MB, devel_shutdown()=81.74 MB
Tracker Memory used at: devel_init()=1.49 MB, devel_shutdown()=74.68 MB.
eAcelerator выгодно отличается от APC. Кому интересно, вот простое руководство для Debian Lenny.
apc.ini
apc.enabled=0
apc.shm_size=32
apc.ttl=7200
apc.user_ttl=7200
eaccelerator.ini
eaccelerator.shm_size="32"
eaccelerator.cache_dir="/var/cache/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"
Комментарии
А просмотров у вас сколько?
Хотя судя по Core i7 CPU 975 у вас хецнер, а у того и диски могут быть уже давно того
43K примерно
Про диски не понял. Думаете они ставят заюзанные жесткие диски и какое это отношение имеет к количеству памяти которую есть PHP? За 5 лет ни разу с железом проблем не было.
Это не диски, это Drupal такая CMS жирная на ресурсы.
Тогда либо у вас слишком тяжёлый сайт, либо слишком кривое железо/софт
Это влияет на быстродействие прямым образом, как оперативу не экономь, а на БД затык. Про хреновость дисков хетцнера только ленивый не писал.
5000-6000 SQL запросов на страницу достаточно тяжело?
Как умирающий жесткий диск влияет на быстродействие, не трудно догадаться и это выглядит немного по другому.
Вообще, тема не про то, где ботлнек конкретного сайта, а про то, что eAccelerator лучше чем APC на живом примере.
Хм. Нет, я с головы всё выдумываю.
Скоро будет статья про 160 000 просмотров на друпале без особых проблем.
С удовольствием почитаю. Можно узнать о каком сайте будет идти речь?
Смею предположить что это http://fermer.ru/ , у них сервер обслуживается в патруле.
Извиняюсь за оффтоп,
Ainur, давно хотела спросить, как у вас реализован блок: Н последих комментариев за сутки, Н последних постов за сутки... Поделитесь пожалуйста, сниппетом.
Спасибо.
Да, про него. Будут затрагиваться вопросы перевода портала на Drupal 6, оптимизации и всплывших граблях.
Опять же, все зависит от количества модулей, своих фичей, он-лайн пользователей.
п.с. у меня давно Друпал 6, прошел через 2 версии 4 потом 5-ка. На седьмой переезд тоже не планирую затягивать.
А переезд, скажем с версии 5 на 6, был произведен с сохранением материалов и путей к ним? Например, http://www.italia-ru.it/news/2011/01/23/54023 - это материал с nid=54023. Но, насколько я понимаю, чтобы при переброске данный материал получил требуемый nid (или vid, не важно сейчас), он должен быть 54023-м по счету. А как быть, если нод меньше (были удаления), вставлять фейковые ноды в пустые места?
Каким инструментом пользуетесь для переноса материалов?
Зашел на ваш сайт и секунд 10-15 было:
504 Gateway Time-out
nginx
Да.
Инструмент - Upgrade.txt
В общем, не мудрить и довериться update.php . Спасибо!
жестоко, я б сразу застрелил. 60-80 уже нервый тик у меня, а тут 6000
Да, на друпал.орг довольно подробная инструкция по обновлению. Составте себе хороший план обновления. Обновите все модули до последней версии. Смотрите примечания у модулей, может быть был какой-нибудь модуль-икс 5.x.1 и есть 5.x.2-dev и в примечаниях указно "Ахтунг! Обновится до 5.x.2-dev преред переходом на друпал 6.x"
Да, замечаю тоже
Тоже нервничаю
Мне после перехода, еще необходимо будет сделать редизайн(новую версию) сайта. При этом боевой сайт будет продолжать пополняться материалами и пользователями. Когда новый сайт будет готов, придется синхронизировать - искать таблицы, в которые вносились изменения (это не только users, node, node_revisions), заменять их в БД нового сайта и опять запускать update.php . Правильно я понимаю?
Не совсем понимаю. Дизайн не связан же с базой
Тему, лично я, портировал на версию 6.х до переезда. При чем тема должна быть модуле-независимой. Это, на пример, если отключаешь какой-то модуль, а где-нибудь в template.php есть вызов функции из этого модуля сайт перестает работать и выдает сообщение что функции такой нет.
После запуска update.php обратного пути, кроме отката базы данных уже нет.
Весь переход нужно желательно делать сначала на тестовом сервере, там же готовить тему для новой версии, смотреть баги, править их и только потом делать переезд на рабочем сервере.
В новой версии сайта будут изменения не только в файлах(шаблоны, css,...), но и в базе (блоки,вьювы...). Т.е. капитальный ремонт, не косметический
Спасибо за советы, у меня теперь полная картина вырисовалась.