Ich arbeite an einer großen Django (v1.5.1) -Anwendung, die mehrere Anwendungsserver, MySQL-Server usw. enthält. Bevor ich NewRelic auf allen Servern austrage, möchte ich eine Vorstellung davon haben, welche Art von Overhead ich aufwenden werde Transaktion.
Wenn möglich, möchte ich sogar zwischen der Anwendungsverfolgung und der Serverüberwachung unterscheiden, die ideal wäre.
Kennt jemand dafür allgemein akzeptierte Zahlen? Vielleicht eine Website, die diese Art von Untersuchung oder Schritte durchführt, so dass wir die Untersuchung selbst durchführen können.
Für den Python-Agenten und die Überwachung einer Django-Webanwendung wird der Overhead pro Anforderung durch die Anzahl der Funktionen bestimmt, die innerhalb einer bestimmten Anfrage ausgeführt werden, die instrumentiert sind. Dies liegt daran, dass keine vollständige Profilerstellung durchgeführt wird. Stattdessen werden nur bestimmte Funktionen von Interesse instrumentiert. Es ist daher nur der Aufwand, einen Wrapper für diesen einen Funktionsaufruf auszuführen, nicht verschachtelte Aufrufe, es sei denn, diese verschachtelten Funktionen waren wiederum diejenigen, die instrumentiert wurden.
Spezifische Funktionen, die in Django instrumentiert werden, sind die Middleware- und View-Handler-Funktion sowie das Template-Rendering und die Funktion innerhalb des Template-Renderers, die sich mit jedem Template-Block beschäftigt. Im Unterschied zu Django selbst verfügen Sie über Funktionen für die Datenbankmodul-Client-Modulfunktionen zum Ausführen einer Abfrage sowie über Memcache- und Web-Externals usw.
Dies bedeutet, dass, wenn für eine bestimmte Webanforderungsausführung nur 100 instrumentierte Funktionen durchlaufen werden, nur deren Ausführung einen zusätzlichen Aufwand verursacht. Wenn stattdessen Ihr View-Handler eine große Anzahl unterschiedlicher Datenbankabfragen ausführt oder Sie eine sehr komplizierte Vorlage gerendert haben, kann die Anzahl der instrumentierten Funktionen wesentlich höher sein und der Overhead für diese Webanforderung wird daher mehr sein. Das heißt, wenn Ihr View-Handler mehr Arbeit macht, hat er im Allgemeinen bereits eine längere Antwortzeit als ein weniger komplexer.
Mit anderen Worten, der Overhead pro Anforderung ist nicht festgelegt und hängt davon ab, wie viel Arbeit ausgeführt wird oder genauer, wie viele instrumentierte Funktionen aufgerufen werden. Es ist daher nicht möglich, Dinge zu quantifizieren und Ihnen eine fixe pro Anfrage für den Overhead zu geben.
Alles in allem wird es einige Gemeinkosten geben und der angestrebte allgemeine Zielbereich liegt bei etwa 5%.
Im Allgemeinen passiert es jedoch, dass die Erkenntnisse, die aus den Leistungsmesswerten gewonnen werden, für die meisten Kunden in der Regel einige einfache Verbesserungen bedeuten, die fast sofort gefunden werden können. Wenn Sie solche Änderungen vorgenommen haben, können die Antwortzeiten sehr schnell auf Werte sinken, die vor dem Beginn der Überwachung noch nicht erreicht wurden. Sie befinden sich also weit vor dem Anfangspunkt, an dem Sie nicht überwacht wurden. Beim weiteren Graben und Tuning können Verbesserungen sogar noch dramatischer sein. Achten Sie auf bestimmte Aspekte der bereitgestellten Leistungsmetriken, und Sie können Ihren WSGI-Server besser optimieren und ihn möglicherweise besser nutzen, die Anzahl der benötigten Hosts reduzieren und so Ihre Hosting-Kosten reduzieren.