Масштабирование LAMP

Question

У меня есть клиент с веб-сайтом LAMP, в основном использующим видео. В настоящее время он находится на одном сервере со всеми компонентами. У него проблемы с масштабированием. Каковы некоторые из тех методов, которые могут быть использованы для помощи.

Я использовал выделение БД на другой сервер с GB Ethernet между ним и веб-сервером. Может быть, добавить больше веб-серверов с некоторой балансировкой нагрузки и дополнительных серверов MySQL с репликацией?

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

Видео на самом деле поступает как изображения в формате jpg. Похож на этот сайт:

http://www.webcams.travel/webcam/1170170095

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

Answer 1

Рекомендации по CloudFront и MemCache и т. Д. - все это хорошо, если предположить, что они определяют корень ваших проблем с производительностью.

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

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

Есть ли какой-либо из запросов, возвращающих столбцы, которые не используются?

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

Все ли ваши таблицы MyISAM? Часто обновляемые таблицы могут показывать улучшение производительности, перемещая их на InnoDB, где они могут выиграть от блокировки на уровне строк (в отличие от блокировки на уровне таблицы MyISAM).

Это просто, общие рекомендации - без особого внимания точно , что медленное, трудно предложить что-либо более глубокое.

Answer 2

Вам нужно точно решить, в чем проблема - общего решения нет.

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

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

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

Answer 3

Прежде всего, я согласен, что вы должны знать, что такое узкое место, прежде чем пытаться масштабировать. Вот несколько вариантов работы мельницы, чтобы вы начали:

1. Получить видео из базы данных. Я не понимаю, как это будет иметь смысл в любой ситуации.

2. Добавить еще один сервер, чтобы только сервер видеоконтента и оставить HTML/приложение исходным. Это не только снижает нагрузку, но и повышает производительность на стороне клиента, преодолевая любые HTTP connection limits.

3. Кэш - это может означать Memcahce или просто готовить HTML-выход вместо динамической обработки его для каждого запроса.

4. Если вам посчастливилось достичь «супер большого», вы можете подумать о CDN. Я уверен, что вы столкнетесь с множеством других препятствий до этого.

Удачи.

Answer 4

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

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

Answer 5

Ответы Барретта - это то, что я хотел бы сделать - идентифицировать узкие места, посмотреть memcached, переместить БД на отдельный сервер из веб-сервисов и т. Д.

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

Кроме того, ознакомьтесь с презентациями Livejournal и Facebook о том, как они масштабируют свои системы, они могут дать некоторую информацию в зависимости от того, как вы структурируете свои приложения.

Answer 6

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

Во-вторых, если вы используете MySQL, включите журнал медленных запросов MySQL (log_slow_queries в my.cnf); это можно использовать, чтобы дать вам представление о том, что представляют собой дорогие запросы к базе данных, и как только вы узнаете, что вы можете настроить их через EXPLAIN <> как уже упоминалось. Возможно, вам просто нужно добавить несколько индексов в базу данных, после чего она снова станет быстрой. Существуют и другие соответствующие параметры my.cnf, например. log запросов, не использующих индекс.

В-третьих, посмотрите на инструменты, такие как плагин Firefox Firefox для Firefox, - он сделает некоторые предложения (например, выгрузите статический контент, скомпилируйте материал, который вы возвращаете, убедитесь, что у вас заканчиваются заголовки и т. Д. И т. Д.). Возможно, сервер (ы) сами по себе не являются узким местом, а страницы занимают много времени для рендеринга из-за зависимости от третьей стороны (внешние JS, рекламные объявления, flash ...).

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

Я уверен, что есть нагрузки больше, что можно сказать ...