Производительность стека ЛАМП при больших нагрузках трафика

Question

Я знаю, что заголовок моего вопроса довольно расплывчатый, поэтому я постараюсь прояснить насколько смогу. Пожалуйста, не стесняйтесь смягчать этот вопрос, чтобы сделать его более полезным для сообщества.

С учетом стандартного стека LAMP с более или менее стандартными настройками (разрешена некоторая настройка, кеширование на стороне клиента и серверной части), работающее на современном оборудовании (16 ГБ ОЗУ, 8-ядерный процессор, неограниченный диск пространство и т. д.), развертывание достаточно сложной службы CMS (проект Drupal или Wordpress для аргументов) - какие объемы трафика, SQL-запросы, пользовательские запросы я могу резонировать ожидать, прежде чем я начну думать о производительности?

ПРИМЕЧАНИЕ: Я знаю, что специфика будет в значительной степени зависеть от деталей проекта, то есть оптимизировать запросы MySQL, индексировать материал, минимизировать удары файловой системы - при условии, что веб-разработчики сделали профессиональную работу - я действительно ищу очень грубый показатель с точки зрения посещений в день, трафик во время пиковых посещений, количество записей до (транзакционных) ошибок MySQL, и так далее.

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

Я хотел бы получить набор цифр от людей с непосредственным опытом, например. «мы запускали такую-то настройку, и она обрабатывала, по крайней мере, такую ​​большую нагрузку [проблемы начали всплывать после таких-то-то-то]». Я также очень заинтересован в любом коннектике (я кратковременный atm) читаю, я могу сделать, чтобы лучше понять суть вопроса.

P.S. Я завтра встречу клиента, чтобы поговорить о его проекте, и я хочу быть готовым рассуждать о производительности, если его проект окажется похожим на FourSquare.

Answer 1

Очень сложно ответить без специфики, как вы уже отметили. Если бы мне было поручено, что вам нужно делать, я бы взял каждый компонент по очереди (сетевой интерфейс, процессор/память, физическая загрузка ввода-вывода, блокировка SMP и т. Д.) И получить максимальную доступную емкость, разделив приблизительную оценку использования для каждого запроса.

Например, io. У вас может быть карта 1x 1 ГБ, которая может достигать 100 Мбайт/сек. (Я имею тенденцию использовать 80% теоретического максимума). Как большой будет типичный «удар»? Возможно, 3 кбайт в среднем, для HTML, изображений и т. Д., Что означает, что вы можете достичь 33 тыс. Запросов в секунду перед тем, как узкое место на физическом уровне. Эти цифры являются абсолютными максимумами, в зависимости от инструментов и навыков, которые вы не можете найти рядом с ними, но никто не может превышать эти максимумы.

Повторите вышеизложенное для каждого компонента, возможно, немного изменив свои номера, и вы быстро создадите картину того, что может быть проблемой. Затем рассмотрите, как вы можете быстро получить больше возможностей в каждом компоненте, можете ли вы просто забить $$ и получить больше производительности (например, использовать SSD-диски вместо HD)? Или вы нажмете предел, который нельзя переместить без перестройки? Также учитывайте, какие ресурсы у вас есть, есть ли у вас много квалифицированного времени программистов, администраторы баз данных или кучу денег? Если у вас много ресурсов, вы можете уменьшить эти ограничения легче и быстрее, когда двигаетесь по кривой опыта.

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

Извините, я не могу дать вам реальные цифры, наши рабочие нагрузки используют пользовательские серверы, кэширование высокой памяти и другие трюки, а не использование всех перечисленных вами продуктов.Тем не менее, я бы больше сосредоточился на запросах IO/SQL и, возможно, сетевых IO, поскольку они, как правило, более жесткие ограничения, чем процессор/память, хотя я уверен, что у других будет другое мнение.

Answer 2

Очевидно, что вопрос таков, что у него нет «правильного» ответа, но я хотел бы закрыть его и дать некоторую обратную связь. Встреча клиента имеет место, выступление было действительно важная персона, их платформу хостинга оказался на Amazon облака :)

Из исследования я сделал самостоятельно:

• Memcache является обязательным;
• MySQL (или любой другой постоянный экземпляр хранилища, который вы запускаете) обычно является первым. Решения включают запуск нескольких виртуальных экземпляров и репликацию данных между ними, распределение нагрузки;
• http://highscalability.com/ является хорошим для чтения :)