Сайт очень медленно реагирует при использовании удаленной базы данных.

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

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

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

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

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

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

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

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

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

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

Положительные моменты:

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

Отрицательные моменты:

• Увеличенная сложность
• Увеличенные затраты на дополнительные ресурсы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Способы снижения задержки включают

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

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

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

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

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

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

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

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