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