Веб-сайт отвечает очень медленно, используя удаленную базу данных

Я хочу, чтобы два одинаковых веб-сайта использовали одну базу данных. Один сервер находится в Азии, на нем размещается веб-сайт и база данных. Другой сервер находится в США, на нем размещена та же сеть через удаленную базу данных. Однако сеть в США отвечает очень медленно, но при перемещении базы данных на локальный сервер (сервер в США) сеть отвечает быстро. Как ускорить соединение между сервером в США и базой данных в Азии?

Я использую Centos7+Nginx+MySQL.

Как ускорить соединение между сервером в США и базой данных в Азии?

Вы, наверное, не можете. США-Азия - это большое расстояние, и это связано с задержкой. Проще говоря: свет имеет конечную скорость.

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

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

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

Если этого недостаточно или невозможно, вам нужно каким-то образом уменьшить задержку между веб-сервером и базой данных, либо путем репликации БД, чтобы вы могли иметь локальную копию, кэшируя некоторые «горячие» ее части, которые не часто меняться или различные другие вещи, такие как кеширование окончательного вывода веб-сервера или другие вещи, которые может делать CDN (см. ответ vidarlo).

Вы не можете улучшить скорость света. _{{нужна цитата}}

Вместо межконтинентальных запросов вам, возможно, придется изучить любую репликацию, которую предлагает MySQL. Вам понадобится веб-сервер и сервер базы данных в Азии, дублированные в каждом месте (США, ЕС, Африка, Ближний Восток и т. д.). Когда веб-сервер записывает, локальная БД немедленно обновляется, и это обновление затем передается на удаленные серверы БД MySQL внутри.

Положительные стороны:

• Сеансы пользователей могут переключаться с одного сайта на другой, а их записи в базе данных будут непротиворечивыми.
• Вам нужно только создать резервную копию одного сервера базы данных, чтобы получить партию.
• Можно добавить избыточность и отказоустойчивость за счет наличия основного сайта, а если он выйдет из строя, переключиться на удаленный сайт.
• Можно горизонтально масштабировать веб-серверы на каждом сайте, чтобы обеспечить обслуживание во время простоя, например обновления/перезагрузки.
• Вы даже можете иметь резервный сервер БД локально для каждого сайта, что опять же обеспечивает избыточность без необходимости аварийного переключения.

Минусы:

• Добавленная сложность
• Увеличение стоимости большего количества ресурсов

В конечном счете, это проблема проектирования инфраструктуры, а не веб-сервера.

Обычный дизайн веб-сайта, поддерживаемого базой данных, использует несколько (или намного больше, например, 50 или 100) запросов к базе данных для создания одной веб-страницы в ответ на запрос браузера.

Каждый из этих запросов, один за другим, требует времени прохождения туда и обратно между веб-сервером и сервером базы данных. Это может быстро добавить.

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

Увидеть разницу? 2 обращения пользователя к серверу и обратно против нескольких (вероятно, десятков) обращений сервер-сервер. Соединение между серверами может быть быстрее, но не намного.

Вот почему ваша установка вообще бессмысленна.

Что же тогда можно сделать?

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

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

Да, бывают случаи, когда основное глобальное магистральное соединение не работает, и соединения между, например. Китай и Европа становятся настоящей проблемой, но если произойдет такое неприятное событие, соединение между вашим веб-сервером и вашим сервером базы данных будет в равной степени затронуто. И это на самом деле хуже, чем замедление соединения между вашим веб-сервером и вашими пользователями, см. выше.

Существуют уловки CDN, которые могут улучшить время отклика даже с одним сервером, создавая впечатление, что у вас несколько серверов в разных местах. У крупных провайдеров CDN, таких как Cloudflare или Akamai, есть действительно мощные инструменты.

2. Используйте репликацию базы данных и поддерживайте базу данных рядом с обоими веб-серверами. Это может потребовать глубокого переосмысления дизайна приложения, а также гораздо более широкого набора навыков и/или более дорогих лицензий на БД.

3. Проверьте свойства подключения к базе данных на обоих концах (сервер базы данных и веб-сервер).

• Обширное ведение журнала, сложная аутентификация и обратный DNS на стороне сервера БД могут в значительной степени отставать от результатов каждого запроса к БД.
• Использование постоянных подключений к базе данных на стороне веб-сервера может сократить количество запросов к базе данных в 2-5 раз.

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

Distance не делает базу данных медленнее, она просто увеличивает задержку.

меры по уменьшению задержки включают

• параллельное выполнение нескольких запросов
• уменьшение количества необходимых запросов
• кэширование результатов локально
• локальное хранение копии базы данных только для чтения

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

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

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

Другой альтернативой является проксирование запроса. С помощью прокси-сервера вы можете настроить веб-сервер в США для ретрансляции на азиатский веб-сервер, локальный для базы данных. Апач определенно может это сделать, и я верю, что Nginx тоже может (но я гораздо меньше знаком с конфигурацией Nginx). Это устранит проблемы с повторяющимися медленными обменами между веб-сервером и базой данных за счет добавления прокси-соединения поверх него. Но прокси-связь может быть одной парой запрос/ответ, что, как правило, будет быстрее.

Вы можете сделать это, если репликация, кэширование или сокращение запросов по какой-либо причине слишком сложны. Настройка прокси-сервера сравнительно проста и не требует изменения логики приложения (в отличие от кэширования и сокращения запросов). Я также считаю, что это более эффективно, чем простое сокращение запросов. Потому что прокси-сервер по сути сводится к одному удаленному запросу, тогда как у вас, вероятно, все еще будет несколько запросов к базе данных.

Проксирование также позволяет избежать репликации в обоих направлениях. Если и локальный (США), и удаленный (азиатский) веб-серверы выполняют операции записи, может быть проще выполнить все операции записи непосредственно на полномочном сервере базы данных. Это позволяет избежать проблемы конфликтующих правок, когда каждое из них пытается перезаписать друг друга на расстоянии. Но теперь мы потенциально можем вернуться к выполнению нескольких запросов к удаленной базе данных туда и обратно (хотя и меньше). С прокси вам гарантирован только один запрос/ответ на загрузку страницы.

Это также дает некоторые преимущества по сравнению с постоянным использованием удаленного (азиатского) веб-сервера напрямую. Если какой-то контент является динамическим, и вы проксируете только этот контент, ваш локальный (США) сервер все равно может предоставить весь статический контент. Конечно, вам может быть лучше с CDN для статического контента и прямого доступа клиента к азиатскому веб-серверу.