Creazione di un modello di prestazioni per un prodotto legacy

1. Inizia con i log del server web per capire il profilo del carico, quanti utenti usano il sistema su base giornaliera e quali pagine stanno andando. La maggior parte dei processi aziendali avrà pagine del nodo foglia che sono abbastanza distinte per consentire la raccolta diretta della frequenza con cui un processo aziendale viene completato in un dato intervallo di tempo e abbinato al numero di utenti sul sistema. Se si dispone dei registri per più anni, eseguendo lo stesso insieme di query su base campione regolare, una volta ogni tre mesi come esempio, sarà possibile mostrare le modifiche nei modelli di utilizzo nel tempo, inclusi eventuali aumenti nella base utenti. . Questi aumenti sono di fondamentale importanza se condurrete test delle prestazioni in modo che il carico possa essere proiettato verso l'esterno di ben 12-18 mesi per vedere come saranno le prestazioni in futuro.

2. Quindi, parla con il supporto del prodotto all'interno della tua organizzazione. Questa è una parte spesso trascurata dell'organizzazione che cattura le aspettative degli utenti. Controllate con la loro gestione e i loro registri / codice di chiamata per vedere ciò che la gente chiama più spesso da una prospettiva "lenta". Questi sono i tuoi eventi di cronometraggio critici. Potresti avere una categoria di tempo di risposta generale per l'interfaccia, ma questi eventi che le persone chiamano devono avere chiamate esplicite nei requisiti di rendimento.

3. Parla con i proprietari delle tue scoperte. Usa i risultati come una struttura per ulteriori requisiti / priorità su ciò che hai. La maggior parte delle volte verranno fuori requisiti aggiuntivi da questa discussione.

4. Incorporare questi elementi nel documento dei requisiti standard per le revisioni future del prodotto

5. Lavorare con lo sviluppo per implementare i test di integrazione di unità, componenti e sistemi legati alle prestazioni come indicato nei requisiti. Qui non fa male avere un ciclo di feedback in modo che gli sviluppatori possano vedere una build per creare differenze nelle prestazioni e assegnare anche la proprietà per il fissaggio delle prestazioni che diminuiscono da build a build.

6. Misurare le prestazioni nei test funzionali. Se non funziona per uno, allora non funzionerà mai per molti. Prima puoi trovare un difetto di prestazione, meglio è perché i test delle prestazioni sono di solito gli ultimi 100 metri sulla pista prima della spedizione. Più tempo puoi risparmiare, meglio è.

7. Assicurati che lo strumento di test delle prestazioni possa testare efficacemente la tua interfaccia e stai misurando i tuoi punti di timing critici.

8. Una volta che si è alla produzione, trovare un modo per misurare gli stessi elementi su una base coerente in produzione per vedere se ciò che si sta osservando in produzione corrisponde a ciò che si stava vedendo in prova. Modifica i requisiti di prossima generazione in base alle tue osservazioni

Molto probabilmente una buona parte delle prestazioni che vorrete misurare e migliorare ha a che fare con l'accesso al database e alle prestazioni del database. Quindi il tuo piano di prestazioni dovrà considerare come misurare quello e cosa cercare in termini di punti di dolore.

Non dici quale back-end del database stai usando, ma ti suggerisco di leggere le informazioni sull'ottimizzazione delle prestazioni per il database che utilizzi come back-end. La misurazione e l'ottimizzazione delle prestazioni per i database è spesso piuttosto specifica del motore di database che si sta utilizzando.

Per SQL Server questo sarebbe un buon libro per cominciare: link

Mi piacerebbe anche essere veloce nell'usare SQL Server Profiler se questo è il tuo back-end.

Non sono del tutto sicuro di quale sia la tua applicazione / sistema, e quale sia lo scopo / base utente, ma ti farò sapere come mi avvicinerei all'attività.

In primo luogo, cercherò di suddividere il sistema in sottosistemi, o componenti, che sono relativamente autosufficienti con solo una manciata, al massimo, interfacce con gli altri componenti. Se riesci a costruirli ed eseguirli individualmente, sarai in grado di monitorare meglio le loro prestazioni e il costo delle risorse associate. Se si trova un processo o un thread particolarmente impegnativo in termini di risorse, è anche possibile gestire il 'drill-down' per trovare la causa principale. La scala di questi passaggi dipende totalmente dalla tua architettura.

Se è possibile per te isolare e monitorare le catene di funzionalità, tanto meglio. Non sono sicuro di quanto impegno ti sia stato assegnato dalla direzione per svolgere questo compito e, sfortunatamente, sarà sempre il driver principale (in base alla tua influenza ascendente) di ciò che puoi ottenere. Ma ho trovato una suddivisione in unità più piccole per essere un approccio fantastico alla maggior parte degli aspetti dell'ingegneria del software - compresa la modellazione delle prestazioni!