MySQL + PHP. Допоможіть вирішити проблему

Вітаю. Маю проблему такого характеру. Є два сервера. Один в Штатах (веб-сервер) і другий в Німеччині (mysql). Пінг доволі адекватний в межах 7-9 мс. Канал 200 мегабіт. Як тільки пробую відкрити сайт (наприклад wordpress)то час завантаження 30 секунд. Як пробую локально розміщувати БД на вебсервері то все ок. skip name resolve встановив, все ніби зробив, щоб працювало швидкео, але це просто дурдом. Взагалі серверів багато і БД будуть в реплікації, а вебсервера в синхронізації в режимі реального часу, але це буде після того, як вирішу цю проблему. Раніше тримали сервера всередині локальної мережі в Датацентрі в Харькові, але через напад мордовії, довелось швидко мігрувати сервера в світ і стикнувся тепер з такою проблемою.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Расстояние от Нью-Йорка до Берлина свет преодолевает за 20 мс. В обе стороны — 40 мс. Так что пинг у вас явно куда-то не туда идет.

Как уже писали — 30 секунд слишком аккуратное время, если именно 30 секунд занимает — ищите, что у вас еще происходит, потому что действительно выглядит как таймаут, может WP у вас Redis пытается искать какой-то например.

Если же не точно 30 секунд — поставьте какой-нибудь профайлер и посмотрите, что и сколько времени занимает. Blackfire какой-нибудь, например.

Є два сервера. Один в Штатах (веб-сервер) і другий в Німеччині (mysql). Пінг доволі адекватний в межах 7-9 мс.

pics or it never happened
как это вообще возможно ? внутри страны ~10-15 мс, а у тебя через атлантику 10 ?

Є два сервера. Один в Штатах (веб-сервер) і другий в Німеччині (mysql).

один вопрос — зачем ?
какие «+» из этого ?

Проблема не в MySQL. Проблема в ТЗ и Физике:

1. ТЗ — непонятна финальная цель
2. Физика — gist.github.com/jboner/2841832

А підкажіть ще може хтось працював з реплікаціями БД. Зараз налаштована реплікація між двома серверами Master-Master. Хочу побудувати аналогічну інфраструктуру серверів в іншій країні і щоб перша гілка передавала на другу дані по типу:
Master(Finland)->Master(Finland)->Master(USA)->Master(USA) можливо далі ще буде Німеччина. Які налаштування потрібно провести на серверах, щоб була можливість саме робити поєднання 4-х мастер-серверів?

А от точно так же, як ви робили М-М реплікацію, ви можете також зробити, щоб у вас був такий ланцюг — коли кожний Master є Slave для попереднього. Просто ви тоді не врубаєте Slave на попередньому Master, і все. (UPD — а, неправильно написав, тут вам потрібно робити кільце). Чи я неправильно зрозумів, и ви хочете два М-М кластери, щоб один в Фін, а другий в США?

UPD — чи всі 4 Master? Ви повинні бути впевнені, что дані будуть різні, без дублювання. Це складніше. Якщо залишатись в рамках стандартної процедури реплікації, це може бути топологія «кільце». Але думаю, слід дивитись в бік Galera Cluster чи подібного.
UPD2 — мало хто робить MultiMaster на дефолтному механізмі реплікації, тому що ви ризикуєте отримати розсинхрон, якщо впаде один з серверів надовго. Каскадне взаємооновлення (два M-M кластери) виглядає надійніше. Також майте на увазі, що я «зварювальник несправжній» — в проді таке не робив, тільки на віртуалках балувався в учбових цілях. Тож хай мене хто поправить, якщо є DBA.

З Wordpress пригадую пару проблем з практики:
1. Без query_cache кілька разів підряд виконувався довгий запит, сайт вмирав по 504. Увіткнули query_cache — покращало, але все ще погано.
2. Були погані індекси в БД — використали плагін Index WP MySQL For Speed. В результаті поганий запит виконується 3 — 4 секунди замість 50+. Автори плагіну написали статтю, як внести такі самі зміни вручну.

Ви можете перевірити за допомогою mysqladmin, чи ваш цей випадок — треба дивитись, в якому саме статусі висить довгий запит. Підозрюю, що кеш не працює вірно, якщо звернення йде по мережі, але тут вже діагностика на місці потрібна.

Це дуже погана ідея розміщувати так інфраструктуру. Ви розумієте скільки запитів до бд продукується під час одного реквесту? А ще те що кожен tcp пакет буде мати той пінг що ви сказали. Хоча мені не віриться що через пів світу у вас пінг всього 9мс.
Швидкість світла 300000000 м/с відстань від штатів до Німеччини десь 12000км в метрах це 12000000 тобто сигнал в один бік фізично летить 0.04с і це тільки один пакет і в один бік. Ще стільки треба на повернення сигналу. А ще є затримки 1-2мс на кожному вузловому маршрутизаторі.
Отже з фізикою і теорією трохи розібрались.
Що можна зробити як адхок рішення:
— Поставити кеш на запити. Редіс або мемкеш поруч з веб сервером
— оптимізувати кількість запитів до мінімума. Робити агреговані запити замість окремих. Жадна загрузка
— поставити веб сервер поруч з бд і ще один реверс проксі вже в штатах. Це буде найшвидший варіант. Так як оверхед спілкування з бд буде локальним, а пінг затратне тільки результат обробки реквеста

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

Я вже перепробував сотню варіантів і жоден не спрацював. Тому буду десь розміщувати на території одного дата центру все це. З кешом звичайно теж хороший варіант, але проблема, що INSERT запитів багато і в цьому випадку він мене не врятує. Раніше до вторгнення мордору все було супер. Віртуальна мережа в межах одного дата-центру, всі сервера поряд, працювало на ура. А потім наш дата-центр розбомбили в Харкові і довелось все швидко мігрувати закордон. Тут я вже і вирішив, що варто б зробити щось краще по інфраструктурі. Побудував реплікації Мастер-Мастер-Слейв-Слейв. Синхронізації поробив файлової системи. І бац, спіткнувся на затримках. Завтра буду напевно в Штатах формувати один блок серверів і резервний в Німеччині. А як наступить мир в Україні і вимре орда то повернусь в рідний дата-центр в Харків.

По інсертам, якщо можна розглянути балк інсерт — то це теж гарний імпрув

Прикольна штука, але судячи з коду pdo то виграш лише на ініціалізації з‘єднання. А підкажіть ще може в курсі — хетцнер дата центр, варто з ними працювати?

А підкажіть ще може в курсі — хетцнер дата центр, варто з ними працювати?

нормальний провайдер, можна працювати

Я ще доречі розмірковував побудувати віртуальну мережу через VPN, але навряд мене врятує цей варіант, а часу затратити доведеться порядно, що це все налаштувати

30с слишком характерное время, у вас явно что-то по таймауту отввливается. И скорее всего даже не мускуль.
ПС. Мне бы сейчас такие «проблемы»)

Та ні, якраз мускул точно. Просто ніколи не міг повірити, що будуть такі затримки

И правильно не могли, схема ущербная но рабочая. У мен, есть Легаси проект в таком варианте, там правда не ВордПресс но схема именно такая (не от меня зависит) и оно все вполне ворочается

Я дуже хотів побудувати мережу яка б дозволяла балансувати навантаження виходячи з геолокації користувача. Але з такими затримками, думаю навіть реплікація буде гальмувати. Може я не врахував чогось і тому в мене таке провисання. Або ще як варіант хост провайдер тормозить

Може спочатку зробити тест без wordpress. Можливо з ним справа. Напишiть окремий файл с тестовим запитом до бази данних.

Робив. Написав голу сторінку з простим підключенням до БД і затрачено 3 секунди на з’єднання. Але коли беру нашу фронт систему з АПІ де більше запитів та і даних бігає то час збільшується до декількох хвилин

навісити на німецький сервак API чи там GraphQL )) всі запити шоб не гуляли між клієнтом і сервером для одного рефреша сторінки їх може бути сотні в обидві сторони.

а найпросіше пересунути базу до веб-сервера

А в чому логіка позначення БД/апп по різним серверам світу? Наскільки пам’ятаю wordpress за 1 запит на сервер робить на порядок більше запитів до БД

Вордпрес це лише сайт візитка компанії. Суть вся в фронт-системі

Підписатись на коментарі