Балансировка нагрузки программы PHP для поддержки растущих пользователей? - PullRequest
2 голосов
/ 27 марта 2010

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

Что нам нужно сделать, если мы хотим увеличить его, чтобы он мог выдержать нагрузку 500 или более? Как мы можем адаптировать эту программу к «балансировщику нагрузки» с минимальными изменениями?

Приложение написано на PHP и использует MySQL.

Ответы [ 2 ]

4 голосов
/ 27 марта 2010

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

Меньше запросов, необходимых для отображения страницы:

  • Более быстрые соединения с базой данных закрываются, что позволяет СУБД освободить память
  • Быстрые ресурсы соединения закрываются, что позволяет вашему приложению освободить память
  • Более быстрые процессы сервера HTTP завершаются, что позволяет им освобождать память
  • Чем быстрее пользователь получает информацию, которую он искал

Типичный общий веб-хост (как вы заметили) будет иметь менталитет одного сервера. Запуск СУБД на том же компьютере, что и веб-сервер, почти никогда не является хорошей идеей, если вы хотите масштабировать. Зачем? Оба должны выделять больше памяти, чем им нужно на самом деле или использовать, чтобы иметь возможность обрабатывать запросы и возвращать запрашиваемые данные. Это особенно верно для любой СУБД, которая поддерживает тип сходства .

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

Это означает, что чем меньше времени ваше приложение тратит на подключение к базе данных, тем меньше вероятность того, что вы достигнете лимита подключения. 50 могут обслуживать 500 и более пользователей. Будь то ограничивающие запросы, оптимизирующие их или оба.

Внимательно посмотрите на свое приложение. Где можно реализовать кэширование для информации, которая вряд ли изменится при каждой загрузке страницы? Как вы можете лучше использовать сессии? Это отличный интерфейс ajax, который делает запрос для КАЖДОГО события?

Большинство людей уже уверяют, что это не так, поэтому такие вопросы попадают в категорию микрооптимизация . Это действительно фундаментальная концепция дизайна.

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

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

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

0 голосов
/ 27 марта 2010

Соединение MySQL считается только используемым, когда оно открыто. Например, если я подключусь к веб-серверу, чтобы получить страницу, потребуется всего 50 мс или около того (угадайте), чтобы создать страницу и отправить ее мне. Это означает, что он может обслуживать 20 страниц за 1 секунду с 1 подключением MySQL. То, что пользователь делает со страницей после ее отправки в браузер, не влияет на производительность ваших серверов.

Таким образом, при 50 вы должны получать около 1000 попаданий в секунду, чтобы вызвать проблемы.

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

Если честно, я не думаю, что это проблема, о которой вы думаете - если вы получаете достаточно трафика, чтобы он действительно стал проблемой, то это то, что мы называем «хорошей проблемой»:)

...