Cercando di quantificare il sovraccarico delle prestazioni del monitoraggio NewRelic nell'app python django

Question

Sto lavorando ad una grande applicazione Django (v1.5.1) che include più server di applicazioni, server MySQL ecc. Prima di distribuire NewRelic su tutti i server che voglio per avere un'idea di quale tipo di sovraccarico dovrò sostenere per transazione.

Se possibile mi piacerebbe anche distinguere tra il monitoraggio dell'applicazione e il monitoraggio del server che sarebbe l'ideale.

Qualcuno sa di numeri generalmente accettati per questo? Forse un sito che sta facendo questo tipo di indagini o passaggi in modo da poter fare le indagini da soli.

Answer 1

Per l'agente Python e il monitoraggio di un'applicazione Web Django, l'overhead per richiesta è determinato dal numero di funzioni eseguite all'interno di una specifica richiesta strumentata. Questo perché non viene eseguita una profilazione completa. Invece sono strumentate solo funzioni specifiche di interesse. È quindi solo il sovraccarico di avere un wrapper che viene eseguito per quella chiamata a una funzione, non le chiamate nidificate, a meno che quelle funzioni annidate siano a loro volta quelle che venivano strumentate.

Funzioni specifiche utilizzate in Django sono la funzione middleware e view handler, oltre al rendering di template e la funzione all'interno del renderer di template che si occupa di ogni blocco di template. Distinti da Django stesso, hai una strumentazione sulle funzioni del modulo client database di basso livello per l'esecuzione di una query, oltre memcache e web esterni ecc.

Ciò significa che se per un'esecuzione specifica di una richiesta Web vengono trasmesse solo 100 funzioni strumentate , quindi è solo l'esecuzione di quelli che comportano un sovraccarico in più. Se invece il gestore della vista eseguiva un numero elevato di query di database distinte o se si eseguiva il rendering di un modello molto complicato, il numero di funzioni strumentate potrebbe essere molto maggiore e, in tal caso, il sovraccarico per quella richiesta Web sarà maggiore. Detto questo, se il tuo gestore di view sta facendo più lavoro, allora generalmente avrà un tempo di risposta più lungo rispetto a uno meno complesso.

In altre parole, il sovraccarico per richiesta non è fisso e dipende dalla quantità di lavoro eseguita o, in particolare, dal numero di funzioni strumentate richiamate. Non è quindi possibile quantificare le cose e fornire una cifra fissa per richiesta per il sovraccarico.

Ciò detto, ci sarà un po 'di spese generali e il target target generale è di circa il 5%.

Ciò che generalmente accade è che l'intuizione che si ottiene dall'avere le metriche di prestazione significa che per la maggior parte dei clienti ci sono di solito alcuni miglioramenti abbastanza facili che possono essere trovati quasi immediatamente. Avendo apportato tali modifiche, i tempi di risposta possono essere ridotti rapidamente al di sotto di quello che erano prima di iniziare il monitoraggio, quindi si finisce per essere più avanti rispetto a quando si doveva iniziare quando non si effettuava il monitoraggio. Con ulteriori scavi e messa a punto, i miglioramenti possono essere anche molto più drammatici. Prestare attenzione a determinati aspetti delle metriche prestazionali fornite e si può anche ottimizzare il server WSGI e magari utilizzarlo meglio e ridurre il numero di host richiesti, riducendo così i costi di hosting.