Come affrontare al meglio la pianificazione e il budget degli sforzi di ottimizzazione delle prestazioni del software?

4

C'è un sistema software che è stato con il cliente da un po 'di tempo. Se è un'applicazione enterprise complessa, matura e complessa che il client utilizza nella produzione. A causa della rapida espansione dell'attività del cliente, il sistema software in oggetto non è in grado di gestire i volumi in modo efficiente e le prestazioni complessive non soddisfano più il cliente.

Quindi il cliente chiede al fornitore del sistema software di migliorare le prestazioni e l'efficienza del sistema. Il cliente si aspetta inoltre che il fornitore prepari un piano e un budget per il ballpark, quindi il costo di tali ottimizzazioni è approssimativamente conosciuto in anticipo.

Quale pensi che sia l'approccio migliore per un piano di questo tipo e un budget di alto livello che potresti preparare per il cliente? Sto facendo la domanda perché ho visto alcuni di questo tipo di piani prima e di solito sono molto vaghi e imprecisi principalmente a causa del fatto che tale esercizio è una specie di dilemma di pollo e uova. Per sapere che cosa esattamente dovrebbe essere ottimizzato e messo a punto nel sistema complesso è necessario il benchmarking, la profilazione e la ricerca. E tale indagine è anche la parte del progetto pianificato, quindi è impossibile sapere in anticipo quali sforzi possono richiedere tali risultati di benchmarking per implementare miglioramenti.

    
posta Tomasz Błachowicz 17.08.2011 - 17:22
fonte

3 risposte

5

Sarei onesto con loro. Se hanno intenzione di finanziare questo, e in effetti ci vorrà molto tempo per trovare i problemi di rendimento, digli che dovrebbe essere finanziato in due fasi. Prima estendere il lavoro necessario per svolgere indagini, benchmark e analisi. Il risultato finale di questo sforzo può essere una proposta per quali aree devono essere ottimizzate. Trova dove è il più bang-for-the-buck. Questo potrebbe essere l'ottimizzazione di una funzione o il refactoring / cambiamento dell'architettura del sistema. È possibile valutare il rischio / la ricompensa e decidere quanto rischio si è disposti a prendere per quanto guadagno di prestazioni.

Se non sono disposti a pagare per la prima fase, potresti dover finanziare tu stesso come parte del lavoro di tipo proposta / analisi.

Quindi puoi essere più preparato a dare loro le opzioni per la fase 2, in realtà ottimizzando le prestazioni. Avrai buoni consigli e sarai in grado di fornire qualche tipo di stima.

    
risposta data 17.08.2011 - 17:36
fonte
4

Posso solo darti un po 'di esperienza personale. Avevamo un prodotto con un grave problema di prestazioni e le persone potevano solo tenere il dito al vento e indovinare quale potrebbe essere il problema.

Nel corso degli anni ho eseguito una buona messa a punto delle prestazioni, quindi ho chiesto al gestore di lasciarmi provare. Ho tirato un numero in aria - 4 settimane.

Era scettico e disse: non ti ci vorrà tanto tempo per creare profiler e quant'altro? Ho detto che non uso i profiler, ho solo acquisisci i campioni manualmente . Ha detto come hai intenzione di ottenere abbastanza campioni per ottenere misurazioni valide? Ho detto che se hai un ciclo infinito quanti campioni hai bisogno? Se non è infinito, solo di lunga durata, di quanti ne hai bisogno? Ha detto ah-hah e mi ha dato il via libera.

Mi ci sono volute 2 settimane solo per avere gli ambienti build / debug impostati sulla mia macchina. C'erano due lingue (forse tre, me ne dimentico). Questo mi ha portato al punto in cui ho potuto riprodurre il problema e prendere alcuni campioni di pila manuale, e ho immediatamente individuato il primo problema. Dal prendere i primi campioni per individuare il problema è durato meno di un'ora.

Ora arriva la parte difficile: ottenere il / i proprietario / i del codice per cambiarlo. Il primo problema non era troppo difficile. Il codice è stato corretto e si è verificata una notevole riduzione dei tempi di esecuzione. Poi ho preso altri campioni e ho individuato il secondo grosso problema. Questa volta, non è stato così facile ottenere la collaborazione del proprietario del codice. Il cambiamento richiesto andò contro la sua nozione di "design adeguato". Sembra che il mio "capitale politico" sia esaurito. Quindi non ci siamo riusciti al massimo. Se riesci ad andare avanti su più passaggi, sono possibili aumenti più rapidi, ma c'è sempre il pericolo del "gioco della colpa". È qui che il proprietario del codice non vuole cambiarlo, perché qualcuno potrebbe chiedere loro perché non hanno fatto il codice in quel modo in primo luogo. È difficile comunicare che i problemi di prestazioni sono come bug - chiunque può crearli e una misura dell'età adulta è in grado di ammetterlo.

Conclusione: sono state spese circa 3 settimane, delle 4 stimate. Abbiamo ottenuto un po 'della possibile accelerazione.

Lezione appresa - Se hai intenzione di fare ciò, è necessario specificare a tutti gli sviluppatori che potrebbero dover effettuare più modifiche al codice, comprese le modifiche alla progettazione. Inoltre, i cambiamenti potrebbero apparire "dispendiosi" nel senso di rendere irrilevanti i cambiamenti precedenti. Devi ottenere il loro buy-in.

    
risposta data 17.08.2011 - 22:29
fonte
1

Per prima cosa devi identificare i blocchi di prestazioni prima di poter stimare il tempo di correzione. Se il blocco è causato dalla necessità di un server più recente con più memoria e potenza di elaborazione che non richiede molto tempo per risolvere. Se hanno una buona attrezzatura, ma il problema è la struttura di base del database, potrebbe essere necessario un anno o più per la correzione. O forse hanno bisogno del partizionamento del database per poter accedere più rapidamente alle cose.

In un prodotto maturo, dovresti trovare in dba le query di lunga durata e correggerle regolarmente. La regolazione delle prestazioni dovrebbe essere continua. Inoltre i tuoi sviluppatori probabilmente hanno una buona idea di dove si trova il debito tecnico e che è un buon punto per iniziare a cercare problemi di prestazioni.

Vorrei stimare il tempo necessario per identificare i blocchi di prestazioni e dire loro che preparerai un preventivo per risolvere i problemi una volta che i problemi saranno noti. Vorrei iniziare anche adesso per esaminare le tue query a lungo termine e correggerle. Ogni miglioramento incrementale aiuterà a mantenere il cliente dalla tua parte. Potresti anche dargli un elenco prioritario delle aree in cui hanno le prestazioni più lente per darti un'idea di cosa iniziare. Potresti anche considerare di proporre un processo di interazione quando trascorri una settimana o due identificando i problemi in una parte specifica dell'applicazione e poi un'altra settimana o due risolvendo questi problemi, quindi passa alla sezione successiva, ecc. In questo modo, puoi iniziare a migliorare prima di identificare tutti gli articoli che causano le scarse prestazioni.

Esistono noti problemi di prestazioni con determinati tipi di strutture SQL (varia a seconda del back-end del database), ma per SQL server, se si utilizzano spesso cose come sottoquery, cursori, funzioni in join e clausole where, UDF scalari, viste che chiamano viste che chiamano visualizzazioni, allora è probabile che il tuo database abbia bisogno di una revisione completa. Se tutte le tue chiavi esterne non sono indicizzate è una vittoria facile, economica (in termini di tempo). Se i tuoi sviluppatori non sanno cosa significa sargable, allora probabilmente hai delle query scritte male e quasi tutte le query dovranno essere esaminate per le cattive pratiche.

Francamente, è bello che il tuo cliente sia disposto a pagare un po 'di soldi per questo, ma hai fatto il design scadente, la tua azienda dovrebbe pagare la maggior parte delle correzioni.

Infine, assicurati di imparare da questo. Se il problema è una cattiva progettazione di database o query poco performanti, istruisci i tuoi sviluppatori a scrivere query performanti e / o assumere uno specialista di dati. Chiunque progetta un sistema Enterprise senza specialisti di dati nella fase di progettazione probabilmente avrà un sistema che fallisce quando il carico diventa alto. Le prestazioni dovrebbero essere considerate nella fase di progettazione del database. Questa NON è ottimizzazione prematura, questo evita problemi noti di prestazioni. È molto più difficile risolvere un sistema Enterprise maturo in produzione che per correggere un cattivo progetto.

Non sto dicendo che il database sia l'unica fonte dei tuoi problemi di prestazioni, solo che è uno dei posti più probabili. Hai bisogno di profilo per vedere cosa sta succedendo. Ricordo una volta in cui stavamo riscontrando un problema di prestazioni e si è scoperto che l'applicazione chiamava lo stesso proc migliaia di volte per ogni pagina quando era necessario chiamarla una sola volta. Ma come specialista di dati, la mia esperienza è stata che ci sono molti database mal progettati e poco performanti là fuori.

    
risposta data 17.08.2011 - 23:24
fonte

Leggi altre domande sui tag