PHP получает количество MySQL запросов в час
Короткий:
Есть ли способ получить количество запросов, которые были выполнены в течение определенного промежутка времени (через PHP) эффективным способом?
Полный:
В настоящее время я использую API для веб-приложения внешнего интерфейса, которое будет использоваться большим количеством пользователей.
Я использую свою собственную платформу, которая использует модели для создания магии данных, и они в основном выполняют INSERT и SELECT. Одна функция модели может выполнять от 5 до 10 запросов по запросу, а другая функция может выполнять 50 или более запросов.
В настоящее время у меня нет способа проверить, «убиваю» ли я свой сервер, выполняя (например) 500 запросов каждую секунду.
Я также не хочу сюрпризов, когда количество пользователей увеличивается до 200, 500, 1000, … в течение первой недели и, возможно, до 10.000 к концу месяца.
Я хочу получать какую-то статистику за час, чтобы у меня было представление о среднем и, возможно, я смогу поработать над производительностью и эффективностью, прежде чем все рухнет. Объедините несколько запросов в один «больший» или тому подобное.
Посты, которые я прочитал, предложили просто сохранить счетчик в моем коде, но это потребовало бы большего количества запросов, просто чтобы иметь номер. Предпочтительным способом было бы добавить селектор в мой скрипт почасовой статистики, который возвращает мне количество запросов, которые были выполнены для x-количества обработанных запросов.
Заключить.
Есть ли другие варианты, чтобы отслеживать эту сумму?
дополнительный. Должен ли я беспокоиться о количестве запросов? Все они маленькие, просто для быстрого выполнения без узких мест или тяжелых вычислений, и в настоящее время я впечатлен тем, насколько быстро все работает!
Extra Extra. Он находится на нашем собственном VPS-сервере, поэтому у меня есть полный доступ, и я не ограничен «основными» функциями или командами или чем-то в этом роде.
Решение
Короткий ответ: Используйте медленный журнал.
Полный ответ:
В начале и в конце периода времени выполните
SELECT VARIABLE_VALUE AS Questions
FROM information_schema.GLOBAL_STATUS
WHERE VARIABLE_NAME = 'Questions';
Тогда возьми разницу.
Если сроки не точны, также получите ... WHERE VARIABLE_NAME = 'Uptime' чтобы получить время (ко второму)
Но проблема … 500 очень быстрых запросов могут быть не такими проблемными, как 5 очень медленных и сложных запросов. Я полагаю, что прошедшее время может быть лучшим показателем для принятия решения, убивать ли кого-то.
И … убийство в процессе может привести к удивительной ситуации, когда непослушное заявление остается в состоянии «убийства» в течение длительного времени. (Увидеть SHOW PROCESSLIST.) Причина этого может Случается так, что заявление необходимо отменить, чтобы сохранить целостность данных. Примером является один UPDATE оператор, который изменяет все строки таблицы с миллионами строк.
Если вы делаете Kill в такой ситуации, вероятно, лучше дать ему закончить.
В другом направлении, если у вас есть, скажем, один ряд UPDATE который не использует индекс, но нуждается в просмотре таблицы, тогда запрос займет много времени и, возможно, будет более тяжелым для системы, чем «500 запросов». «Лекарство», вероятно, будет добавлять INDEX,
Что делать со всем этим? Используйте медленный журнал. Задавать long_query_time в какой-то небольшой стоимости. По умолчанию установлено значение 10 (секунд); это почти бесполезно. Измените это на 1 или даже что-то меньшее. Тогда следите за медленным журналом. Я считаю, что это лучший способ следить за выходом системы из-под контроля а также сказать вам, что работать над ремонтом. Больше обсуждения: http://mysql.rjweb.org/doc.php/mysql_analysis#slow_queries_and_slowlog
Обратите внимание, что лучший показатель в замедленном журнале — это не количество выполненных запросов и не длительность их выполнения, а результат двух. Это по умолчанию для pt-query-digest, За mysqlslowdump, добавив -s t результаты сортируются в указанном порядке.
Другие решения
Других решений пока нет …