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

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

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

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

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

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

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


optimization performance traffic lamp server-load
person Val Redchenko    schedule 25.02.2013    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

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

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

person rlb    schedule 26.02.2013

arrow_upward
0
arrow_downward

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

Из исследований, которые я провел независимо:

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