Passa al contenuto principale

Mi viene spesso posta una domanda del tipo "Sono sulla Release X e sto pensando di passare alla Release Y? La nuova release è più veloce? Quanto è più veloce?". Forse state pianificando un aggiornamento hardware e avete domande simili.

Capisco il suo interesse. Ma ecco il mio problema. Mentre noi gestiamo i benchmark interni quando prepariamo una nuova release di OpenVOS, i nostri benchmark riflettono semplicemente quanto bene il sistema gestisce il benchmark! Nella misura in cui l'attività di un benchmark riflette la vostra applicazione, potete aspettarvi risultati in qualche modo simili. Ma abbiamo molti clienti OpenVOS, ed essi eseguono molte applicazioni diverse. Quindi, anche se possiamo fare alcune dichiarazioni generali su ciò che ci si potrebbe aspettare, dobbiamo sempre farle con un linguaggio attento. Anche se abbiamo visto un miglioramento del 20% delle prestazioni rispetto al nostro benchmark, i vostri risultati saranno probabilmente inferiori, ma potrebbero essere migliori. Il risultato è che la nostra stima spesso non è molto utile.

Non c'è dubbio che la comprensione delle caratteristiche prestazionali di un'applicazione sia un passo importante nella qualificazione di tale applicazione su una nuova release del sistema operativo, o su una piattaforma hardware più recente. La maggior parte dei clienti OpenVOS esegue applicazioni mission-critical sui loro sistemi; l'ultima cosa di cui si ha bisogno è fare un aggiornamento e vedere una sorta di sorpresa.

Quindi vorrei proporre un approccio diverso. Invece di chiedermi dichiarazioni generali sulle prestazioni di una nuova release, vorrei suggerirvi di preparare un sottoinsieme della vostra applicazione - forse le parti più sensibili alle prestazioni - da far girare in un ambiente controllato e simulato. Preparate dei dati fittizi che conservino l'ampiezza e la profondità dei dati reali. Se gestite transazioni per 3 milioni di clienti nel mondo reale, allora popolate 3 milioni di clienti simulati nel vostro ambiente di prova. Se si gestiscono 1000 negozi nel mondo reale, allora popolate 1000 negozi a scopo di test. Il motivo per cui è necessario adottare questa misura è semplice: si vuole che l'impronta di memoria e di memoria dell'ambiente di prova riproduca accuratamente ciò che accade in produzione.

È possibile utilizzare questo ambiente di test per stabilire le prestazioni di base sulla propria configurazione corrente, e poi quando è il momento di passare ad una nuova release di OpenVOS, o ad una nuova piattaforma hardware, è possibile utilizzare il proprio ambiente di test come metro di valutazione. Se volete scoprire i vantaggi di un aggiornamento hardware prima di acquistare l'apparecchiatura, parlate con noi. Manteniamo un laboratorio di riferimento dove potete venire ad eseguire i vostri test su uno qualsiasi dei nostri prodotti attuali. Spesso non dovete nemmeno viaggiare; possiamo mettere a disposizione l'attrezzatura su Internet.

Una volta che si dispone di un ambiente di test del software realistico e riproducibile, si può facilmente rispondere a diverse domande davvero cruciali - dov'è il top-end delle prestazioni della mia applicazione? Quante transazioni posso effettuare attraverso questo sistema? Quali sono i colli di bottiglia che si incontrano quando si cerca di farlo? Secondo la mia esperienza, ci sono sempre dei colli di bottiglia. Molto meglio trovare i colli di bottiglia sul sistema di prova che in produzione.

Stratus Professional Services ha molta esperienza nell'aiutare i clienti a misurare e ottimizzare le prestazioni delle loro applicazioni sui nostri prodotti. Quindi, se avete bisogno di un piccolo aiuto per questo esercizio, telefonate al vostro Account Executive.

© 2024 Stratus Technologies.