Я собираюсь вести блог в прямом эфире с мероприятия и ожидаю огромного всплеска трафика. В настоящее время я использую apache с modphp, и он умер в прошлом году из-за интенсивного трафика, и я не хочу, чтобы это повторилось снова.
Я подумываю создать отдельный VPS для этого блога, работающего на wordpress.
Какой http-сервер мне следует использовать? apache, lighttpd или nginx?
Что будет лучше всего работать при большой нагрузке?
Контент будет очень динамичным с обновлениями AJAX.
Lighttpd или nginx, вероятно, являются правильным решением. Лично я бы выбрал nginx.
Не забудьте также сильно оптимизировать ваше приложение. Кешируйте результаты запроса с помощью memcached.
Дальнейшая оптимизация может быть произведена путем обслуживания ваших изображений, js и css из отдельный домен без файлов cookie. Следование советам, содержащимся в этом руководстве, тоже поможет вам добиться успеха.
Вы можете настроить свой веб-сервер с помощью Лак для кеширования данных статической страницы. Если вы действительно хотите сделать все возможное, отправляйте свои изображения, js и css из CDN.
В зависимости от того, сколько трафика вы получите (или ожидаете получить); вам может потребоваться рассмотреть несколько интерфейсных веб-узлов, и в этом случае Varnish может действовать как чертовски хороший балансировщик нагрузки.
Я говорил это раньше и повторю еще раз. Если вы ожидаете скачков трафика, времени безотказной работы и отсутствия простоев, возможно, вам стоит взглянуть на Amazon EC2 с Автоматическое масштабирование предложение. Вероятно, это будет более эффективно, чем создание собственного решения, особенно если вы не ожидаете, что трафик будет сохраняться в течение всего года.
Кроме того, вы не сказали, используете ли вы VPS или физическую машину. Я обнаружил, что VPS не подходят для сайтов с высоким трафиком, потому что часто возникают проблемы с конфликтом ввода-вывода, вызывающие большое время ожидания ввода-вывода. Для обеспечения высокой доступности вы действительно не можете превзойти выделенное оборудование, двойные сетевые карты, резервную сетевую инфраструктуру и т. Д.
Полагаю, все зависит от вашего бюджета.
Nginx или lighttpd - верные ставки. Вы можете настроить Apache для повышения конкурентоспособности, используя модуль mpm-worker вместо prefork. Однако для этого требуется настроить php для использования fastcgi или подобного; это, наверное, умная идея сама по себе.
Я лично запускаю wordpress, используя nginx с php-fpm, и это чертовски быстро.
Есть некоторые оптимизации, которые вы можете сделать независимо от того, какой веб-сервер вы выберете.
Протестируйте установку под имитационной нагрузкой, чтобы убедиться, что она не сработает.
Я только что перешел с prefork apache2 на nginx php через fastcgi. Нет никакого сравнения, настройка nginx по умолчанию просто способна многократно обрабатывать запросы apache с помощью prefork. Я мог бы использовать apache2 mpm worker php через fast cgi, но я установил nginx на том же сервере, но с другим портом, чтобы полностью протестировать все, прежде чем переключать на него сайт. Теперь я могу повторить apache2 с mpmworker и fastcgi и сравнить.
Моя общая мысль такова, что apache2 mpm worker fastcgi будет работать и для меня.
Вы можете провести нагрузочное тестирование, используя http://loadimpact.com, где моя установка apach2 2 не смогла завершить работу с 20 пользователями, а nginx завершил работу с 50 пользователями практически без нагрузки. Кстати, моя установка имеет всего 128 МБ ОЗУ с 1 ГБ подкачки.
добро пожаловать на этот сайт.
Извините, если я вас разочаровал, но ваш сайт может снова вылететь из-за высокой нагрузки. Любой сервер имеет ограниченную мощность. VPS имеет лишь небольшую часть емкости полного сервера. И вы не знаете, насколько высока ваша нагрузка.
контент будет очень динамичным - обновления AJAX
Обратите внимание, что это может значительно увеличить нагрузку на сервер; в зависимости от реализации.
Чтобы ответить на ваш вопрос, использование только nginx или nginx в качестве прокси перед Apache, как писал Эспеннилсен, вероятно, являются лучшими решениями из тех, что вы упомянули.
Предложения CarpeNoctem также убедительны. WP Super Cache - это распространенная рекомендация для простого ускорения работы Wordpress. Если вы последуете моему предложению ниже, польза от WP Super Cache уменьшится.
Чтобы действительно получить производительность при ограниченном бюджете, вам следует:
Squid может быть настроен на сохранение полного вывода веб-страницы из Wordpress в ОЗУ и «обновления» его из Wordpress через заданное время. Это означает, что одна и та же версия веб-страницы предоставляется всем пользователям без изменений на короткое время, но тем временем Squid может обслуживать веб-страницу из ОЗУ. Это значительно быстрее, чем обращение к веб-серверу и выполнение Wordpress для каждого запроса страницы.
Настроить кеширование сложно и требует определенных знаний. Было бы рекомендовано использовать профессионального системного администратора с прошлым опытом в этой области.
Ранее у нас была установка apache2 с примерно 200 виртуальными хостами (по одному на каждого клиента), которые проксировались на один из 4 внутренних серверов с балансировкой нагрузки. Мы обнаружили, что как с mpm-worker, так и с prefork, Apache2 использовал огромную сумму неразделенной памяти на каждое соединение (20-30 Мбайт каждый, всего почти 400-500 Мбайт, только для внешнего интерфейса!) (Mpm-worker, похоже, менял кратные этому числу на основе maxclients). У нас не было оперативной памяти, выделенной для большого простаивающего пула интерфейсных рабочих, и мы постоянно достигали максимальной нагрузки на наших машинах еженедельно.
Затем мы переключили интерфейс на nginx. Я настроил его на максимальное количество подключений 4096 (аналогично максимальному количеству клиентов на apache), и он использует оперативную память 30 МБ. Он продолжает работать и обеспечивать адекватный отклик в условиях интенсивной замены. Мы смогли почти удвоить максимальное количество одновременных запросов. Мы достигаем максимальной нагрузки только в дни крайнего срока, и даже тогда мы можем настроить наши серверные ВМ, чтобы отдать приоритет этим клиентам.
Оглядываясь назад, использовать apache2 в качестве балансировщика нагрузки / прокси, вероятно, было неразумно, но это то, к чему мы пришли после многих лет эволюции. Мы его явно переросли, и на помощь пришел nginx.
Помните, что это всего лишь анекдотические свидетельства, но вы найдете похожие истории успеха с любым из серверов, основанных на событиях (lighttpd или nginx).
ваше приложение php будет узким местом со всеми тремя вариантами. Я настроил многомиллиардные сайты с apache.