Нахождение узкого места производительности в сценариях Python и MySQL

Question

У меня есть скрипт с основным циклом for, который повторяется около 15 тыс. Раз. В этом цикле он запрашивает локальную базу данных MySQL и обновляет SVN в локальном хранилище. Я поместил SVN-репозиторий на RAM-диск, так как раньше большую часть времени казалось на чтение / запись на диск.

Теперь у меня есть скрипт, который работает в основном с той же скоростью, но загрузка ЦП для этого скрипта никогда не превышает 10%.

ProcessExplorer показывает, что mysqld также не занимает почти никакого процессорного времени или много читает / записывает на диск.

Какие шаги вы бы предприняли, чтобы выяснить, где находится узкое место?

Answer 1

Выполнение SQL-запросов в цикле for 15 000 раз является узким местом в каждом языке.

Есть ли причина, по которой вы спрашиваете каждый раз снова? Если вы выполните один запрос перед циклом for, а затем зациклите набор результатов и часть SVN, вы увидите резкое увеличение скорости.

Но я сомневаюсь, что вы получите более высокую загрузку процессора. Причина в том, что вы не делаете расчеты, но в основном IO. Кстати, вы не можете измерить это при использовании процессора mysqld, так как в фактическом коде не сложность запросов, а их количество и задержка серверного ядра для ответа. Таким образом, вы увидите только очень короткие, не дорогие запросы, которые суммируются во времени.

Answer 2

Хорошо известно, так сказать, что svn update ждет целую секунду после завершения работы, так что временные метки изменения файла оказываются "в прошлом" (поскольку многие файловые системы не имеют временная гранулярность менее одной секунды). Вы можете найти больше информации об этом в Google, чтобы найти svn sleep_for_timestamps.

У меня нет очевидного решения, чтобы предложить. Если это действительно критично для производительности, вы можете: 1) не обновлять так часто, как вы делаете 2) попробовать использовать низкоуровневый API Subversion (удачи).

Answer 3

Профилируйте свой код Python. Это покажет вам, сколько времени занимает каждый вызов функции / метода. Если это вызов метода, запрашивающий базу данных MySQL, вы будете иметь представление, где искать. Но это также может быть что-то еще. В любом случае, профилирование - это обычный подход к решению таких проблем.