Gennaio ColdFusion MX for JRun. Conclusioni sulle prestazioni

Transcript

1 Gennaio 2003 ColdFusion MX for JRun Conclusioni sulle prestazioni

2 2003 Macromedia, Inc. Tutti i diritti riservati. Le informazioni contenute in questo documento rappresentano la posizione corrente di Macromedia sull argomento discusso alla data della pubblicazione. Poiché Macromedia si adegua alle condizioni del mercato in continuo mutamento, tale posizione non costituisce impegno alcuno e pertanto Macromedia non garantisce la precisione delle informazioni qui contenute dopo la data della pubblicazione. Questa guida è a puro scopo informativo. MACROMEDIA NON OFFRE ALCUNA GARANZIA, ESPRESSA O IMPLICITA, IN QUESTO DOCUMENTO. Copyright 2001 Macromedia, Inc. Tutti i diritti riservati. Macromedia, il logo Macromedia, ColdFusion, il logo ColdFusion, Dreamweaver, UltraDev, Flash, JRun, HomeSite, Macromedia Generator e Macromedia Spectra sono marchi di fabbrica o depositati di Macromedia, Inc. Altri marchi potrebbero essere marchi di fabbrica o depositati dei rispettivi titolari. Macromedia, Inc 275 Grove Street Newton MA info@macromedia.com (617)

3 Indice Indice... 3 Riepilogo... 4 Statistiche... 4 Prestazioni dell'applicazione... 5 Definizione delle prestazioni dell'applicazione... 5 Miglioramento delle prestazioni in ColdFusion MX for JRun... 5 Installazioni ColdFusion multiple... 6 Configurazione ed applicazione prova...7 Risultati delle prove... 8 Windows Solaris... 9 Linux Clustering dei server ed istanze ColdFusion multiple...13 Deviazione standard e riciclo automatico...13 Deviazione standard...13 Riciclo automatico...14 Appendice Risultati delle prove Tempi di risposta di Windows 2000 (secondi) Produzione HTTP su Windows 2000 (24 ore) Tempi di risposta di Solaris Produzione HTTP su Solaris (24 ore) Tempi di risposta su Linux Produzione HTTP su Linux (24 ore) Varianze nei tempi di risposta (deviazione standard) con una configurazione di 4 server cluster Dettagli sull'applicazione di prova Tack

4 Riepilogo La distribuzione di ColdFusion MX per Macromedia JRun su un server J2EE quale JRun 4 consente agli sviluppatori di sfruttare al massimo la produttività di ColdFusion con tutte le funzioni di Java 2 Enterprise Edition (J2EE). I miglioramenti a livello di prestazioni in ColdFusion MX for JRun e la provata superiorità di Jrun 4 a livello di produttività, scalabilità e disponibilità consentono agli sviluppatori di creare e distribuire applicazioni in grado di gestire alti volumi di attività utente con prestazioni e stabilità prevedibili. E con la funzione di clustering server a livello aziendale basato su JINI di JRun 4, le funzioni di bilanciamento del carico, backup automatico dei dati a tutti i livelli ed isolamento dei processi si combinano per garantire applicazioni ColdFusion dalle massime prestazioni ed altamente flessibili. Statistiche Windows Fino al 41% più rapido di ColdFusion 5 1 Solaris Fino al 44% più rapido di ColdFusion 5 2 Linux Fino al 74% più rapido di ColdFusion Processore singolo con Windows 2000 e Sun JVM 2 Processore duale Solaris 7 con Sun JVM 3 Processore duale RedHat Linux 7.2 con Sun JVM 4

5 Prestazioni dell'applicazione Definizione delle prestazioni dell'applicazione Un'applicazione ad alte prestazioni è in grado di inviare rapidamente contenuto agli utenti. In queste conclusioni, le prestazioni dell'applicazione vengono analizzate misurando il tempo di risposta delle pagine, ossia il tempo trascorso tra l'invio di una richiesta (il clic su un pulsante di invio, l'immissione manuale di un URL o il clic su un collegamento da parte di un utente) ed il successivo completamento della richiesta in questione. Un tempo di risposta inferiore per richiesta (con completamento più rapido della richiesta) consente all'applicazione di inviare più contenuto generale a più utenti in un dato periodo di tempo (produzione). Tre fattori di base influenzano le prestazioni in termini di tempi di risposta: Architettura e configurazione del server dell'applicazione Web Infrastruttura della rete Design delle pagine Web Tutti e tre i fattori sono di notevole importanza ed ignorandone anche uno solo, nessuna applicazione Web funzionerebbe in modo efficiente. Tuttavia, poiché l'ampiezza banda ed il design delle pagine Web non sono funzioni del server applicativo, queste conclusioni si concentrano esclusivamente sui cambiamenti nel tempo di risposta delle pagine risultanti dai miglioramenti apportati al server ColdFusion. Miglioramento delle prestazioni in ColdFusion MX for JRun I server ColdFusion MX e ColdFusion MX for JRun implementano un nuovo metodo di esecuzione dei modelli ColdFusion. Nelle versioni precedenti, ad ogni richiesta le pagine di ColdFusion venivano elaborate da un interprete. In entrambe le versioni di ColdFusion MX questo non succede più. Alla richiesta iniziale da parte di una pagina del server ColdFusion MX o ColdFusion MX JRun, la pagina viene compilata in un bytecode Java ed a quel punto viene eseguita e quindi passata alla memoria cache ed al disco. Tutte le richieste successive per quella pagina vengono gestite dal bytecode memorizzato, a meno che un aggiornamento alla pagina non forzi la ricompilazione della pagina stessa. Come illustrato in queste conclusioni, il cambiamento porta ad un notevole aumento di prestazioni per le applicazioni di produzione. Sebbene ColdFusion MX for JRun e ColdFusion MX Enterprise Edition condividano questo approccio all'esecuzione con modelli, sono state implementate ulteriori ottimizzazioni nell'edizione ColdFusion MX for Jrun per renderlo ancora più rapido della versione Enterprise autonoma, di ben il 30% più rapido nelle stesse configurazioni 4. 4 Processore duale RedHat Linux 7.2 con Sun JVM 5

6 Installazioni ColdFusion multiple In ColdFusion MX Enterprise e Professional Edition, così come in ColdFusion 5 e versioni precedenti, ColdFusion viene installato una volta per server. All'interno di questa installazione gli sviluppatori sono in grado di eseguire più applicazioni; tuttavia tutte le applicazioni vengono eseguite all'interno di un processo server singolo. A risultato di questo, tutti i problemi che si verificano in un'applicazione incidono su tutte le altre applicazioni sullo stesso server. Inoltre, molte impostazioni a livello server, quali caching, server per , sicurezza con modello sandbox e così via, vengono distribuite a tutte le applicazioni sul server. Questi due aspetti di ColdFusion potrebbero non essere l'ideale per talune applicazioni. Facendo affidamento sulle piene capacità dell'architettura J2EE, ColdFusion MX for JRun offre una nuova e potente opzione di distribuzione, consentendo più installazioni di ColdFusion su un solo server. Per le applicazioni ColdFusion, questo si traduce in due grandi vantaggi. Dapprima, è possibile effettuare il clustering di un'applicazione ColdFusion singola tra diversi processi indipendenti su un server singolo, garantendo maggiore disponibilità senza dover sostenere ulteriori costi hardware. Qualora un processo singolo non riesca, è possibile comunque deviare il traffico su altri processi del server. In secondo luogo, più applicazioni ColdFusion possono essere eseguite nella propria istanza server. Questa configurazione garantisce maggiore flessibilità nella configurazione server ed allo stesso tempo maggiore sicurezza ed isolamento tra un'applicazione e l'altra. Più applicazioni server ColdFusion per una singola applicazione ColdFusion garantiscono un livello superiore di stabilità, disponibilità ed utilizzo delle risorse del server. Tutto questo viene discusso in ulteriori dettagli nella sezione Clustering dei server ed istanze ColdFusion multiple. 6

7 Configurazione ed applicazione prova Le prove per pervenire a queste conclusioni sono state eseguite con ColdFusion 5 Enterprise Edition, ColdFusion MX Server Enterprise Edition e ColdFusion MX for Macromedia JRun, su server singoli con configurazioni multi-processore variabili su Microsoft Windows 2000 Advanced Server, Sun Solaris 7 e RedHat Linux 7.2. Per ciascun sistema operativo, i dati vengono presentati confrontando le prestazioni delle tre versioni di prodotti ColdFusion. Su Windows 2000, sono disponibili ulteriori dati che illustrano la capacità di ColdFusion MX for JRun di fornire scalabilità SMP lineare man mano che il numero di processori aumenta, portando ad una produzione superiore. Le impostazioni sono state regolate in modo da ottenere prestazioni ottimali in ciascuna versione dei prodotti. In ColdFusion 5 Enterprise Edition e ColdFusion MX Server Enterprise Edition, sono state effettuate delle rettifiche alle impostazioni del server per accomodare le richieste simultanee. Questa impostazione è gestita dal server applicativo sottostante ed indica il numero di richieste simultanee gestite da ColdFusion in un dato momento. Quando il server raggiunge il limite specificato, le richieste vengono inviate in coda e gestite nell'ordine in cui vengono ricevute. La regola generale è quella di impostare le richieste simultanee portando a 3-4 il numero di CPU sul sistema. Pertanto, se il server dispone di due processori, il numero di richieste simultanee per il server ColdFusion dovrebbe essere di 6-8. In tal caso, qualora vengano richiesti più di sei thread, ColdFusion mette automaticamente in coda le richieste aggiuntive fin quando una delle altre due non si libera. Notare che il numero ottimale potrebbe variare secondo la configurazione hardware e l'applicazione in esecuzione. Le distribuzioni reali delle applicazioni ColdFusion traggono vantaggio dalla configurazione dell'impostazione ottimale delle richieste simultanee dell'applicazione in questione. In ColdFusion MX for JRun tale impostazione per le richieste simultanee non esiste. Nelle prova di questa versione, sono state effettuate delle rettifiche alle impostazioni minime e massime delle dimensioni dei thread per il Web Container Service con un'impostazione di timeout alta in caso di inattività (per informazioni sulle impostazioni usate, consultare l'appendice A). Le prove su ColdFusion MX Server Enterprise Edition e ColdFusion MX for JRun sono state condotte lasciando attivata l'impostazione di 'cache fidata' di ColdFusion. Questo specifica che tutti i file richiesti e residenti al momento nella cache dei modelli non verranno ispezionate per rilevare eventuali aggiornamenti. Per i siti in cui i modelli non vengono aggiornati durante l'utilizzo del server, così facendo si riducono al minimo i costi di gestione del sistema di file. Questa è un'impostazione di configurazione importante per le prestazioni di ColdFusion MX in generale e va usata correttamente per qualsiasi distribuzione di applicazioni. Le prove per queste conclusioni sono state eseguite nello stabilimento Macromedia Enterprise Testing di Newton, nel Massachusetts. L'applicazione usata nella prova è Tack2++ (una nuova versione dell'applicazione esempio Tack2Plus originale in dotazione a ColdFusion MX), che conserva tutte le caratteristiche funzionali dell'applicazione Tack2Plus originale, ma utilizza le funzioni di caching di modelli ed interrogazioni, come succederebbe in un'applicazione Web di ColdFusion reale. L'applicazione rappresenta una tipica applicazione di e-commerce reperibile sul Web. Per ulteriori dettagli sull'applicazione, consultare l'appendice. 7

8 Risultati delle prove Windows 2000 Le seguenti versioni di prodotti sono state confrontate su Windows 2000: ColdFusion Server 5 Enterprise Edition ColdFusion MX Server Enterprise Edition ColdFusion MX per JRun con Macromedia JRun 4 Con la seguente configurazione server: Windows 2000 Advanced Server SP2 Serve Intel OCPRF x 500MHz PIII Xeon 4 GB di RAM Il server per database back-end per ciascuna suite di prove era un Compaq 6500 indipendente, con quattro processori Pentium III da 500 MHz e Microsoft SQL Server Tutte le prove sono state eseguite usando 100 utenti virtuali (VU) simulati con Segue SilkPerformer V. Per dimostrare la scalabilità SMP lineare con ColdFusion MX for JRun, la configurazione dei processori del computer di prova è stata gradualmente aumentata da uno ad otto processori. Come illustrato nella Figura 1, il tempo di risposta medio delle pagine per l'applicazione è migliorato in modo non lineare man mano che si aggiungevano processori. I risultati hanno dimostrato inoltre che ColdFusion MX for JRun garantisce tempi di risposta più celeri rispetto ad altre versioni del prodotto. Tempi di risposta medi delle pagine (secondi) Windows 2000 Tempi di risposta medi (sec.) Numero di processori CF5 Enterprise CFMX Enterprise CFMX-JRun Figura 1: Miglioramenti nei tempi di risposta medi delle pagine con l'aggiunta di processori in Windows

9 In aggiunta all'elaborazione più rapida di richieste di pagine, ColdFusion MX for JRun garantisce una scalabilità a livelli molto più sofisticati rispetto ad altre versioni di prodotti ColdFusion, man mano che il numero di processori server aumenta. Questo fa in modo che l'applicazione possa gestire più richieste in un dato periodo di tempo (come illustrato nella Figura 2). Produzione HTTP / 24 ore - Windows 2000 Hit / 24 ore Milioni CF5 Enterprise CFMX Enterprise CFMX-JRun Numero di processori Figura 2: Richieste HTTP gestite in 24 ore su Windows 2000 su tre versioni di prodotti e su configurazioni di processori multipli Solaris Le seguenti versioni di prodotti sono state confrontate su Solaris: ColdFusion Server 5 Enterprise Edition ColdFusion MX Server Enterprise Edition ColdFusion MX per JRun con Macromedia JRun 4 con la seguente configurazione server: Solaris 7 Server Sun E220 2 processori SparcV9 da 450 MHz 512 MB di RAM Serve http IBM (Apache) JVM for Solaris è un ambiente di runtime Java(TM) 2, Standard Edition (Versione JPSE_1.3.1_ ) con Java HotSpot(TM) Client VM (versione JPSE_1.3.1_ , modalità combinata). Il server per database back-end per ciascuna suite di prove era un Compaq 6500 indipendente, con quattro processori Pentium III da 500 MHz e Microsoft SQL Server Tutte le prove sono state eseguite usando 100 utenti virtuali (VU) simulati con Segue SilkPerformer V. 9

10 Come osservato con Windows 2000, ColdFusion MX for JRun ha dimostrato un guadagno notevole in termini di prestazioni rispetto alle versioni precedenti del prodotto. Il tempo di risposta medio delle pagine era all'incirca metà rispetto a ColdFusion 5, come illustrato nella Figura 3. Tempo di risposta medio delle pagine (secondi) Solaris Tempi di risposta medi (sec.) CF5 Enterprise CFMX Enterprise CFMX JRun Versione del prodotto Figura 3: Miglioramenti nei tempi di risposta med i delle pagine con tre versioni di prodotti su Solaris In aggiunta ad un invio più rapido del contenuto, i miglioramenti di scalabilità in ColdFusion MX for JRun si traducono nella capacità di inviare più contenuto rispetto ad altre versioni di ColdFusion durante un periodo di tempo prestabilito. La Figura 4 mostra che ColdFusion MX for JRun è stato in grado di gestire quasi il doppio dei dati in un periodo di 24 ore rispetto a ColdFusion 5 Enterprise Edition. Produzione HTTP / 24 ore - Solaris Hit HTTP / 24 ore Milioni CF5 Enterprise CFMX Enterprise CFMX JRun Versione del prodotto Figura 4: Richieste HTTP gestite durante un periodo di 24 ore su Solaris 10

11 Linux Le seguenti versioni di prodotti sono state confrontate su Linux: ColdFusion Server 5 Enterprise Edition ColdFusion MX Server Enterprise Edition ColdFusion MX per JRun con Macromedia JRun 4 con la seguente configurazione server: RedHat 7.2 Server Penguin Computing 2 processori 933MHz PIII 512 MB di RAM Serve http IBM (Apache) Il server per database back-end per ciascuna suite di prove era un Compaq 6500 indipendente, con quattro processori Pentium III da 500 MHz e Microsoft SQL Server Tutte le prove sono state eseguite usando 100 utenti virtuali (VU) simulati con Segue SilkPerformer V. Come nel caso di Windows e Solaris, le prove con Linux hanno dimostrato che ColdFusion MX for JRun invia più contenuto con tempi di risposta delle pagine più rapidi rispetto alle versioni precedenti di ColdFusion. Tempi di risposta medi delle pagine (secondi) Linux Tempi di risposta medi (sec.) CF5 Enterprise CFMX Enterprise CFMX JRun Versione del prodotto Figura 5: Miglioramenti nei tempi di risposta med i delle pagine su Linux 11

12 Produzione HTTP / 24 ore - Linux Hit HTTP / 24 ore Milioni CF5 Enterprise CFMX Enterprise CFMX JRun Versione del prodotto Figura 6: Richieste HTTP gestite durante un periodo di 24 ore su Linux 12

13 Clustering dei server ed istanze ColdFusion multiple Un modo per garantire disponibilità e tempi di risposta omogenei è definire dei cluster di server per gestire le applicazioni Web. Un cluster corrisponde ad un set di server che creano un'immagine unica e gestiscono il carico sulle applicazioni e sui server dividendolo tra tutti i server che fanno parte del cluster in questione. La gestione del carico in un cluster deve tenere in considerazione i seguenti fattori: Bilanciamento del carico Alternando le richieste tra i server in un cluster usando un algoritmo predefinito, ad effetto "round robin". Backup automatico del server Rerouting automatico delle richieste ad un secondo server qualora il primo sia fuori linea. La funzione di clustering dei server con ColdFusion MX for JRun consente inoltre l'isolamento dei processi e l'esecuzione di applicazioni diverse nelle proprie istanze ColdFusion. Questo impedisce che il blocco di un'applicazione causi il blocco di altre. Deviazione standard e riciclo automatico Deviazione standard La deviazione standard nei tempi di risposta corrisponde alla misura del livello di discrepanza della gestione di pagine di un'applicazione sul client. L'ideale sarebbe richiedere la gestione di una richiesta di pagina nello stesso periodo di tempo, ossia il minimo possibile. Naturalmente le molte variabili che compongono un'applicazione (tempo di risposta del database, ritardi nel riciclo automatico, ecc.) portano sempre a tempi di risposta diversi. L'obiettivo di un'applicazione ben definita è ridurre al minimo le deviazioni nei tempi di risposta, garantendo un'esperienza omogenea per l'utente finale. Nessuno vuole usare un'applicazione in cui una pagina potrebbe essere visualizzata la prima volta entro un secondo, mentre la seconda volta in cinque secondi. ColdFusion MX for JRun vi consente di effettuare il clustering di più istanze di server applicativi su un solo computer (o più computer). Quando si opta per questa tecnica, la deviazione standard nei tempi di risposta delle pagine risulta ridotta. Abbiamo effettuato una prova eseguendo la stessa applicazione di prova Tack2++ su una sola istanza di server, configurando quindi di eseguirla su quattro istanze di server in un cluster su un solo computer. La Figura 7 illustra la deviazione standard nei tempi di risposta per le singole pagine dell'applicazione di prova in ciascuna configurazione. Come dimostrato nel grafico, tutte le pagine riportano deviazioni ridotte nei tempi di risposta, alcune persino del 50%. 13

14 Dimostrazione delle varianze dei tempi di risposta ridotti (deviazione standard) con configurazione di server cluster Deviazione standard nei tempi di risposta Server singolo Quattro server cluster Figura 7: Dimostrazione delle varianze nei tempi di risposta ridotti (deviazione standard) con una configurazione di server cluster Riciclo automatico La specifica per il linguaggio di programmazione Java include un concetto denominato 'riciclo automatico', in cui l'ambiente di runtime pulisce automaticamente gli oggetti creati dal programmatore. Questa funzione di riciclo automatico prevede dei costi di gestione nella Java Virtual Machine (JVM), associati alla riduzione periodica delle prestazioni corrispondente ai momenti in cui si attiva la funzione di riciclo automatico. Le moderne JVM riportano un numero maggiore di opzioni per controllare la funzione di riciclo automatico al fine di aumentare le prestazioni. I dati per questa impostazione, in dotazione al sistema Sun SDK, sono disponibili per il riciclo automatico parallelo al seguente indirizzo Questa opzione riduce l'effetto "fermiamo tutto" di chi effettua il riciclo automatico, distribuendo il lavoro tra tutti le CPU del computer. Il clustering di svariate istanze di server applicativi su un solo computer riduce ulteriormente questo effetto, poiché molto probabilmente solo una delle istanze effettua il riciclo automatico in un dato momento. Abbiamo effettuato una prova con un'applicazione Tack2++ su una sola istanza di server, configurando quindi di eseguirla su quattro istanze di server in un cluster su un solo computer ad 8 processori. Le Figure 8 e 9 illustrano la percentuale di utilizzo delle CPU per tutti i processori in un dato periodo di tempo di prova (circa 20 secondi). La Figura 8 illustra una singola istanza di server. In questo caso l'effetto "fermiamo tutto" è chiaramente visibile ad un punto in cui tutti i processori, tranne uno, scendono oltre il livello di utilizzo del 40%. Anche superando il limite di tempo, l'utilizzo della CPU risulta sporadico ed è in media compreso tra il 70 e l'80%. Chiaramente questo non rappresenta un utilizzo ottimale dell'hardware. 14

15 Server singolo % di utilizzo Figura 8: singolo 0 13:51 13:52 13:53 13:54 13:55 13:56 13:57 13:58 13:59 14:00 14:01 14:02 14:03 14:04 14:05 14:06 14:07 14:08 14:09 14:10 processore 1 processore 2 processore 3 processore 4 processore 5 processore 6 processore 7 processore 8 L'effetto "fermiamo tutto" sull'utilizzo della CPU in una configurazione a server Nella seconda prova abbiamo usato lo stessa applicazione sullo stesso hardware, ma con una configurazione di quattro istanze cluster ColdFusion. Come illustrato nella Figura 9, questo ha eliminato completamente la riduzione di utilizzo della CPU osservato nella Figura 8. Inoltre, ha consentito un livello di utilizzo della CPU superiore ed indisturbato durante tutta la prova. Quattro server cluster % di utilizzo Figura 9: tempo 24:21 24:22 24:23 24:24 24:25 24:26 24:27 24:28 24:29 24:30 24:31 24:32 24:33 24:34 24:35 24:36 24:37 24:38 24:39 24:40 Quattro server cluster ColdFusion illustrano un utilizzo efficiente della CPU nel 15 processore 1 processore 2 processore 3 processore 4 processore 5 processore 6 processore 7 processore 8

16 Appendice Risultati delle prove Tempi di risposta di Windows 2000 (secondi) Numero di processori Versione del prodotto: ColdFusion Server 5 Enterprise 1,3370 0,7630 0,4520 0,3250 ColdFusion MX Server Enterprise 0,9110 0,5580 0,3950 0,3180 ColdFusion MX for JRun 0,7951 0,4737 0,2994 0,2179 Produzione HTTP su Windows 2000 (24 ore) Numero di processori Versione del prodotto: ColdFusion Server 5 Enterprise ColdFusion MX Server Enterprise ColdFusion MX for JRun Tempi di risposta di Solaris Versione del prodotto: Tempi di risposta (sec.) ColdFusion Server 5 Enterprise 1,0162 ColdFusion MX Server Enterprise 0,7204 ColdFusion MX for JRun 0,

17 Produzione HTTP su Solaris (24 ore) Versione del prodotto: Hit HTTP ColdFusion Server 5 Enterprise ColdFusion MX Server Enterprise ColdFusion MX for JRun Tempi di risposta su Linux Versione del prodotto: Tempi di risposta (sec.) ColdFusion Server 5 Enterprise 1,0162 ColdFusion MX Server Enterprise 0,5485 ColdFusion MX for JRun 0,3408 Produzione HTTP su Linux (24 ore) Versione del prodotto: Hit HTTP ColdFusion Server 5 Enterprise ColdFusion MX Server Enterprise ColdFusion MX for JRun

18 Varianze nei tempi di risposta (deviazione standard) con una configurazione di 4 server cluster Tempi di risposta massimi Tempi di risposta minimi STDD Pagina Singolo Cluster Singolo Cluster Singolo Cluster 01_Index 3,922 3,454 0,016 0,015 0,141 0,134 02_MenuPage 3,485 3,407 0,031 0,015 0,155 0,117 03_SailList 9,25 3,438 0,016 0,016 0,149 0,123 04_Python 4,234 3,422 0,016 0,015 0,138 0,113 05_RtnCurrent 9,375 9,531 0,015 0,031 0,164 0,124 06_CAAD4 9,375 3,406 0,015 0,016 0,156 0,121 07_Bjorn 9,094 3,469 0,015 0,031 0,151 0,116 08_Aerobolt 9,25 3,39 0,015 0,031 0,15 0,116 09_RtnCats 9,39 3,406 0,015 0,031 0,153 0,121 10_MastList 9,282 9,296 0,015 0,047 0,159 0,141 11_Lightning 9,375 3,422 0,031 0,031 0,171 0,137 12_Ripper 9,641 3,391 0,031 0,032 0,141 0,118 13_BoardsList 9,359 3,437 0,032 0,031 0,164 0,121 14_Rocket 3,485 9,5 0,031 0,046 0,151 0,128 15_Mondo 9,672 3,422 0,015 0,031 0,161 0,116 16_FirstItem 3,782 3,235 0,063 0,078 0,133 0,113 17_BuySecond 3,25 3,297 0,062 0,062 0,15 0,112 18_Checkout 3,438 3,25 0,047 0,047 0,143 0,1 19_FindCust 4,437 3,438 0,109 0,141 0,203 0,155 20_Confirm 3,187 3,281 0,062 0,062 0,121 0,104 21_Continue 9,297 3,36 0,047 0,047 0,167 0,137 22_CustEntry 3,235 2,891 0,063 0,093 0,169 0,098 23_SaveCust 9,532 3,703 0,109 0,234 0,225 0,164 18

19 Dettagli sull'applicazione di prova Tack2++ L'applicazione Tack2++ rappresenta una tipica applicazione di e-commerce composta da un catalogo, un carrello degli acquisti, pagine di pagamento alla cassa, ecc. Sebbene i vantaggi riscontrati con altre applicazioni possano variare secondo l'ambito e la complessità delle applicazioni, gli utenti possono aspettarsi di ottenere risultati simili con applicazioni e configurazioni server simili. La combinazione di carico utente usata in questa prova è generalmente più esigente dei siti di e-commerce più comuni sul Web. In questa suite di prove, ciascun utente virtuale inizia e completa un acquisto, laddove gli studi hanno dimostrato che all'incirca il 90% di tutto il traffico su un tipico sito di e-commerce sul Web include attività di browsing e meno del 5% di tutti gli utenti aggiunge articoli al carrello degli acquisti e passa alla cassa. Ciascuna sessione utente nella suite di prove è composta dalle seguenti serie di richieste: Menu principale Articoli presentati Articoli specifici Aggiunta di articoli al carrello Pagamento Immissione di informazioni sul cliente Informazioni sull'ordine Sono state generate richieste http simultanee per simulare 100 sessioni di client virtuali. Questa attività simulata rientra nei limiti tra tre e dodici milioni di richieste al giorno. Come spiegato in precedenza, le variazioni nei numeri di richieste al giorno tra ColdFusion Server 5, ColdFusion MX Server Enterprise Edition e ColdFusion MX for JRun sono il risultato di impostazioni diverse per i server per il numero di richieste simultanee consentite. Ciascuna prova dello stress è stata eseguita svariate volte per confermarne l'accuratezza. Per questo documento abbiamo usato i risultati medi delle prestazioni. Nelle applicazioni Web vere e proprie, la maggior parte del tempo della sessione passa aspettando che l'utente faccia qualcosa. Un sito Web di grosse dimensioni potrebbe avere centinaia di sessioni utente aperte, mentre solo alcune dozzine stanno presentando richieste attive sul server applicativo. Il resto delle sessioni attende che l'utente faccia qualcosa. Ricreare pause ed errori realistici da parte degli utenti è molto difficile, e pertanto ai fini di questa prova, le pause utente sono state eliminate completamente. Di conseguenza 100 sessioni simultanee di utenti virtuali non rappresentano 100 utenti simultanei, bensì il numero di utenti simultanei sarebbe sicuramente molto superiore. Sebbene il rapporto esatto tra sessioni aperte e sessioni attive sia difficile da generalizzare a causa della disparità nelle applicazioni Web, una prova usando 500 utenti virtuali si tradurrebbe all'incirca in sessioni utente aperte. 19