то всегда будет работать интерпретатор, а оптимизации в v8 работают только в jit
очень важный момент, спасибо!
Использовал в тесте eval так как, мне когда то советовали для более достоверного теста
А теперь кажется понял, что при добавлении eval, получается можно тестить на скорость интерпретатор
а без него jit.... я правильно понял?? поправьте пожалуйста...
Антон Антон, логи тоже проверю, и на счет innodb_flush_log_at_trx_commit тоже спасибо за подсказку.
Вообще спасибо за полезный ответ! Как глоток свежей воды :) respect !
Akina, как понял, очистка памяти... и смотрел в других примерах эти показатели на порядок меньше... (статьи о profile)
freeing items 0.000020
cleaning up 0.000008
да спасибо, была мысль в редиску горячие данные пересадить... но все же есть надежда на mysql...
вот реально если надо сделать 300 запросов по id и разных таблиц, то ~200-300ms.. ну грустно это, неужели БД не может работать быстрее?
Роман Мирр, конечно where in используется когда это возможно. но в данном случае данные нужно тянуть из разных таблицы, плюс некоторые структуры нужно рекурсивно распутывать...
но это уже предменая область, меня интересует, возможность настроить так что бы простые запросы на чтение работали быстрее. при том что в данном примере, половина времени уходит на чистку.
ky0, текущий проект ориентирован на высокие нагрузки, и выходит что 20 запросов к базе по ходу выполнения одного скрипта, занимает ~20ms, есть подозрение что это можно ускорить, но на текущий момент не нашел как это сделать.
без transaction 258.55ms
с transaction 176.83ms
сделал еще пачку тестов, получилось в среднем прирост производительности 20%
Странно немного... Понять бы что происходит.