Масштабирование веб-приложения по нескольким сервисам
Мы разрабатываем наше веб-приложение и работаем над сокращением времени загрузки. Когда мы начали разработку приложения, мы зарегистрировались у известного хостинг-провайдера, предлагающего "выделенные решения" в облаке. В результате у нас есть один выделенный сервер для нашего веб-приложения и один выделенный сервер для нашей базы данных. Оба сервера были настроены с одинаковым объемом оперативной памяти, одинаковым процессором и SSD-дисками. Даже потратив время и деньги на нашу инфраструктуру, мы заметили, что время загрузки составляет 8-10 секунд.
Другая хостинговая компания посоветовала нам уменьшить масштаб и поместить все на один сервер (вместо того, чтобы разделять его). Они отметили, что разделение серверов приведет к увеличению времени загрузки из-за задержек в сети, и заявили, что PHP будет быстрее взаимодействовать с SQL через сокеты, чем по сети. Я знаю, что это правда, но я не ожидал результатов, которые мы получили. Сразу после переноса всего на наш оригинальный сервер приложений время загрузки сократилось до 3-4 секунд с 8-10!
Проблема в том, что мы сейчас ищем нового хостинг-провайдера, и нам посоветовали использовать кластер с балансировщиком нагрузки, сервером базы данных, сервером приложений и масштабированием оттуда. Проблема заключается в том, что если мы снова разделим сервер приложений и базы данных, мы вернемся к исходной точке.
Из всего, что я прочитал, кажется, что почти всегда рекомендуется разделять эти серверы, а не группировать их вместе. Есть ли прирост производительности, который достигается при правильной настройке, или это просто для масштабируемости в долгосрочной перспективе?
Я ценю помощь!
2 ответа
Ваш вопрос очень широкий, поэтому я просто упомяну несколько аспектов:
локальный сокет ввода-вывода быстрее, чем TCP, но для большинства приложений это должно быть незначительно по сравнению со всеми другими частями вашего времени выполнения (балансировщик нагрузки, обработка PHP, обработка запросов к БД, ...)
Сплит-системы обеспечивают лучшее кэширование, например, сервер БД может хранить больше индексов в ОЗУ.
возможно, точка масштабируемости: разделить системы проще в настройке, например, для развертывания новой версии программного обеспечения или обновления PHP, вы можете просто добавить новый сервер приложений, протестировать его и, наконец, удалить старый.
чтобы исследовать ваши проблемы: проверьте, сколько соединений с БД открыто для каждого веб-запроса. Одним из объяснений ваших измерений может быть приложение, которое использует много SQL-запросов без постоянных соединений, поэтому новое TCP-соединение открывается для каждого доступа к БД.
Я не знаю, что вы делаете, чтобы получить 8-10 секунд времени загрузки (при условии, что вы определяете "время загрузки" как "время между приходом HTTP-запроса и созданием страницы и отправкой в браузер").
Вы не сможете использовать ваши ЦП на 100% с помощью веб-сервера и базы данных, и даже если вам как-то удастся это сделать, размещение веб-сервера и базы данных на одном сервере не поможет.
Кроме того, любая перегрузка на сервере БД не будет устранена путем перемещения обоих серверов на одном оборудовании.
Таким образом, проблема почти связана с
- очень много очень маленьких операторов SQL, которые отправляются в БД по отдельности, поэтому даже небольшая задержка в локальной сети накапливается (представьте, что у вас есть 10000 операторов SQL на страницу и сетевая задержка 0,1 мсек. Это приведет к вашей 10-секундной загрузке время).
- огромные капли, хранящиеся в базе данных, которые должны попасть на веб-сервер через соединение SQL, которое обычно медленнее протокола, предназначенного для передачи файлов, особенно по сети
- сетевое соединение между вашими хостами каким-то образом искусственно ограничено
Может быть, это что-то еще, что я не могу себе представить в данный момент, потому что типичное веб-приложение очень редко становится медленным, когда вы распределяете его по большему количеству процессоров, если эти процессоры имеют быстрое сетевое соединение между ними.
До тех пор, пока вы не узнаете, что вызвало / вызвало проблему на отдельных хостах, у вас может снова возникнуть такая же проблема, а может и нет.
В прошлом году у меня возникла первая проблема - один мой клиент заключил контракт с третьей стороной на разработку программного обеспечения для них. Типичная операция на демонстрационном ноутбуке заняла около 4 часов. Когда мой заказчик переместил программное обеспечение в предполагаемую производственную среду (сервер приложений BIG, кластер баз данных BIG), то же самое заняло чуть более 16 часов. Просматривая журналы и проводя сетевую трассировку, мы обнаружили, что приложение делало около 15.000 выборок в секунду в системе dev, и задержка в 0.3 мс между сервером приложений и базой данных ограничивала это чуть более 3000 выборок в секунду. Разработчикам было приказано изменить способ доступа к базе данных (выполнить объединение двух таблиц вместо выбора одной, затем выбор одной строки для каждого из результатов), в результате чего вся операция заняла менее 30 минут.
Дело в том, что проблема, с которой вы сталкиваетесь, необычна, возможно, связана с тем, что ваше программное обеспечение ведет себя необычным образом, и вам действительно следует выяснить, что здесь происходит, и почему установка с двумя машинами была намного медленнее.
Разделение на 2 машины, как правило, должно повысить производительность, поскольку у вас больше процессоров для выполнения этой работы. Это также повышает ремонтопригодность. Для вашей базы данных может потребоваться специальный параметр ядра или уровень исправления; Ваш веб-сервер может иметь противоречивые требования. И всякий раз, когда вы выполняете обновление, гораздо проще иметь возможность обновить одну из двух систем, не касаясь другой.