.NET Core: l'invio della stessa richiesta più volte come parte di uno stress test / test di carico rende il test inaffidabile?

0

Ho un'applicazione .NET Core che accetta richieste HTTP. Sono un po 'annoiato, quindi ho deciso di sottoporlo a test utilizzando West Wind Web Surge e inserendo una richiesta di esempio come corpo.

La mia domanda è, dal momento che la richiesta è esattamente la stessa ogni volta, vedo prestazioni artificialmente elevate perché l'applicazione ha già elaborato una richiesta simile? È probabile che qualcosa venga salvato in memoria anziché ricalcolato ogni volta, e io non ne sono consapevole? Vale la pena di creare un'applicazione che generi richieste in modo casuale per ottenere un'immagine più vera? Il mio codice è piuttosto standard, niente di eccezionale in corso.

So che è una domanda generica, ma non so davvero dove cercare la risposta.

    
posta Nickdb93 28.05.2018 - 18:53
fonte

2 risposte

3

Sì. (sorta di)

Puoi avere tutti i tipi di memorizzazione nella cache tra il tuo cliente e l'eventuale risposta. Se si eseguono i test su un ambiente e una rete che non si controllano completamente, ad esempio una distribuzione dal vivo in cui possono essere coinvolti vari team di rete e di distribuzione, è probabile che vengano implementate alcune politiche di memorizzazione nella cache.

Ora, vuoi testare le prestazioni con o senza memorizzazione nella cache? se lo provi senza i tuoi risultati sono utili? Dopo tutto il sistema live utilizzerà una cache.

Se lo collaudi con, poi di nuovo, la quantità di memorizzazione nella cache corrisponde a ciò che vedresti se fosse in diretta? Presumibilmente non ti aspetti richieste identiche al 100% in tempo reale.

Quello che devi fare è simulare il sistema live nel miglior modo possibile. Ciò significa generare traffico live pseudo o replay su un sistema distribuito sullo stesso tipo di hardware del sistema live.

    
risposta data 28.05.2018 - 19:39
fonte
1

Il test di carico ben eseguito non sta martellando un singolo URL, questa forma di test non ha molto senso (a meno che tu stia testando .NET Core o IIS), rappresenta l'utente della vita reale seduto dietro il browser reale con tutte le cose correlate come:

  • Intestazioni
  • Cookie
  • Comportamento relativo a risorse incorporate (immagini, script, stili, caratteri, ecc.) - i browser reali li scaricano usando 6 thread paralleli e rispettando le intestazioni di Cache-Control
  • Cache stesso, i veri browser scaricano risorse incorporate, ma lo fanno solo una volta, su richieste successive, le risorse vengono restituite dalla cache e non viene effettuata alcuna richiesta effettiva
  • AJAX richieste - sebbene nessuno degli strumenti di test del carico possa effettivamente eseguire JavaScript sul lato client se l'applicazione utilizza la tecnologia AJAX e genera richieste di rete - è necessario simulare questo come i browser eseguono JavaScript in modo asincrono e la maggior parte degli strumenti di test del carico non può avviare thread aggiuntivi

E, ultimo ma non meno importante, se l'applicazione presuppone diversi casi d'uso da parte di diversi ruoli utente, dovresti considerare la creazione di diversi gruppi indipendenti di utenti che si associano ai casi d'uso della tua applicazione (ad es. utenti anonimi che eseguono solo la scansione, utenti che hanno compilato alcuni moduli) , ecc.) e il carico di lavoro rappresenterà più o meno la distribuzione nella vita reale.

Quindi l'idea principale di un buon load test è che questo test dovrebbe essere realistico, altrimenti non ha molto senso in quanto non sarai in grado di dire con certezza quanti utenti simultanei l'applicazione supporta fornendo tempi di risposta ragionevolmente bassi quando si rompe, si ripristina quando il carico diminuisce, ecc.

    
risposta data 29.05.2018 - 06:37
fonte

Leggi altre domande sui tag