Как настроить веб-сервер и подготовить его для одновременного посещения большого количества посетителей?
У меня есть еще один связанный с этим вопрос, но я отклоняюсь от него, так как меняю свой сервер на использование nginx вместо Apache.
Связанный: Проблемы с сервером, нехватка оперативной памяти, действительно высокая средняя нагрузка
У меня все еще возникают проблемы, хотя сейчас их гораздо проще найти. Вот ситуация, о которой я могу рассказать:
У моей жены есть сайт WordPress с множеством плагинов, включая WooCommerce. Даже когда мы вдвоем непрерывно просматриваем сайты (я с двумя открытыми браузерами, она с одним), мы можем остановить сервер.
Системные характеристики: Debian 7.7, 512 МБ ОЗУ, 512 МБ подкачки, 2 ядра (скорость неизвестна), nginx, PHP5-FPM, MySQL Server.
Этот снимок экрана моего окна терминала в значительной степени рассказывает историю:
Значения vmstat si / so равны 0 (в основном) во время легкого серфинга. Поскольку мы оба просматриваем сайт одновременно, значения меняются путь вверх, а htop показывает, что идет серьезная борьба. С новой установкой nginx / php-fpm у меня есть, если я просто запустил sudo service php5-fpm restart, все исправлено. Та же проблема возникает и с Apache: если мы просматриваем сайт в одно и то же время, si / so взлетает до небес, и сайт зависает, то он либо восстанавливается самостоятельно через некоторое время, либо мне приходится перезапускать Apache.
Я здесь в растерянности. Я бы предпочел продолжить настройку nginx и устранить ее. В этом случае, похоже, проблема в php-fpm. Но когда мы попадаем на сервер, это неприемлемо. Если бы ее сайт вдруг посетило сразу 20 человек, мы бы облажались.
Если попытка запустить сайты WordPress на 2-ядерном сервере объемом 512 МБ безнадежна, дайте мне знать. Возможно, мне придется перейти на 1024 МБ / 4 ядра.
Отделите логику приложения и отображения (спереди) от логики доступа к данным и хранилища (сзади). База данных будет генерировать много операций ввода-вывода и, как таковая, будет замедлять другие действия на том же сервере.
Добавьте RAM. нет, серьезно, добавь оперативку. Доступ к данным, хранящимся в памяти, происходит быстрее, чем доступ к данным, хранящимся на флэш-накопителе, что быстрее, чем доступ к данным, хранящимся на вращающемся жестком диске.
Добавьте слой кэширования между приложением и базой данных, например memcached или некоторые другие в пространстве. Опять же, это означает, что часто используемые данные могут быть извлечены из памяти, а не с вращающихся пластин.
Больше жестких дисков. Жесткий диск может искать только одно физическое положение за раз. Увеличивая количество шпинделей, вы можете заставить других выполнять поиск, пока один читает, и разделить более затратную по времени часть (поиск) между большим количеством физических устройств.
Разделите веб-голову между несколькими физическими блоками и настройте балансировщик нагрузки для распределения запросов между ними (с оговоркой, что все они хранят данные сеанса в общем хранилище, таком как база данных или файл в общей папке CIFS / NFS), чтобы они могут разделить нагрузку.
Используйте веб-сервер, который предлагает объединение в пул и повторное использование соединения, так как время для развертывания соединения занимает много времени по сравнению с обслуживанием запроса, особенно если большая часть данных находится в памяти.
Проведите аудит процессов внутри вашего сервера или серверов и определите, есть ли посторонние процессы, которые не создают ценности. Определите, используются ли какие-либо ресурсы (ОЗУ, ЦП, дисковый ввод-вывод), но не создают значения, и определите, можно ли их безопасно отключить.
Выполняйте потоковую передачу журналов (особенно журналов доступа по протоколу http и журналов ошибок HTTP) через Berkeley Syslog в специальный журнал (при запуске RSyslogd или Splunk и т.п.) вместо записи на локальный диск. Опять же, доступ к локальному диску стоит дорого.
Настройте свой сервер и посмотрите, выгружается ли и сколько данных из основной памяти на диск. Если оно больше 5% или сумма неравномерна и сильно колеблется, ДОБАВЬТЕ БОЛЬШЕ ОЗУ. Серьезно, перелистывание на диск происходит медленно, дорого и болезненно.
Инструментируйте свой php и найдите, какие части являются наиболее загруженными и какие части используют какие наборы ресурсов. Назначьте затраты на использование ОЗУ, время процессора, использование дискового ввода-вывода, использование сети. Масштабируйте эти затраты по среднему времени доступа. Фактически взимайте с себя плату, исходя из этих затрат, и вкладывайте деньги в свой фонд оптимизации. Теперь посмотрим, как сэкономить.
А если серьезно, то оперативной памяти побольше.
Изменить 1: Вот как я могу это сломать. Это очень грубый дизайн салфетки, но он показывает, как сделать его масштабным. Кусочки, которые могут выглядеть новыми, - это биты очереди. По сути, они абстрагируют сетевой трафик и делают систему в целом менее связанной. Это означает, что кратковременный переходный процесс между серверной частью данных и веб-головками будет менее разрушительным и будет легче восстанавливаться. Очереди проходят между приложением в веб-заголовке и интерфейсом на серверах баз данных и управляются из диспетчера очередей. Эта более слабая связь уменьшит необходимость пейджинга посреди ночи для одного кратковременного сообщения.
для nginx нужно сделать очень небольшую настройку. Вся настройка OS / nginx, которую вы можете сделать, может увеличить количество запросов в секунду на 5-10%. Мне кажется, ты больше привязан к памяти. Лучше всего удалить процессы php-fpm с вашего веб-сервера и создать серверы приложений, на которые nginx отправляет трафик.
---> internet -> nginx -> many app servers