Я являюсь администратором сервера для небольшого стартапа в качестве побочного предприятия (что означает, что я ни в коем случае не являюсь опытным экспертом в этой области), и недавно я помог перенести сайт с компьютера с одним Windows на кластер компьютеров в Rackspace. Облако.
В настоящее время сайт показывает около 600 запросов в секунду, но, учитывая количество ресурсов, которые мы ему выделили, я считаю, что он может быть намного выше.
Прямо сейчас мы используем Rackspace Cloud Load Balancer (Apache Zeus) перед 8 веб-серверами. Каждый веб-сервер работает под управлением Linux в облачном экземпляре объемом 512 МБ, а контент обслуживается Varnish с серверной частью Apache 2.
Само веб-приложение - это PHP. Apache работает в mpm-worker, а php - в fcgi. Также включен PHP APC.
Что касается бэкэнда базы данных, у меня есть два экземпляра сервера размером 4 ГБ, обслуживающие MySQL, в настройке репликации Master-Master, при этом половина веб-серверов указывает на каждый сервер. Приложение довольно интенсивно использует базу данных, поэтому так много ресурсов выделено на базу данных.
Производительность обычно в порядке, однако у нас были некоторые всплески нагрузки, с которыми существующая инфраструктура не могла справиться, поэтому я динамически увеличивал размер узлов. Это сработало отлично, но я чувствую, что при определенных условиях нагрузки, которые у нас были, мне пришлось вложить в инфраструктуру гораздо больше ресурсов, чем я ожидал, чтобы поддерживать сайт в рабочем состоянии и быстро. В моем исследовании кажется, что мы используем очень необычную настройку в отношении наличия такого большого количества отдельных экземпляров лака, и мне может потребоваться изучить вариант слоя кеширования.
Нарисован обзор текущей архитектуры. здесь (ссылка на документы google)
Модель ценообразования в облаке Rckspace довольно линейна, что означает, что экземпляр сервера размером 1024 Мбайт ровно вдвое превышает стоимость экземпляра 512 Мбайт. Таким образом, я стремлюсь максимизировать свою производительность, работая при том же количестве ресурсов (стоимости).
Моя первоначальная мысль - удалить балансировщик нагрузки в стойке в пользу использования одного экземпляра varnish перед бэкэндами apache и, возможно, сделать бэкэнд apache 4 экземплярами по 1 ГБ, а не 8 экземплярами по 512 МБ. Стоимость балансировщика нагрузки чрезвычайно низкая, поэтому, чтобы оправдать замену его другим выделенным сервером, необходимо, чтобы прирост производительности был большим.
Я также играл с идеей HAProxy и Nginx, но я не хочу начинать слепо экспериментировать на производственной площадке.
Моя цель - иметь возможность обслуживать около 2000 запросов / с примерно при том же распределении оборудования.
Редактировать: Некоторое время у меня работал mod_pagespeed, который увеличивал скорость примерно на 100 запросов / с, но у меня, похоже, было много проблем с тем, как он взаимодействует с лаком.
Редактировать: Лак VCL, Диск - это Rackspace Cloud по умолчанию (не-san, предполагая SATA), База данных в настоящее время составляет примерно 1,5 ГБ. При нормальных условиях подкачки на диск не требуется. Процессы Apache занимают около 20 МБ каждый. Процессы php-cgi обычно занимают намного больше ресурсов.
OP, вы можете использовать http://blitz.io для бесплатного тестирования производительности. Кроме того, посмотрите на «ab» и «httperf» некоторые инструменты для тестирования производительности командной строки.
Лак можно использовать с большим успехом при минимальной настройке. Кроме того, если вы используете тяжелые приложения PHP, я рекомендую установить APC.
Я бы пошел с одним большим объемом ОЗУ (проверьте использование лаковой ОЗУ с помощью varnish-tools и увеличьте до исправности) Экземпляры Varnish и без балансировщика нагрузки (или два лака и балансировщик нагрузки, если вы хотите высокой доступности) и столько же apache серверы по мере необходимости ... если ваше приложение связано с ЦП (больше серверов) или ОЗУ (серверы с более высоким MEM), зависит от вас.
Также поможет игра с настройками кеша (что можно обналичить на сколько времени).