Come si calcolano i requisiti del server per un'applicazione Web

I primi tre punti sono la pianificazione della capacità. L'organizzazione sta cercando di preventivare e prevedere per il futuro. Purtroppo, non esiste un modo semplice o accettato per prevedere le prestazioni e la scalabilità. Ogni applicazione e ambiente è diverso. Pertanto, il modo migliore per rispondere è misurare.

In particolare:

1. Discutere con la direzione o i proprietari dei prodotti quale sarà la probabile crescita degli utenti e i tipi di utenti diversi. Se non lo sanno, indovina ma documenta che si tratta di supposizioni.
2. Crea un'esecuzione automatica dei percorsi comuni della tua applicazione. Puoi registrare attività o inserirle in applicazioni di test di carico come JMeter .
3. Crea un ambiente di test che corrisponda all'hardware corrente o proiettato. Presta particolare attenzione a cose come larghezza di banda, archiviazione, SSL, registrazione o altri aspetti frequentemente dimenticati che potrebbero influire sulle prestazioni. Crea il servizio di immagini di terze parti se possibile, usando immagini più piccole o rappresentative.
4. Utilizza l'applicazione di test del carico per creare la proposta per il numero previsto di utenti in momenti diversi.
5. Utilizza uno strumento di gestione delle prestazioni delle applicazioni, come AppDynamics o DynaTrace , per misurare le prestazioni e identificare i colli di bottiglia.

Oltre ai requisiti di cui sopra, questo può aiutarti:

1. Conferma che il tuo ambiente supporta il carico richiesto.
2. Trova il carico massimo supportato dall'ambiente.
3. Trova i colli di bottiglia che limitano le tue prestazioni o scalabilità.
4. Fai esperimenti con diverse configurazioni per vedere come eseguire o scala.
5. Osserva come si comporta il sistema quando si attivano errori.

Gli ultimi due punti, requisito HA (alta disponibilità) e DR (ripristino di emergenza, presumibilmente RPO (obiettivo del punto di ripristino) e RTO (obiettivo del tempo di recupero) ), è più difficile da prevedere in quanto si tratta di requisiti aziendali. Discutere con la tua gestione o con i proprietari dei prodotti i possibili errori e quanto costano ridurre o correggere . Se entrambi siete nuovi, aspettatevi molte supposizioni e tarda notte da parte vostra.

Mi piace molto la tua domanda. È buono. Non penso che ci sia una vera risposta a questo, ma proverò. Quando si crea / progetta un nuovo server è più importante scegliere il giusto Ambiente e metodi. Non tutti gli ambienti sono scalabili, la maggior parte solo in modo limitato. Ciò che l'Hardware-Team sta cercando di calcolare è, che tipo di filesystem e interfacce possono usare. Alcuni file system sono facili da configurare ma difficili da espandere. Altri sono difficili da configurare ma facili da gestire ed espandere.

La cosa migliore, secondo me, è entrare in contatto con quelli che ti fanno queste domande e spiegargli perché non puoi rispondere a queste domande adesso. Quando si avvia una nuova applicazione o sistema, nessuno può dire come tutto questo si evolve specialmente quando non ci sono altri sistemi a cui è possibile confrontare. Ma tu hai le conoscenze sull'API che hai progettato e "Hardware-Man" ha la conoscenza di come funzionano i suoi Enviroment / Server. Insieme puoi sicuramente capire queste domande.

Spero che questo ti aiuti.

Proporrei una base più oggettiva. Vai ai tuoi log HTTP esistenti. Supponendo che si tratti di un aggiornamento di un'app già presente sul campo, è sufficiente tirare i registri ed esaminare le richieste HTTP che sono incluse. Ciò fornisce una base oggettiva assoluta per la modellazione del carico invece di un dito bagnato nell'aria per testare il vento.

Inoltre, tieni presente la prospettiva della QA. Non puoi possedere entrambi i requisiti e la convalida. Pertanto, è possibile utilizzare i dati obiettivo dai registri per aiutare a creare informazioni sul modello di carico, ma è necessario che qualcuno del business esegua l'accesso alla definizione effettiva. Perché? Perché stai iniettando un requisito nello stream che fino ad ora non era disponibile per gli sviluppatori, gli architetti, i gestori della piattaforma, ecc ... se fallisci nell'app, vuoi che il business dietro di te sia accurato.

Che cosa puoi tirare i registri?

• Massima velocità di transazione all'ora (conteggio delle richieste bloccate per ora)
• Gli utenti più alti all'ora (conteggio dell'indirizzo IP bloccato per ora)
• Flussi di dati utente (vedi tag di riferimento su richieste per costruire un albero di richieste precedenti)
• Tempi di risposta esistenti (se si dispone del campo preso in considerazione w3c abilitato per le chiamate dei servizi Web). Questo può essere usato per impostare aspettative per le versioni future su una base obiettiva per colpire o eccedente il modello attuale
• Pensa ai tempi dei ritardi tra le richieste di IP. Puoi reale modellare i punti campione sul tempo tra le due richieste di afferrare il tag di riferimento e il blocco tramite l'indirizzo IP per creare un campione impostato. È quindi possibile estrarre statistiche su tali campioni per min, max, media, 90 ° percentile pensa volte. Diamine, alcuni pacchetti di statistiche saranno pari fornire una funzione che è possibile inserire un numero casuale in a ottenere una distribuzione appropriata per la produzione
• Se disponi di log per periodi di tempo precedenti, puoi proiettare la crescita modelli per osservati rispetto a quelli desiderati (vendite o proiezioni di utilizzo)

Preferisco Splunk per questo tipo di lavoro. Per la maggior parte delle organizzazioni dovresti essere in grado di trasferire 30 giorni di log nel livello gratuito senza doverti preoccupare di configurare una mezza dozzina di app diverse insieme come fai con lo stack ELK.

Soddisfa i requisiti e potresti inseguire fantasmi ingegneristici che non si verificherebbero mai nella produzione e non riducono effettivamente alcun rischio. Assicurati che qualcuno nella parte commerciale accetti le tue esigenze o potresti essere il proprietario di un eccesso di budget per inseguire i non difetti.