In seguito agli ottimi articoli introduttivi presentati di recente su Nettuts +, questo articolo mostra come puoi portare New Relic al livello successivo. Come strumento di monitoraggio delle prestazioni, New Relic è fantastico, ma per quanto riguarda le prestazioni analisi, prima di andare a vivere. È qui che entra in gioco JMeter. In questo tutorial, vedremo come possiamo stressare la nostra applicazione sotto carico realistico e combinare l'output di JMeter e New Relic per darti sicurezza nelle prestazioni delle tue applicazioni, prima di rilasciarle in un ambiente di produzione.
Contenuto sponsorizzatoQuesto contenuto è stato commissionato da NewRelic ed è stato scritto e / o modificato dal team Tuts +. Il nostro obiettivo con i contenuti sponsorizzati è quello di pubblicare tutorial pertinenti e obiettivi, case study e interviste ispiratrici che offrono un vero valore educativo ai nostri lettori e ci consentono di finanziare la creazione di contenuti più utili.
Perché aspettare fino alla distribuzione per vedere come la tua applicazione sarà in grado di affrontare il traffico del mondo reale. Se c'è un collo di bottiglia nel codice che degrada l'esperienza dell'utente, vuoi davvero che vada in diretta? Cosa succederebbe se potessimo trovare questi colli di bottiglia in anticipo, migliorare le prestazioni e offrire una grande applicazione ai nostri utenti finali la prima volta, e mantenere ciò andando avanti con il benchmarking regolare. JMeter e New Relic insieme possono darti questa perfetta suite di test delle prestazioni.
Prima di poter iniziare a utilizzare New Relic e JMeter abbiamo bisogno di una semplice app per eseguire alcuni test delle prestazioni! Quindi, scriviamo una semplice app Ruby Sinatra che ha un servizio che possiamo testare. Non entrerò troppo nella creazione di questa applicazione, dato che puoi leggere su Sinatra in altri articoli su Nettuts+.
L'applicazione verrà simulata un po ', per permetterci di vedere alcuni risultati interessanti sulla falsariga di ciò che potremmo vedere in varie applicazioni. Scriveremo un servizio che accetta un ID e, a seconda di tale ID, restituirà un valore immediatamente o con un ritardo. Questo ci mostrerà cosa può accadere se le richieste vengono gestite rapidamente o lentamente e l'impatto che questo ha sulle prestazioni complessive delle tue app in quanto molti utenti fanno richieste.
Ecco il codice che definisce i servizi:
richiede 'sinatra' richiede 'puma' richiede modulo 'newrelic_rpm' Esempio di classe App < Sinatra::Base get '/example/:id' do |id| result = id if id == '1' result = "This is our id: #id" end if id == '2' sleep 3 result = "We waited for id: #id" end result end end end
Come potete vedere, questo è chiaramente un esempio forzato, ma l'idea è che abbiamo alcuni servizi di risposta rapida e uno con un leggero ritardo. Ora possiamo usare questa app e iniziare a scrivere il nostro piano di test delle prestazioni in JMeter. Prima assicuriamo che JMeter sia installato sulla nostra macchina.
Portare la tua segnalazione a New Relic è un processo molto semplice. New Relic supporta Ruby, Python, PHP, Java e altre piattaforme, con guide facili da seguire per tutti. Nel caso di Ruby an Sinatra, è letteralmente un processo in quattro fasi:
Una volta che hai seguito questi semplici passaggi, dovresti iniziare a vedere alcuni dati che arrivano a New Relic mentre colpisci la tua app con un po 'di traffico. Saprai che funziona quando l'app è in elenco e diventa verde.
Per completezza, elencherò solo una breve panoramica della vista principale che New Relic fornisce per le vostre applicazioni. Il design su New Relic è principalmente per monitorare le applicazioni che si trovano in ambienti di produzione con traffico in tempo reale. La schermata panoramica offre una rapida occhiata allo stato attuale della tua applicazione e al modo in cui risponde alle richieste dei clienti.
Lo schermo può essere suddiviso come segue:
JMeter è un'applicazione Java che ti consente di creare piani di test in grado di stressare la tua applicazione. Puoi impostare tutto dalla quantità di utenti simultanei del servizio, alla quantità di richieste che fanno un secondo. Puoi anche aumentare le richieste per vedere come la tua app si occupa del cambiamento del carico, proprio come potrebbe nella distribuzione del mondo reale.
Come parte di questo tutorial, mostrerò le basi per ottenere un piano di test in esecuzione contro le tue applicazioni, ma con una miriade di plugin e documentazione ci sono molti strumenti per gestire qualsiasi tipo di test delle prestazioni che potresti aver bisogno.
L'installazione è abbastanza semplice e qui elencheremo le istruzioni per Mac e Linux.
Su un Mac, JMeter può essere installato molto facilmente tramite Brew. Una volta che hai Brew prova il
seguente comando:
brew install jmeter
Su una macchina Linux, è sufficiente scaricare dalla pagina dei download di JMeter. Quindi, segui semplicemente le istruzioni fornite.
Una volta ottenuto il pacchetto principale di JMeter, dobbiamo anche installare il set standard di plugin. In futuro utilizzeremo un plug-in in particolare, quindi è necessario aggiungerli per poterlo utilizzare. Il set di plug-in standard può essere ottenuto da questo link: http://jmeter-plugins.org/downloads/file/JMeterPlugins-1.0.0.zip Una volta scaricato, estrarre nel pacchetto JMeter che si trova in: "/ usr / local / Cellar / jmeter / "su un Mac e ovunque l'abbia installato su Linux.
Quindi ora abbiamo installato JMeter e la nostra semplice applicazione, testiamo questa app e vediamo come si comporta. Quando accendi JMeter otterrai questa schermata:
Ora, impostiamo l'URL di base per le nostre richieste. Fai clic destro su "Piano di test" nel riquadro di sinistra e scegliere 'Aggiungi -> Config Element -> HTTP Request Default'. Ora possiamo inserire il nostro URL di base qui in questo modo.
Ora possiamo aggiungere la quantità di thread o "utenti" del nostro sistema. Per fare ciò, fare clic con il pulsante destro del mouse su "Piano di test" ancora e scegli 'Aggiungi -> Thread (utenti) -> Gruppo discussione'. Possiamo quindi inserire gli utenti, in questo caso 20. Assicurati di scegliere l'opzione di conteggio del ciclo per sempre, in quanto ciò ci consentirà di controllare il tempo e il numero di richieste tramite un plug-in in un secondo momento.
Una volta ottenuto il gruppo di thread, ora possiamo definire le richieste che vogliamo apportare alla nostra applicazione che andremo al test delle prestazioni. Per fare ciò aggiungeremo "Richiesta HTTP" al nostro "Piano di prova". Questo può essere trovato facendo clic destro sul "Thread Group" e scegliendo "Aggiungi -> Sampler -> Richiesta HTTP". Possiamo quindi definire la richiesta da effettuare nel riquadro come di seguito.
Puoi vedere come non abbiamo bisogno di definire l'URL di base, come abbiamo fatto in precedenza e invece è sufficiente aggiungere il percorso per la richiesta. In questo caso il percorso è alla nostra risposta 'esempio / 1'. Noterai anche che sono andato avanti e ho aggiunto le altre due richieste insieme al risultato e ai pannelli grafici, che utilizzeremo per analizzare i risultati dei test. A questo punto dovresti avere la possibilità di aggiungere elementi e possono essere facilmente trovati nel menu dai loro nomi. I due principali di interesse sono il "Throughput Shaping Timer" e il "Composite Graph".
The Shaping Timer ci consente di mappare come vogliamo che le richieste vengano fatte alla nostra applicazione nel tempo. Ad esempio, possiamo configurare una richiesta al secondo per 60 secondi, quindi accelerare fino a cinque richieste al secondo per 60 secondi e vedere l'effetto che questo ha sui nostri tempi di risposta. Diamo un'occhiata a come lo configuriamo nel riquadro Timer shaping.
Quindi, inserendo e aggiungendo ogni riga, è possibile definire la quantità di richiesta da effettuare e per quanto tempo dovrebbe farlo. Possiamo quindi visualizzare i nostri risultati utilizzando il "Grafico composito", che mostra le transazioni effettuate al secondo rispetto al tempo di risposta delle nostre richieste. Ciò richiede una configurazione minima, semplicemente aggiungendo i due grafici che combineremo, quindi nelle impostazioni per il grafico composito, aggiungere nei grafici richiesti in questo modo:
Questo è tutto! Ora possiamo eseguire il nostro piano di test e iniziare a vedere alcuni risultati. Hit gioca verso la parte superiore dello schermo e poi clicca sul grafico composito. Inizierà ad accumulare i risultati non appena entrano ed è possibile ottenere una foto di come la vostra applicazione sta rispondendo. Diamo un'occhiata ai nostri risultati.
Possiamo vedere chiaramente che il salto di richieste in un minuto ha un impatto piuttosto considerevole sulla nostra applicazione. Per il primo minuto le richieste sono stabili ad uno al secondo e danno tempi di risposta di circa due / tre ms. Tuttavia, quando aumentiamo a cinque, i tempi di risposta aumentano leggermente di cinque e cinque m / s. Ovviamente si tratta di tempi di risposta molto rapidi nel mondo reale, ma stiamo solo mostrando qui come possiamo aumentare il carico e vedere l'effetto, se presente, questo avrà.
Confrontiamo questi risultati con il servizio che ha un ritardo di tre secondi. Come riuscirà a far fronte all'aumento del carico? Per passare all'esempio due, fare clic con il tasto destro del mouse sull'esempio 1 e scegliere l'interruttore. Questo disabiliterà quella richiesta, quindi eseguirà un interruttore sull'esempio due e questo lo abiliterà. Assicurati di fare clic sul "Cancella tutto" (Spazzare il pennello) icona in alto per cancellare i risultati dell'ultima corsa, quindi premere play.
Anche con il ritardo di tre secondi, il server ha gestito le richieste abbastanza bene e vediamo molto lo stesso in termini di risultati per questo servizio. Aumentano solo pochi millisecondi quando le richieste aumentano. Con un servizio così semplice, è normale.
Il vero potere ora viene dalla combinazione di questi dati con New Relic. Ad esempio, potremmo impostare JMeter per funzionare per mezz'ora con diverse varianti di carico e quindi utilizzare New Relic per analizzare i risultati e utilizzare la sua funzionalità di drill-down per individuare i colli di bottiglia nell'applicazione. Questi possono quindi essere perfezionati, aumentando le prestazioni prima di consegnare ai clienti.
Ancora una volta, non entrerò nella configurazione di New Relic in quanto questo è trattato in altri articoli recenti su Nettuts + (Vedi qui). Ma una volta che la tua applicazione è connessa, è semplicemente un caso di generare il carico attraverso JMeter e accedere a New Relic per vedere i risultati. Per questa corsa, ho impostato il Timer Shaping per eseguire il nostro carico per 30 minuti aumentando le richieste da 5 a 10 e poi 15 al secondo. Questo dovrebbe darci un po 'di traffico ragionevole da guardare in New Relic.
Una volta che il test di JMeter è stato eseguito, possiamo dare un'occhiata a New Relic che ora possiamo vedere come stat sul traffico che segue l'app.
Ciò mostra chiaramente l'aumento delle richieste, raggiungendo il picco massimo di 400 richieste al minuto (RPM) e i tempi di risposta che rimangono stabili in tre secondi. Possiamo approfondire le statistiche e esaminare la transazione che stiamo facendo. Se facciamo clic sulla vista Transazioni Web, possiamo vedere l'analisi di New Relic eseguita solo su questa parte dell'applicazione. Se il codice che gestiva la richiesta avesse più livelli, come i metodi per chiamare altri sistemi per ottenere i dati prima di presentarli all'utente, vedremmo più di una ripartizione.
Ad esempio, a sinistra mostra che abbiamo trascorso il 100% del tempo richiesto, in quella chiamata. Se avessimo uno stage multiplo come una chiamata a un database, potremmo vedere una percentuale elevata e sapremmo ottimizzare la query al database per aumentare le prestazioni.
New Relic fornisce anche un'ottima vista di reporting sui dati delle applicazioni, denominata Scalabilità. Questo rapporto può essere davvero utile per monitorare la capacità delle applicazioni di gestire un carico crescente. Il grafico mostra il tempo di risposta rispetto alle richieste al minuto e puoi vedere chiaramente se c'è un calo nel tempo di risposta man mano che aumentano. Questo è un ottimo strumento e uno a cui dovresti fare riferimento spesso in entrambi i test delle prestazioni come questo, ma anche nel monitoraggio delle prestazioni della tua applicazione di produzione.
Nel nostro esempio di seguito, è chiaro che l'applicazione è in grado di mantenere un tempo di risposta di tre secondi anche all'aumentare dell'RPM.
New Relic fornisce anche un'altra visione, quella di Capacity. Questo ci consente di esaminare la quantità di risorse disponibili utilizzate dalla nostra applicazione. Indica allo sviluppatore se il numero di istanze che servono alla tua applicazione è sufficiente per gestire il tipo di carico che stai ricevendo. Questo è fondamentale per garantire che non stiate correndo in prossimità della capacità e che sia in grado di gestire eventuali picchi di traffico che potrebbero verificarsi al di fuori del normale flusso di traffico. La nuova Relic riassume bene la pagina, accanto all'analisi della nostra applicazione qui, che possiamo vedere come una carenatura anche su questa singola istanza.
Lo scopo di questo tutorial era di mostrarti come configurare rapidamente i piani di test di JMeter per la tua applicazione, in modo da poter testare le prestazioni della tua applicazione prima di consegnarla ai tuoi clienti. Questo approccio può essere utilizzato in nuovi progetti, assicurando che l'applicazione che stai per consegnare sia pronta per il traffico del mondo reale. Può anche essere utilizzato su applicazioni legacy, fornendo un indicatore di prestazioni di base in modo che, man mano che si apportano modifiche in futuro, è possibile vedere se le prestazioni dell'applicazione stanno migliorando o diminuendo.
Sfruttando gli ottimi strumenti forniti da New Relic, puoi monitorare la tua applicazione online in tempo reale, ma anche prendere il suo set di strumenti e applicarlo alla tua analisi offline. Questo ti darà, lo sviluppatore, la fiducia nel tuo prodotto sia durante lo sviluppo che quando verrà rilasciato in libertà.