У меня есть приложение Facebook, написанное на PHP. Он имеет 150 просмотров страниц в минуту и будет иметь до 300 просмотров страниц в минуту до конца этого года. При получении большего количества PV у меня начинаются проблемы с масштабируемостью, и поэтому я хотел бы попросить вас совета, как масштабировать, чтобы успешно обрабатывать 300 PV в минуту.
Мое приложение похоже на викторину, оно размещено на VPS, который может использовать:
Конфигурация моего VPS выглядит так:
В то время как в последние месяцы я пытался оптимизировать конфигурацию MySQL, Lighttpd и PHP с помощью некоторых руководств, представленных в Интернете. Мне удалось широко использовать Memcached, поэтому многие запросы упали до 1 мс, а те, которые не обрабатываются memcache, занимают до 300 мс. Я добавил хорошие индексы в MySQL, чтобы они не вызывали опасений у пользователей.
Некоторое время вышеупомянутых оптимизаций было достаточно для обработки новых запросов, но в последнее время из-за растущей популярности приложения я заметил, что некоторые запросы занимают больше 3 секунд, и в критическом всплеске мой Lighttpd просто говорит, черт возьми, вы и пользователи получаете Internal Ошибка сервера 500.
Мне удалось найти (я точно знаю это сегодня) решение для исправления ошибки 500, установив:
"PHP_FCGI_MAX_REQUESTS" => "500"
Но до сих пор проблема масштабируемости не решена. Мне нужно обрабатывать в 2 раза больше запросов, чем сейчас. И думаю, как это сделать. Вот решения, которые я сегодня придумал:
Я могу купить у своего дистрибьютора VPS план большего размера, который имеет 3,3 ГГц вместо 2,6 ГГц, которые у меня есть сейчас, и на 2 ядрах, а не на одном. Понадобится еще немного денег, но может ли это мне помочь? Как рассчитать, выдержит ли он 300 PV?
Вторая идея - купить еще один VPS и переместить туда базу данных. Это должно дать прирост ЦП и памяти для процессов FastCGI и процесса базы данных. Но как узнать, что лучше создать другой сервер или купить более крупный план для этого, который у меня есть сейчас?
Итак, я пришел к 3 пункту - спросить кого-нибудь. Итак, я - программист, а не администратор, с огромной проблемой масштабируемости и прошу вашей помощи.
Я хотел бы знать, как я могу рассчитать, сколько PV в минуту может обрабатывать мой текущий VPS - это поможет мне решить. Потому что, если 300 PV выходит за рамки моих текущих возможностей VPS - я могу сразу подумать о другом решении и больше не возиться с конфигурацией.
Во-вторых - если возможно, что мой VPS может обрабатывать больше запросов - это проблема конфигурации - чем мне понадобится помощь от кого-то, кто более осведомлен в этом вопросе, чтобы помочь мне правильно настроить конфигурацию. Я могу предоставить эту конфигурацию здесь или отправить кому-нибудь по электронной почте и надеюсь узнать от вас, у кого есть время и знания, чтобы помочь мне в этом. У меня нет времени на дальнейшие эксперименты в этом вопросе.
Наконец - если это выходит за рамки моих возможностей VPS, я хотел бы узнать от вас, как решить, следует ли мне обновить свой VPS или создать другой сервер? Какое решение будет лучше для цели 300 PV?
Если вы подошли к этому пункту моих вопросов, заранее большое спасибо за вопрос. Ваша помощь, совет или контакты с людьми, которые могут помочь в этом вопросе, будут мне очень полезны!
Извините, но вы уверены, что говорите о просмотрах страниц за МИНУТУ, а не за СЕКУНДУ? 300 страниц в минуту означает всего 5 страниц в секунду, которые любой мобильный телефон должен уметь без труда передавать, поэтому я действительно не могу представить, что процессор с тактовой частотой 2,6 ГГц не справится с этим!
Если вы действительно уверены, что говорите о минутах, тогда следите за дисковым вводом-выводом, процессором и памятью. Невозможно, чтобы правильно спроектированное приложение работало так медленно, поэтому где-то у вас должна быть огромная проблема с настройкой. Возможно, вы выполняете тысячи обращений к базе данных MySQL или кэшу памяти, и вы очень чувствительны к задержке ввода-вывода (в этом случае ЦП останется почти неиспользованным). Если ваш процессор постоянно загружен, значит, у вас что-то не так в коде, и бесполезно пытаться оптимизировать ввод-вывод и другие компоненты, единственное жизнеспособное решение - исправить код.
Самым узким местом для VPS с разумными характеристиками обычно является дисковый ввод-вывод, поскольку все виртуальные машины, работающие на данном хосте, будут совместно использовать один и тот же диск (или массив дисков - хорошие хосты VPS будут иметь ваши виртуальные машины в массиве RAID10 или аналогичном), в Фактически, иногда несколько хостов виртуальных машин будут совместно использовать один и тот же массив, если они настроены с внешним массивом дисков. Это особенно очевидно, когда памяти становится мало, поскольку ваши запросы к базе данных всегда будут попадать на диск из-за отсутствия ОЗУ для кеширования даже основного рабочего набора данных.
Вы можете обнаружить, что получение собственного выделенного сервера с низкими характеристиками может улучшить ситуацию просто потому, что ваши потребности могут монополизировать необработанную полосу ввода-вывода, и вы увидите меньшую задержку ввода-вывода, поскольку головки дисков только переворачиваются назад и вперед для вашего I / O запрашивает, а не запросы ввода / вывода для нескольких других машин. Это может даже оказаться дешевле, чем решение «запустить два VPS», особенно если учесть, что во многих случаях передача данных между виртуальными машинами будет учитываться в ваших квотах на пропускную способность для машин (уточняйте у своего хоста - это не всегда так, но Если вам прямо не сказали, что это не так, безопаснее предположить, что это так), поэтому вы можете увеличить расходы, связанные с пропускной способностью. Вы можете быть удивлены, насколько мало вы можете арендовать небольшую машину на базе P4, и, судя по вашему описанию, я сомневаюсь, что мощность процессора является вашим узким местом (более вероятными виновниками являются конфликты памяти и ввода-вывода).
Ограничением может быть 500 МБ памяти, поэтому может помочь идея разделения двух VPS на две виртуальные машины, чтобы ваша база данных не конкурировала с процессами FastCGI и memcached. Точно так же, возможно, стоит выделить больше фиксированной ОЗУ - я никогда не верил в идею «прерывистого выделения ОЗУ», поскольку я предполагаю, что каждая ОС будет пытаться использовать как можно больше ОЗУ для повышения эффективности ввода-вывода (хотя Я никогда не использовал хост, который использует наращиваемое распределение ОЗУ, поэтому у меня нет прямых доказательств, подтверждающих мое неверие!). Что значит остальные free -m шоу? Кроме того, какого размера ваши базы данных? Выделение большего количества фиксированной оперативной памяти может помочь больше, чем переход на дешевый выделенный сервер (поскольку большинство более дешевых вариантов имеют только 512 МБ физической памяти, хотя большинство из них также можно обновить за дополнительную плату), в зависимости от того, насколько ограничены 512 МБ для ваших нужд.
Извините, это не совсем прямой ответ ...
Чтобы проверить, насколько RAM зависит от вашей производительности, вы можете установить виртуальную машину с аналогичной спецификацией на вашем локальном компьютере, продублировать вашу настройку и добавить на нее программное обеспечение для тестирования (http://httpd.apache.org/docs/1.3/programs/ab.html это место для начала), затем увеличьте объем ОЗУ, выделенный для виртуальной машины, чтобы увидеть, какое значение имеет место, где начинают возникать ошибки. Вы также можете смоделировать плохую конкуренцию ввода-вывода, запустив пару других простых виртуальных машин, каждая из которых выполняет своего рода Тест ввода-вывода, такой как bonie ++.
Я хотел бы знать, как я могу рассчитать, сколько PV в минуту может обрабатывать мой текущий VPS - это поможет мне решить. Потому что, если 300 PV выходит за рамки моих текущих возможностей VPS - я могу сразу подумать о другом решении и больше не возиться с конфигурацией.
Это очень и очень сложно. Очень сложно предсказать, какое влияние окажет оптимизация. И взаимодействие с другими частями вашей системы.
Вам нужно поэкспериментировать.
Во-вторых - если возможно, что мой VPS может обрабатывать больше запросов - это проблема конфигурации - чем мне понадобится помощь от кого-то, кто более осведомлен в этом вопросе, чтобы помочь мне правильно настроить конфигурацию. Я могу предоставить эту конфигурацию здесь или отправить кому-нибудь по электронной почте и надеюсь узнать от вас, у кого есть время и знания, чтобы помочь мне в этом. У меня нет времени на дальнейшие эксперименты в этом вопросе.
Если вы не можете экспериментировать, все, что можно делать, - это слепые догадки. Что может сработать. И у вас может быть особенно удачное и точное слепое предположение.
Вы должны профилировать и исследовать свою работающую систему. Кто-то «догадался» выше, что вы выбираете своп, и это могло быть хорошим предположением. Сначала используйте top, vmstat, sar, чтобы получить представление о том, что делает ящик. У вас есть привязка вашего процессора? Вы делаете массовый ввод-вывод? Вы меняете местами? Это даст вам разумное представление о том, в чем проблема.
Ваша проблема может лежать где-то между lighthttpd, PHP, memcache, MySQL. Обычные подозреваемые:
Вы должны указать на одну из трех проблем.
300 просмотров страниц в минуту - это немного, это 5 просмотров страниц в секунду, так что, похоже, происходит что-то странное.
Я склонен согласиться с ответом Дэвида Спиллетта. Я бы добавил, что размещение вашего приложения и базы данных на одном узле также является серьезным узким местом, потому что базы данных в целом требуют памяти. Я разместил несколько сайтов с высокой посещаемостью, столь же загруженных, как и тот, который вы описываете, и мы никогда не размещаем наш уровень базы данных на виртуальных машинах или на том же уровне, что и уровни Интернета и приложений; наши базы данных всегда работают на реальном и выделенном оборудовании.
Наши внешние интерфейсы, в зависимости от архитектуры, балансируют нагрузку с помощью CSM Cisco, но вы можете выполнить аналогичную балансировку нагрузки с помощью apache.
Если вы работаете в магазине Linux, есть масса способов решить эту проблему без дорогостоящего оборудования Cisco.
Посмотри на это: http://haproxy.1wt.eu/