Мне нужно настроить свой новый выделенный сервер (Intel Atom E220 1.6 Ghz ONE CORE, 2 ГБ RAM)
Да и сайт у меня необычный. У него много параллельных процессов (php), потому что некоторые запросы php занимают более 1 секунды. Скрипт оптимизирован, но он выполняет запросы cURL и соединения сокетов, и ему приходится ждать ~ 1 секунду для каждого ответа.
Итак, у меня есть ~ 100 одновременных, 1-секундных запросов php.
Конфигурация ведьмы лучше для меня?
Андрей
РЕДАКТИРОВАТЬ - ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ
У меня дома есть сервер, это «сервер обнаружения». И у меня есть специальный центр обработки данных, то есть «сервер веб-сайта».
Сервер обнаружения написан на C #, скомпилирован с моно под linux. В основном сервер обнаружения представляет собой асинхронный сервер сокетов. Каждый поток на этом сервере обнаружения занимает от 0,5 до 1,0 секунды.
Сервер веб-сайтов имеет простой скрипт, который называется check.php. Этот скрипт действительно прост: он подключается к серверу обнаружения, отправляет строку. После обнаружения (~ 1 сек) он считывает сервер обнаружения формы ответа.
Это будет зависеть от того, какие еще функции вам нужны, поэтому для простоты я предполагаю, что ничего другого не требуется, кроме обслуживания сценариев PHP и статических файлов. Я сомневаюсь, что приложение, которое вы описываете, будет зависеть от процессора даже на Atom, поэтому я предполагаю, что оперативная память будет вашей ключевой причиной узких мест.
Если эти запросы действительно должны быть параллельны, а не стоять в очереди, тогда вам понадобится достаточно ОЗУ, чтобы одновременно работать как минимум 100 экземпляров PHP и соответствующие рабочие веб-сервера. Возможно, вы сможете уменьшить это, используя Apache с MPM на основе потоков, если ваш PHP компилируется полностью потокобезопасным (модуль libcurl является потокобезопасным, вам нужно будет проверить любые другие, которые вы используете, но я считаю, что большинство из них поточно- безопасно в наши дни), поскольку я считаю, что это позволит более эффективно разделять кодовые страницы с помощью apache / mod_php / php. Если потокобезопасный запуск невозможен, вы можете подумать о чем-то более легком, чем Apache, тогда вы можете, по крайней мере, уменьшить эту часть следа, поэтому lighttp или nginx запускают PHP через fCGI (который, как правило, более удобен в настройке, чем Apache + mod_php, поскольку большинство дистрибутивов в основном делают apache + mod_php для вас из коробки, сохраняя небольшую настройку, но может быть значительно более эффективным ОЗУ, чем Apache).
Если вы используете Apache, вы можете уменьшить вероятность того, что рабочие с загруженным PHP будут «потрачены впустую», обслуживая статические файлы (это означает, что вам нужно разрешить больше рабочих, чем действительно требуется для вашего PHP-кода), поместив nginx (или lighttp) перед Apache как обратный прокси-сервер - управляемый событиями сервер с низким ОЗУ, обрабатывающий все статические запросы и просто отправляющий запросы, требующие PHP, в Apache.
Насколько сложно ваше приложение и насколько вы привязаны к PHP? Описание в вашем вопросе (многие рабочие, большинство из которых просто сидят, ожидая, что что-то произойдет) позволяет предложить полностью управляемое событиями решение, а не решение на основе процесса / потока, но это будет означать отход от PHP. В настоящее время существует множество веб-архитектур, основанных на событиях, некоторые из которых, по-видимому, довольно стабильны. Чтобы назвать только одного, node.js - один из самых популярных вкусов современности. При организации, полностью управляемой событиями, каждый параллельный запрос будет использовать очень мало дополнительной оперативной памяти. Вы можете смешивать и сочетать технологии - используйте эффективный в ОЗУ веб-сервер, управляемый событиями, для обработки статических файлов и прокси для обоих экземпляров node.js (запуск вашего кода, который будет проводить все свое время в ожидании запросов, сделанных во внешний мир, чтобы вернуться ) и экземпляры Apache (выполняющие ваш оставшийся PHP-код), хотя это сочетание и сопоставление может быть не привлекательным для вас в зависимости от вашего уровня технических знаний и уверенности, поскольку его будет сложнее настроить, чем просто apahe + mod_php.
редактировать
С вашим новым описанием того, что делает PHP-скрипт, вы сможете использовать php-модуль curl curl_multi_* функции для выполнения асинхронных HTTP-запросов. Это означает, что все ваши проверки могут быть сделаны одним процесса PHP означает проблему использования памяти спорна и коммутационные веб-сервера будут делать практически никакой разницы. Видеть руководство по PHP для ссылки на эти функции и примеры как этот для получения дополнительных примеров, похожих на учебные, если справочные материалы не проясняют общий процесс.
Если это автоматизированный процесс, и вам не нужен HTTP-ответ от него (т.е. вы просто записываете ответы в базе данных для дальнейшего анализа), вы даже можете запустить php-скрипт непосредственно из задания cron, вместо того, чтобы использовать веб сервер вообще.
Во всех случаях, кроме самых крайних, выбор сервера не имеет значения для производительности.
Ответ на вашу проблему - убрать задержку из цикла запрос-ответ. IOW: использовать очереди