Разделение динамического и статического контента на сайте с высоким трафиком
Я пытаюсь увеличить емкость своего веб-сайта, которая превышает возможности моего текущего веб-сервера. Сайт размещается на выделенном веб-сервере (Litespeed) и на выделенном сервере базы данных. Он получает более 180 000 посетителей в день, и ежедневно с сайта производится 100 000 загрузок.
На сайте, основанном на PHP/MySQL, размещено более 200 ГБ пользовательских загрузок / файлов, к которым открыт общий доступ. Для каждой загрузки мы храним файл main/download вместе с предварительным просмотром. Это может быть короткий файл MP3, короткое видео в формате MP4 (преобразованное в FLV для предварительного просмотра) и изображения (jpg) среди нескольких других форматов, которые обычно имеют уменьшенные изображения и предварительный просмотр изображений большего размера. У нас также есть форум с 20 ГБ вложений.
Весь динамический контент, загружаемый / статический контент, размещается на веб-сервере, и загрузки составляют ~20 в течение дня, узким местом является ожидание диска и ЦП (двойной 5410).
Мой хост предложил зеркалировать веб-сервер с помощью аппаратного балансировщика нагрузки перед ними, что означает сохранение больших, более медленных дисков или, в качестве альтернативы, запуск одного веб-сервера для динамических страниц с более быстрыми дисками и перемещение всего статического содержимого, миниатюр / предварительных просмотров и загрузок в выделенный статический сервер под управлением nginx. Это прекрасно работает для предварительного просмотра изображений, однако все загрузки обрабатываются динамически с помощью PHP-скрипта на веб-сервере, так же как и потоки предварительного просмотра Mp3 и flv. Я не понимаю, какую пользу принесет это для загрузки / потокового контента, поскольку я предполагаю, что веб-сервер все еще будет находиться под большой нагрузкой, и только статические серверы будут обслуживать только JS, CSS и изображения для предварительного просмотра. Они также предложили создать частное облако; с виртуальным веб-сервером и балансировщиком нагрузки на каждом сервере.
Может ли кто-нибудь объяснить, как лучше всего оптимизировать этот сценарий и сделать его более гибким для дальнейшего расширения в случае необходимости?
Другая информация: наши MP3-файлы не являются большими (350-400 КБ), FLV-файлы занимают до 10 МБ, но некоторые другие материалы, такие как rar/zip-файлы, могут иметь размер до 30 МБ и в среднем около 10 МБ.
Спасибо
3 ответа
Извините, но я бы взял профилировщик, если он существует для PHP / MySql, и оптимизировал бы его. Независимо от того, как я сократил числа, этот сайт - нечто вроде, которое должно быть в состоянии успешно работать на процессоре Atom с ядрами. 180.000 посетителей в день - это НЕ ТОЛЬКО для хорошо запрограммированного сайта. Для ожидания диска - получите подходящий RAID-контроллер или ZFS и вставьте 1-2 SSD в качестве кэширования. Плюс получить хард iscs - быстро много. Базы данных - это не то, что вы ставите с производительностью на обычном конечном сервере. Просто чтобы дать вам представление - у меня есть сервер данных объемом 800 Гб, и я использую 10 дисков - 8x Velociraptor ion Raid 10, 2 SSD в зеркале для журналов. Ожидание диска будет происходить с плохо спроектированными подсистемами для любой базы данных.
Итак, опять же, на вашем месте я бы:
Начните оптимизировать мой PHP-код, вставьте несколько ускорителей. Я помню, как имел дело с 400 000 посетителей на сайте знакомств год назад на двойном Pentium. Через час во время телешоу. С ASP - не компилируется.
Начните выкладывать лучшую подсистему ввода-вывода.
Примечание: позднее может потребоваться новое оборудование. Так или иначе. Здесь правила SuperMicro - у них есть серверные корпуса с 72 отсеками для дисков высотой 4 стойки. 24 диска в 2 стойках, все на объединительной плате SAS. Я использую один из них (всего 20 дисков), и он действительно потрясающий.
Вы можете оптимизировать обслуживание статического контента с помощью сценариев, используя заголовок X-SENDFILE.
вам, вероятно, следует разделить статический контент и базу данных на разные диски / массивы и немного поэкспериментировать с настройкой массива статического контента. в некоторых случаях raid1/raid10 может быть лучше, в других случаях raid5 может работать лучше (особенно если вы не пишете слишком много), а в некоторых случаях просто иметь несколько отдельных дисков (или массивов raid1, если вам нужна избыточность) с выложенными файлами равномерно через все они могли бы добиться цели.
в зависимости от того, сколько памяти у вас есть, все небольшие файлы или некоторые из наиболее часто запрашиваемых файлов (вы можете получить статистику из журналов веб-сервера) в ramdisk, что упрощает работу с дисками. (хотя это действительно зависит от того, какой именно трафик вы видите, поскольку ОС пытается сделать это за вас с помощью кэширования, которое может или не может работать хорошо)
и, конечно, разделение сервера на две части, каждая из которых обслуживает половину файлов, может помочь вам даже без loadbalancer. (это опять же зависит от трафика)
Прежде чем инвестировать в оборудование или изменить свою архитектуру, я предлагаю попытаться найти причину проблем с производительностью.
Вы упомянули дисковый ввод-вывод. Что вызывает этот IO? Вы уверены, что это загрузка файлов, возможно, регистрация или другие действия.
Я обычно начинаю с каталогизации того, что пишу / читаю с диска. Существуют ли какие-либо конкретные программы / функции, которые имеют тенденцию вызывать больше проблем, чем другие. Попробуйте отключить определенные задачи, например, отправлять журналы apache в / dev / null. Остановите почту, если она также запущена на сервере.
Это всего лишь пример того, с чего я бы начал.
Многие хосты быстро используют больше оборудования - здесь, безусловно, есть бизнес-мотив, но, как правило, это единственный выход для решения проблем с производительностью. Как правило, они не предоставляют услуги по оптимизации веб-производительности, поэтому ответ по умолчанию становится более аппаратным.
Более дорогое оборудование и убывающая прибыль.