Масштабная ЛАМПА - PullRequest
       16

Масштабная ЛАМПА

3 голосов
/ 23 ноября 2008

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

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

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

Видео на самом деле идет в формате JPG. Похоже на этот сайт:

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

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

Ответы [ 6 ]

8 голосов
/ 23 ноября 2008

Советы по поводу CloudFront, MemCache и т. Д. Все в порядке, при условии, что они устраняют корень проблем с производительностью.

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

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

Проходят ли какие-либо запросы назад столбцы, которые не используются?

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

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

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

5 голосов
/ 23 ноября 2008

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

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

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

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

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

Удачи.

4 голосов
/ 23 ноября 2008

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

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

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

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

0 голосов
/ 29 апреля 2011

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

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

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

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

Я уверен, что есть еще много вещей, которые можно сказать ...

0 голосов
/ 23 ноября 2008

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

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

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

0 голосов
/ 23 ноября 2008

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

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

...