Мы разрабатываем наше веб-приложение и работаем над сокращением времени загрузки. Когда мы начали разработку приложения, мы подписались на известного хостинг-провайдера, предлагающего «выделенные решения» в облаке. В результате у нас есть один выделенный сервер для нашего веб-приложения и один выделенный сервер для нашей базы данных. Оба сервера были настроены с одинаковым объемом оперативной памяти, одинаковыми процессорами и твердотельными накопителями. Даже с вложением времени и денег в нашу инфраструктуру мы заметили время загрузки 8–10 секунд.
Другая хостинговая компания посоветовала нам уменьшить масштаб и разместить все на одном сервере (вместо того, чтобы разделять его). Они упомянули, что разделение серверов приведет к увеличению времени загрузки из-за задержки в сети, и заявили, что PHP будет быстрее взаимодействовать с SQL через сокеты, чем по сети. Я знаю, что это правда, но я не ожидал результатов, которые мы получили. Сразу после переноса всего на наш исходный сервер приложений время загрузки упало с 8-10 до 3-4 секунд!
Проблема в том, что сейчас мы ищем нового хостинг-провайдера, и нам посоветовали использовать кластер с балансировщиком нагрузки, сервером базы данных, сервером приложений и масштабированием оттуда. Беспокойство заключается в том, что если мы снова разделим приложение и сервер базы данных, мы вернемся к исходной точке.
Из всего, что я читал, кажется, что почти всегда рекомендуется разделять эти серверы, а не группировать их вместе. Есть ли прирост производительности при правильной настройке или это просто для масштабируемости в долгосрочной перспективе?
Я ценю помощь!
Ваш вопрос очень широкий, поэтому я просто упомяну несколько аспектов:
ввод-вывод локального сокета быстрее, чем TCP, но для большинства приложений он должен быть минимальным по сравнению со всеми другими частями вашего рабочего времени (балансировщик нагрузки, обработка PHP, обработка запросов к БД, ...)
сплит-системы позволяют лучше кэшировать, например сервер БД может хранить больше индексов в ОЗУ.
возможно, точка масштабируемости: сплит-системы проще настраивать, например чтобы развернуть новую версию программного обеспечения или обновить PHP, вы можете просто добавить новый сервер приложений, протестировать его и, наконец, удалить старый.
для исследования ваших проблем: проверьте, сколько соединений с БД открывается для каждого веб-запроса. Одним из объяснений ваших измерений может быть приложение, использующее много SQL-запросы без постоянных соединений, поэтому новое TCP-соединение открывается для каждого доступа к БД.
Я не знаю, что вы делаете, чтобы получить время загрузки 8-10 секунд (при условии, что вы определяете «время загрузки» как «время между поступлением HTTP-запроса и созданием страницы и ее отправкой в браузер»).
У вас не должно быть возможности довести ваши процессоры до 100% использования с веб-сервером и базой данных, и даже если вы каким-то образом справитесь с этим, размещение веб-сервера и базы данных на одном сервере не поможет.
Кроме того, любая перегрузка на сервере БД не будет уменьшена путем перемещения обоих серверов на одно и то же оборудование.
Итак, проблема почти связана с
Может быть, это что-то еще, чего я не могу себе представить в данный момент, потому что очень редко типичное веб-приложение становится медленнее, когда вы распределяете его по большему количеству процессоров, если эти процессоры имеют быстрое сетевое соединение между собой.
До тех пор, пока вы не выясните, что вызывает проблемы на разных хостах, у вас может быть та же проблема снова, а может и нет.
В прошлом году у меня возникла проблема первого типа - мой заказчик заключил контракт с третьей стороной на разработку для него программного обеспечения. Обычная операция на демонстрационном ноутбуке длилась около 4 часов. Когда мой клиент переместил программное обеспечение в предполагаемую производственную среду (БОЛЬШОЙ сервер приложений, БОЛЬШОЙ кластер базы данных), то же самое заняло чуть более 16 часов. Просматривая журналы и выполняя трассировку сети, мы обнаружили, что приложение сделало около 15 000 выборок в секунду в системе разработки, а задержка 0,3 мс между сервером приложений и базой данных ограничила это значение чуть более 3000 выборок в секунду. Разработчикам было сказано изменить способ доступа к базе данных (выполнить объединение двух таблиц вместо выбора в одной, затем выбор одной строки для каждого результата), в результате чего вся операция заняла менее 30 минут.
Дело в том, что проблемы, которые у вас возникают, необычны, могут быть связаны с вашим программным обеспечением, которое ведет себя необычным образом, и вам действительно следует изучить, что здесь происходит, и Зачем установка с двумя машинами была намного медленнее.
Разделение на 2 машины должен обычно улучшает производительность, потому что у вас больше процессоров для выполнения этой работы. Это также увеличивает ремонтопригодность. Для правильной работы вашей базе данных может потребоваться специальный параметр ядра или уровень исправления; у вашего веб-сервера могут быть противоречивые требования. И всякий раз, когда вы выполняете обновление, гораздо проще иметь возможность обновить одну из двух систем, не касаясь другой.