Друзья! кто знает как подкрутить myslq что бы 300-700 запросов за один request на сервер выполнялись с приемлимой скоростью. у меня на это уходит 3-5 секунд (mac), на сервере примерно так же (ubuntu), а у коллеги на windows в районе 150ms. Значит дело в каких то конфигах или это внутренняя реализация рабоыт с памятью разных систем? Мб есть какая то конфигурация для большого кол-ва запросов? сами запросы достаточно хорошо оптимизированы индексы и все такое

у mysql много узких мест, тут профилировать надо, смотреть железо

найди вот эту книгу в интернете, там есть главы посвященные настройкам

https://www.ozon.ru/context/detail/id/145190140/

правда русский перевод достаточно устаревший, там mysql версии 5.6 разбирается, но конкретно тюнинг не сильно отличается

а 300-700 запросов на 1 реквест это не много? Или я не так прочитал эту фразу?

спс, возьму на заметку

ваще рекомендую прочитать книгу полностью) она довольно объемная, но там mysql с потрохами разбирается)

это много. но там по другому сложно сделать.  когда нибудь это перепишем, логика слишком сложная.

у тебя не myisam случайно подсистема?

InnoDB

кэширование кстати тоже не помогает, уже пробовал

Просто у мускуля действительно очень много узких мест, начиная от захвата семафоров, заканчивая там уже совсем адскими вещами, типа горячего сброса файлов журнала на диск

поэтому лучше выбирать постгрес и не париться)

есть мнение, чт опереписать будет проще, чем настроить mysql :)

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

но пришел то ты с проблемой мускуля)

смотри что показывает SHOW ENGINE INNODB STATUS

не уверен. у коллеги не сильно мощный комп и стандартный mysql  из опенсервера. у него 150-200ms на весь reques. думаю можно что то нарыть не сложное

ну эт опока данных немного. пока нет параллельных запросов...

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