Имеет ли смысл отдельный сервер MySQL при использовании Nginx вместо Apache? - PullRequest
1 голос
/ 06 января 2010

Рассмотрим веб-приложение, в котором вызов приложения состоит из сценария PHP, выполняющего несколько запросов MySQL, некоторые из них memcached. PHP не делает очень сложную работу. Он в основном обслуживает данные MySQL с некоторым форматированием.

Раньше рекомендовалось размещать MySQL и механизм приложений (PHP / Apache) в отдельных блоках.

Однако, когда данные могут быть разделены по горизонтали (например, когда услугами пользуются десять разных клиентов и возможно разделить данные на каждого клиента) и когда вместо более тяжелого Apache используется Nginx + FastCGI, имеет ли смысл ставить Nginx Memcache и MySQL на одну и ту же коробку? Затем, когда приходит больше клиентов, добавить аналогичные коробки?

Справочная информация: мы переходим на Amazon Ec2. А отдельное поле для MySQL и сервера приложений означает двойные тома EBS (необходимые на серверах приложений, чтобы код оставался постоянным, так как он часто меняется). Также, если что-то случится с полем базы данных, больше клиентов потерпит неудачу.

Уточнение: в настоящее время приложение работает с LAMP на одном сервере (до перехода на EC2).

Ответы [ 3 ]

3 голосов
/ 06 января 2010

Если ваша прикладная архитектура уже разработана для поддержки Nginx и MySQL в отдельных экземплярах, вы можете разместить все свои службы в одном экземпляре, пока не получите достаточно трафика, который оправдывает разделение.

В целом, создание новых идентичных экземпляров с полным стеком (Nginx + Ваше приложение + MySQL) значительно усложнит обслуживание вашей установки. Подумайте о создании резервных копий, выпуске обновлений приложений, исправлении ядра базы данных, обновлении схемы базы данных, создании отчетов по всем вашим клиентам и т. Д. Если вы выберете этот метод, вам действительно потребуется найти некоторые большие преимущества для компенсации всех недостатки.

2 голосов
/ 06 января 2010

Вы должны тщательно измерить, сколько у вас служебной памяти - я не вижу, что enginex и Apache имеют большое значение, это PHP, который будет использовать всю оперативную память (это, в свою очередь, зависит от того, сколько процессов выбирает веб-сервер для запуска). , но это больше проблема тюнинга).

Лично я бы держался подальше от enginex на том основании, что слишком странно запускать такой странный сервер в работе.

Базы данных всегда нуждаются в большом количестве оперативной памяти, и единственный способ разумно настроить буферы памяти - это разместить их на выделенных серверах. Это предполагает, что у вас есть большие данные.

Если у вас очень маленькие данные, вы можете хранить их в одном окне.

Аналогично, memcached практически не имеет смысла, если вы не запускаете его на выделенных блоках. Извлечение памяти из MySQL для передачи memcached действительно отнимает у Питера деньги Полу. MySQL может кешировать содержимое в свой innodb_buffer_pool довольно эффективно (это экономит ввод-вывод, но может в конечном итоге использовать больше ЦП, поскольку вы не будете кешировать логику представления и т. Д., Что возможно при использовании memcached).

Memcached имеет смысл только в том случае, если вы запускаете его на выделенных коробках с большим количеством оперативной памяти; это также разумно, если у вас недостаточно ворчаний на ваших серверах БД, чтобы обслуживать нагрузку чтения вашего приложения. Подумайте об этом перед развертыванием.

1 голос
/ 06 января 2010

Если ваше приложение может работать с PHP и MySQL на разных серверах (на самом деле я не понимаю, почему это не сработает), то оно также будет работать с PHP и MySQL на одном сервере.


На самом деле вопрос в том, смогут ли ваши серверы справиться с нагрузкой Apache / nginx / PHP, MySQL и memcached?

И есть только один способ ответить на этот вопрос: вам нужно протестировать в «реальной» «рабочей» конфигурации, чтобы определить собственные загруженные ваши серверы - или использовать какой-нибудь инструмент, например ab , осада или OpenSTA для "симуляции" этой нагрузки.

Если нагрузка на все на одном сервере не слишком велика ... Что ж, продолжайте, если это делает хостинг вашего приложения более дешевым; -)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...