Глядя на количественную оценку накладных расходов производительности NewRelic мониторинга в python django app
Я работаю над большим приложением Django (v1. 5. 1), которое включает в себя несколько серверов приложений, серверы MySQL и т. д. Прежде чем выкатывать NewRelic на все серверы, я хочу иметь представление о том, какие накладные расходы я понесу за транзакцию.
Если возможно, я хотел бы даже различать отслеживание приложений и мониторинг серверов, что было бы идеально.
Кто-нибудь знает общепринятые числа для этого? Возможно, сайт, который занимается этим видом расследование или шаги, чтобы мы могли провести расследование самостоятельно.
1 ответ:
Для агента Python и мониторинга веб-приложения Django накладные расходы на запрос определяются количеством функций, выполняемых в рамках конкретного запроса, которые инструментируются. Это происходит потому, что полное профилирование не выполняется. Вместо этого используются только конкретные функции, представляющие интерес. Таким образом, это только накладные расходы, связанные с выполнением оболочки для одного вызова функции, а не вложенных вызовов, если только эти вложенные функции не были в свою очередь теми, которые выполнялись инструментированный.
Специфическими функциями, которые инструментируются в Django, являются функция middleware и обработчик представлений, а также рендеринг шаблонов и функция внутри рендера шаблонов, которая имеет дело с каждым шаблонным блоком. В отличие от самого Django, у вас есть инструментарий на низкоуровневых функциях клиентского модуля базы данных для выполнения запроса, а также memcache и web externals и т. д.
Это означает, что если для конкретного веб-запроса выполнение прошло только через 100 инструментальные функции, то это только выполнение тех, которые несут дополнительные накладные расходы. Если вместо этого обработчик представления выполнял большое количество различных запросов к базе данных или у вас был очень сложный шаблон, то число инструментированных функций может быть намного больше, и поэтому накладные расходы для этого веб-запроса будут больше. Тем не менее, если ваш обработчик представления выполняет больше работы, то он уже обычно будет иметь большее время отклика, чем менее сложный один.
Другими словами, накладные расходы на запрос не являются фиксированными и зависят от объема выполняемой работы или, более конкретно, от количества вызываемых инструментальных функций. Поэтому невозможно количественно оценить вещи и дать вам фиксированную цифру на запрос для накладных расходов.Все это говорит о том, что будут некоторые накладные расходы, и общая дальность прицеливания составляет около 5%.
Однако обычно происходит то, что озарение, получаемое от обладания показатели производительности означают, что для большинства клиентов обычно есть некоторые довольно простые улучшения, которые можно найти почти сразу. После внесения таких изменений время отклика может быть довольно быстро снижено до уровня ниже того, что было до начала мониторинга, поэтому вы в конечном итоге окажетесь впереди того, с чего вы должны были начать, когда у вас не было мониторинга. При дальнейшем копании и настройке улучшения могут быть еще более драматичными. Обратите внимание на некоторые аспекты метрик производительности: кроме того, вы можете лучше настроить ваш сервер WSGI и, возможно, лучше использовать его, а также сократить количество требуемых хостингов и, таким образом, снизить затраты на хостинг.