Mysql удаленный тормозит больше чем локальный

А настройки-то одинаковые? Профайлинг чо показывает? https://ruhighload.com/Как использовать show profile в mysql?

Запросы через одно соединение передаются или на каждый новое создается?

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

1 не настроен innodb, буфер должен быть побольше

2 медленный диск

3 на удаленный сервер есть паузы между запрсами для сетевого соединения передачи, каждый запрос создает и рвет tcp соединение

Возможно это поможет, но оно имеет побочные эффекты

http://php.net/manual/ru/features.persistent-connections.php

https://yiiframework.ru/forum/viewtopic.php?t=35626

slow log смотрел на удаленном, там мизерные совсем query time, около 0.0001

1. Сам mysql ещё не тюнинговал. Разве буферы повлияют, если в 1 таблице 1 запись и я на ней тестирую?

2. Диск SSD, а на локальном SATA, всяко разно он быстрее будет

3. Соединение создается одно, только при конекте, дальше я посылаю запросы уже в это соединение. Разве не так?

Это я знаю, но я на 1 соединении пока тестирую

А пинг между хостами какой? Сетевые задержки — самый очевидный подозреваемый

skip-name-resolve?

пинг 27.4 ms
на соединение тратится мало, около 0.07s

делал это

Еще может повлиять скорость проца и памяти, на хостингах как правило с этим проблемы, производительность дешевых как правило хреновая

Ну и explain запросов надо бы посмотреть

Потому что удалённое железо говно. Поменяй провайдера или тариф, обычно топовые тарифы виртуалок ничего. Во вторую очередь накладываются задержки, 0.07с это дальше чем от мск до сша, такие вещи делаются только в одной локалке.

Не в запросах дело, в таблице тупо 1 запись и он(запрос) выполняется 0.2 сек, что оооч долго на пустом сервере

С чего взял что виртуалка и железо плохое? Обычный сервер, проц i7, ssd

Не в запросах дело, в таблице тупо 1 запись и он(запрос) выполняется 0.2 сек, что оооч долго на пустом сервере

Скорей всего DNS

Нужна опция skip-name-resolve

Пинг проверь.

Так соединяется 1 раз же? Проверка IP идет при соединении же, а не при запросах?

Опция эта прописана в server.cnf вроде правильно

[mysqld]
skip-name-resolve

ping 24.0 ms

У нас так недавно оракл тормозил. Разница в 2 раза между боевым и тестовым сервером. Разница по пингу - в 6 раз. (2ms/0.3ms-0.4ms) Проблема была или в том что скорость 50мбит или еще что-то (админы не признаются). Короче пинг там критичен, как я понял.

http://php.net/manual/ru/features.persistent-connections.php

на соединение тратится мало, около 0.07s

Там, вроде, tcp и это может сильно влиять на итоговую скорость запросов. Зачем тебе вообще mysql где-то далеко, а не на локалхосте?

Он решил размазаться (см. его предыдущие треды).

Не не, это не правильная распределёнка. У нас тут бд с app серваком через один роутер - и то проблемы, а у него там php с orm и перебор объектов в цикле с запросом к базе на каждый чих. И база где-то в жопе через кучу роутеров.

Прикинь, там orm-говноцикл вместо update/select на 100 записей и каждая будет 24ms соединяться с бд.

Нет там никаких orm-циклов. Да и зачем соединяться то каждый раз? Соединение 1 раз устанавливается в начале работы

Да, я уже начинаю понимать, что это не очень хорошая идея ) Хотя тут Mysql на другом сервере мне сказали что норм и так делают...

Так ты как-то не правильно делаешь. Перепроверь всё еще раз 10.

Ну и чисто пукну: размажь чутка иначе — каждый бекенд с слейв-сикелем на одной машинке, а мастер-сикель на отдельной. Ты понимаешь о чем я?

У нас тут бд с app серваком через один роутер - и то проблемы

Это то что ты выше описывал с ораклом?

Версия бд какая? Бага есть такая, ага.

Да проверяю второй день
Т.е. предлагаешь завести второй бекенд?

Значит ты не понял. Иди читай: https://ruhighload.com/Репликация данных

Посмотрел лог всех запросов, помимо самих sql делаются ещё

administrator command: Prepare
administrator command: Close stmt

Подготавливаемые (или параметризованные) запросы используются для повышения эффективности, когда один запрос выполняется многократно.

На этапе подготовки на сервер посылается шаблон запроса. Сервер выполняет синтаксическую проверку этого шаблона, строит план выполнения запроса и выделяет под него ресурсы.

Use http://php.net/manual/ru/pdo.query.php Luke.

Ага.

Нет там никаких orm-циклов.

Да есть. Это суть любой orm.

Да и зачем соединяться то каждый раз? Соединение 1 раз устанавливается в начале работы

Тебе передать данные надо? По tcp ответ получить, что данные дошли надо? Это минимум 24ms.

Т.е. предлагаешь завести второй бекенд?

Я предлагаю n+1 бекендов, где n>0. Бекенды тоже размазать по функционалу, где возможно. Хотя для проектов масштабов php это всё лишнее.

Да ты прав, в цикле пользователи и прочее цепляются, бывает иногда 1 страница 100 запросов генерирует. Каждый запрос минимум 0.05с и страница открывается 5 сек. Запросы эти конечно можно сократить, но даже если их будет в 5 раз меньше, все равно задержка будет ацкая )

А бакенд со слейв данные в мастер записывать будет, так? А еще сессии и файлы нужно как то хранить централизованно, ты про это?

Если уж размазывать, то по идее, выкидывается orm делается какое-нибудь api, которое дёргает микросервис провайдер данных (n+1 штук за прокси провайдером:), а он уже одним куском всё выплёвывает что надо. Но надо ли это делать для магазина на 100 позиций с 3.5 посетителями в час.

У тебя на сессии получается один микросервис, на данные другой, на файлы третий, веб-контроллер, который всем этим рулит - четвёртый, все эти три могут быть в нескольких экземплярах, общение через rabbitmq, который может быть тоже в нескольких экземплярах, распределёнка во все поля, короче. (man pipeline архитектура, микросервисы) Но я не знаю, как на php сделать сервис (и нужно ли), который будет всегда запущен и принимать/обрабатывать запросы.

Сложно это все ) Проще надо

Сложно это с какой стороны посмотреть. Логика размазанная по сраной многослойке в понимании куда сложнее, чем pipeline.