Я разработчик PHP, я всегда работал в среде LAMP, и до сих пор все шло хорошо. На данный момент я разрабатываю веб-приложение PHP, все еще на apache и без использования какой-либо структуры.
PHP-fpm будет обслуживать динамическое и статическое содержимое во внешнем интерфейсе, в то время как скрипты php-cli будут выполняться во внутреннем интерфейсе через некоторые задания cron (фактическое приложение).
На этот раз я столкнулся с проблемой параллелизма, потому что этот веб-сайт будет использоваться несколькими пользователями. Предполагаемое количество одновременно зарегистрированных пользователей составляет 50-75, по крайней мере, на период запуска.
Я почти везде читал, что Nginx лучше, чем Apache в этом виде работы; Я прочитал много статей, в которых объясняются различия между ними, я читал статистику производительности, но нигде не нашел фактического порога (количества одновременных пользователей), выше которого вам следует переключиться с Apache на Nginx.
Мне интересно это только потому, что, как я сказал выше, я всегда работал с Apache, и изменение веб-сервера - важный выбор, в частности, в отношении времени, которое мне придется потратить на документацию Nginx, чтобы полностью понять его поведение. / функциональные возможности. Действительно, я попытался настроить сервер LEMP, но сейчас Nginx мне кажется арабским.
После этого "краткого" вступления я задаю следующие вопросы:
ПРИМЕЧАНИЕ. Думаю, эта информация будет важна для ответа: Prod. сервер (во время запуска) будет: 4c / 8t intel - 8gb RAM - SSD жесткий диск
Большое спасибо.
Во-первых, 50-75 одновременных пользователей - ничто. Любой веб-сервер может справиться с этим в полностью неоптимизированной конфигурации по умолчанию, и вам не о чем беспокоиться, пока вы не добавите ноль (или два) в конец этого числа.
Если у вас проблемы с производительностью на этом уровне, ваша проблема, вероятно, где-то еще (база данных, код приложения).
Тем не менее, не существует волшебного «порогового» значения, при котором можно было бы рассмотреть возможность внесения архитектурных изменений - на самом деле нет причин Когда-либо переключитесь, если вы не хотите: если вы знакомы с Apache, вы можете оставить его, чтобы упростить администрирование и решить проблемы с нагрузкой, добавив дополнительные серверы для распределения рабочей нагрузки.
Если вы хотите оптимизировать производительность, вы должны основывать свое решение на производительности. Настройте свои серверы как можно лучше (см. здесь для Apache 2.2 или здесь для Apache 2.4, или здесь для nginx), а потом сделать нагрузочное тестирование чтобы определить, какие характеристики даст вам каждый дизайн.
Если результаты тестов близки, не имеет значения, какой веб-сервер вы используете, потому что узкое место находится в другом месте вашего дизайна (и ваше тестирование должно показать вам, где находится узкое место, чтобы вы могли работать с этой конкретной частью системы).
Если числа радикально отличаются, вы можете использовать более быстрый веб-сервер, чтобы избежать необходимости добавлять дополнительное оборудование, но некоторые Дело в том, что вам нужно будет добавить больше машин для обработки высокого параллелизма - это просто путь Интернета.
Напоследок вспомни, что каждый раз, когда вы преждевременно оптимизируете, Кнут убивает котенка. Он говорил о преждевременной оптимизации программирования, но это аксиома и для системного администрирования, и для проектирования инфраструктуры: если вы этого не сделаете, необходимость чтобы максимизировать производительность сразу при запуске, разверните то, что вы знаете (и то, что вы тестировали), и постепенно повышайте производительность позже.