Non siamo riusciti a trovare alcun vantaggio rispetto a one-out, one-in. In poche parole, il problema di questo approccio è che quando gli utenti sono visitatori di siti web di commercio elettronico, il server web non sa quanti utenti contemporanei ha in ogni momento. È un ostacolo. Ecco perché.
Più avanti in questo articolo, vi diciamo anche come utilizzare una camera virtuale basata sulla tariffa per proteggere anche il vostro sito.
Tradizionalmente i server di e commerce vengono predisposti per supportare un numero massimo di utenti contemporanei e il carico viene spesso definito in questo modo. L'utilizzo di questo approccio per gestire la coda di un sito web presenta un problema che risolviamo con le tariffe.
Il problema sorge perché i visitatori stanno effettivamente utilizzando il webserver solo mentre il loro browser sta caricando ogni pagina web.
Ad esempio, supponiamo che un sito di commercio elettronico venda biglietti. Dall'inizio del percorso del visitatore alla fine del percorso (la sessione dell'utente) ci sono sei pagine, poiché il visitatore
L'intero processo di transazione richiede cinque minuti, in media.
Supponiamo, sempre a titolo di esempio, che ogni minuto arrivino 100 visitatori per acquistare i biglietti e che il tempo medio per completare il processo sia di cinque minuti. In un dato momento, ci sono 500 persone che stanno effettuando la transazione nello stesso momento e il server deve essere predisposto per supportare 500 utenti contemporanei.
Si potrebbe pensare di creare un contatore di utenti concorrenti che viene incrementato ogni volta che un nuovo visitatore arriva alla home page e decrementato ogni volta che un visitatore completa la transazione, in modo da sapere quanti utenti vengono gestiti da un singolo server in qualsiasi momento, ma questo non funziona.
Non funzionerà perché non tutti i visitatori completano la transazione. La gente cambia idea, o si distrae, o se ne va e torna più tardi. Poiché il webserver sta interagendo con i visitatori solo quando i loro browser stanno caricando le pagine, il webserver non ha modo di sapere quando questo è successo, o a chi.
Invece, per determinare che un visitatore non fa più parte del processo di transazione, il singolo server deve attendere che non arrivino più richieste di pagine da parte di quel visitatore e quindi spegnere la sessione di quel visitatore. Il timeout deve essere sempre impostato su un tempo molto più lungo della durata media della transazione (ad esempio 20 minuti in questo esempio), poiché alcuni visitatori impiegano molto più tempo di altri per completare la loro transazione.
Si potrebbe aggiungere la possibilità di diminuire il proprio contatore nozionale di utenti concorrenti ogni volta che la sessione di un visitatore termina in questo modo, ma questo dà risultati molto scarsi.
Se il 10% dei 100 visitatori che arrivano ogni minuto non completano la transazione, quelli che la completano saranno attivi in media per cinque minuti e quelli che non la completano saranno considerati sempre attivi per almeno 20 minuti (in realtà il timeout della sessione più la durata media della sessione è più probabile se si considerano le sessioni multiple).
Sono 90 * 5 + 10 * 20 = 650, e il server riporterà 650 utenti concorrenti, anche se in realtà è meno occupato!
Inoltre, ben 10 * 20 = 200 di questi utenti concorrenti non stanno effettivamente utilizzando il sito e sono in fase di time out, che è più del 30% degli utenti concorrenti segnalati, anche se è solo il 10% dei visitatori che non riescono a completare la transazione.
Ora diciamo che si vuole aggiungere una coda a questo sito, controllata dal nostro contatore di utenti concorrenti. Una volta che il sito è a capacità, allora un individuo che è in testa alla coda sarà passato al sito solo quando il contatore diminuisce. Questo è chiamato una coda one-out-one-in. Quello che succederà è che il 30% del tempo, una persona in cima alla coda starà aspettando che qualcuno che non completerà la sua transazione finisca di non completarla.
C'è anche il lavoro di integrazione tecnica aggiuntivo e il carico sul sito web per la creazione e il funzionamento del contatore e la condivisione delle informazioni con il sistema delle code. Se il meccanismo di condivisione o di conteggio va in tilt o si rompe, la coda si blocca. Ancora peggio, se il singolo server è così occupato da non riuscire ad aggiornare il server delle code per dire a quest'ultimo di far entrare la persona successiva, anche la coda si blocca.
Tutti questi problemi sono facilmente e semplicemente risolti inviando invece i visitatori dalla parte anteriore della coda ad un tasso costante e fisso - in questo caso 100 visitatori al minuto.
In questo modo non c'è bisogno di misurare il numero effettivo di utenti concorrenti, e non c'è bisogno di un'integrazione complessa con il sito web di ticketing, e nessun rischio che la coda si blocchi.
Ecco perché nel 2004 abbiamo inventato e brevettato la sala d'attesa virtuale basata sulle tariffe per i siti web più frequentati.
‘Brillante. Ho passato una notte insonne con il timore che il sito web si bloccasse di nuovo dopo l'ultima volta che abbiamo provato a gestire la nostra popolare promozione senza Queue-Fair. Sono molto felice di aver trovato la vostra soluzione. Grazie per la vostra reattività: è molto apprezzato il fatto che l'abbiate configurata in meno di un giorno e che abbia funzionato perfettamente. Fantastico. Un'ottima soluzione. D'oro. Grazie ancora; questo significa molto per me. Stanotte dormirò bene. Leggendario.’
‘Queue-Fair è onestamente un prodotto straordinario - altamente raccomandato. Vorrei che avessimo cambiato prima! L'intero processo fino all'implementazione è stato uno dei più fluidi che abbia mai sperimentato. Queue-Fair ha funzioni aggiuntive che il nostro precedente fornitore non era in grado di realizzare, quindi il passaggio è stato facile. Chiunque sia alla ricerca di un prodotto per le code non dovrebbe cercare oltre. Lo adoriamo!’
‘La comunicazione è stata davvero fluida e tutto ha funzionato bene. La campagna è stata un successo: siamo stati sempre nella zona verde con il nostro server! Tutto ha funzionato, sia dal punto di vista tecnico che da quello del cliente, e abbiamo ricevuto un feedback positivo. Vi consigliamo di contattare Queue-Fair! Sono lieto di aver trovato la soluzione ai nostri problemi.’
‘Quando abbiamo aperto le vaccinazioni COVID ai giovani tra i 16 e i 29 anni, ci siamo rivolti a Queue-Fair, che ci ha rapidamente allestito una sala d'attesa virtuale completamente brandizzata. Quel pomeriggio, Queue-Fair ha messo in coda 450.000 persone per noi. Queue-Fair ha fatto sì che il nostro sistema fosse in grado di accettare le prenotazioni a un ritmo adeguato, senza sovraccaricarsi. Siamo molto grati per l'eccezionale supporto di Queue-Fair e il lancio è avvenuto con grande successo. La coda ha funzionato perfettamente e ci ha aiutato a superare un problema tecnico puntualmente scoperto che altrimenti avrebbe rovinato la campagna. Grazie mille a Queue-Fair per la sua offerta! È molto apprezzato. Queue-Fair ci ha salvato!’
‘Tutto ha funzionato perfettamente! Lo userò ogni volta che avremo un picco di traffico per non perdere nessun visitatore. Queue-Fair è la soluzione più economica sul mercato. Pochi minuti per l'installazione. Ottimo supporto e ottima reattività. Pagine facili da modificare. Il miglior rapporto qualità/prezzo che si possa ottenere per gestire eventi critici, sono stato in grado di gestire senza problemi un picco di traffico di oltre 10.000 visitatori da uno show televisivo.’
‘Abbiamo eventi che sono estremamente popolari, con il risultato di un gran numero di persone che visitano il nostro sito web in una sola volta. Queue-Fair aiuta a gestire tutto ciò, risolvendo il problema. Abbiamo apprezzato soprattutto il supporto durante la configurazione e la facilità d'uso. Raccomandiamo Queue-Fair perché è un'ottima alternativa ad altri fornitori di code, offrendo un supporto eccellente.’
‘Ottimo servizio con un ottimo team! Imbarco facile, efficiente per far fronte ai picchi di carico! Elevata disponibilità del servizio!’
‘Queue Fair è una soluzione robusta e facile da usare per gestire i picchi di visitatori previsti e imprevisti. La guida e la comunicazione con il team sono state molto piacevoli; le nostre domande hanno ricevuto risposte tempestive. È rassicurante sapere che possiamo sempre applicare una misura di gestione attivando Queue Fair per gestire picchi inaspettati di visitatori. Non ci sono svantaggi nell'utilizzo di Queue-Fair.’
‘Eccellente! Facile da usare, facile da configurare e da usare - e superba comunicazione aziendale! Queue-Fair funziona benissimo quando le cose si scaldano e aiuta a ridurre il carico del sito web di ticketing. Costruendo Queue-Fair tenendo conto della facilità d'uso, il team di supporto ha potuto utilizzarlo senza bisogno di sviluppatori!’
‘Queue-Fair è una piattaforma solida con un ottimo servizio clienti. Il loro sistema di code robusto ed equo ci ha tolto molto dello stress di gestire una vendita flash. Non c'è nulla che non piaccia! Provate, non rimarrete delusi.’
‘Siamo molto contenti di avere Queue-Fair come partner della sala d'attesa per i tre grandi eventi di lancio dell'iPhone. Il nostro sito web non si è bloccato! Abbiamo persino superato il nostro obiettivo di vendita, grazie a Queue-Fair! La piattaforma Queue-Fair è user-friendly, molto facile da usare, e i report sui dati ci hanno fornito indicazioni significative per i nostri progetti futuri. Siamo molto felici di averli come partner :) Queue-Fair sarà sicuramente l'unica sala d'attesa che raccomanderemo ai nostri cari amici. Più potere a Queue-Fair! Ottimo lavoro!’
‘Uno strumento facile da usare e un team reattivo. Ogni sabato offriamo un numero limitato di prodotti in pre-ordine, creando un sovraccarico massiccio e rapido del server. Dovevamo trovare una soluzione per assorbire il traffico e rendere più fluida l'esperienza di acquisto dei nostri clienti. Lo strumento è stato facile da configurare sul mio sito web. La documentazione è completa e accurata.’
Se si conosce il numero di utenti contemporanei gestiti da un server web e il tempo medio di transazione o la durata della visita, dalla prima pagina del flusso di transazioni alla pagina di conferma dell'ordine, è possibile convertirlo in un tasso di coda utilizzando la legge di Little, dividendo il numero di utenti per la durata, in questo modo:
Tasso di coda = utenti concorrenti / tempo di transazione
Queue-Fair invierà visitatori al vostro sito web alla velocità da voi specificata - disponiamo dell'intelligenza artificiale di coda di gran lunga più accurata del settore per garantire che il numero di visitatori che desiderate ogni minuto sia il numero di visitatori che ricevete ogni minuto, tenendo conto automaticamente delle persone che non sono presenti quando viene chiamato il loro turno e di quelle che tornano in ritardo.
Come si traduce questo dato nel numero di utenti contemporanei? Naturalmente, non tutti i visitatori che raggiungono il vostro sito impiegheranno l'esatto tempo medio per completare la transazione, ma con Queue-Fair otterrete un numero molto costante di utenti concorrenti, grazie alla legge dei grandi numeri.
Ad esempio, supponiamo che abbiate un tasso di coda di 100 visitatori al minuto. Invieremo 100 visitatori al vostro sito ogni minuto in un flusso costante: è quello che facciamo e siamo straordinariamente bravi a farlo. Diciamo anche che le persone utilizzano il vostro sito web per una media di cinque minuti, con il 70% di loro che impiega tra i 4 e i 6 minuti dal momento in cui passa dalla coda al momento in cui effettua l'ultima richiesta di pagina (che completi o meno una transazione). Si tratta di una deviazione standard di un minuto rispetto alla media. Statisticamente parlando, ciò significa che per ogni visitatore che impiega cinque minuti e mezzo, ce ne sarà un altro che ne impiega quattro e mezzo, e queste variazioni nella durata delle visite individuali in più sessioni tendono quindi ad annullarsi a vicenda quando se ne contano molte. La legge dei grandi numeri dice che questo annullamento diventa tanto più esatto quanto maggiore è il numero di persone coinvolte.
Quanto esattamente? Possiamo risolverlo con un po' di statistica. La dimensione del campione è di 5 * 100 = 500, che è il Grande Numero in questione. Questo è il numero di persone da contare. Ciò significa che l'errore standard nella media per il tempo di transazione è 1 (la deviazione standard, 1 minuto) diviso per la radice quadrata della dimensione del campione (quindi la radice quadrata di 500) secondo la formula statistica per l'errore standard nella media, che dà un errore standard nella media per il tempo di transazione di 0,044 minuti, o solo 2,7 secondi, che è meno dell'uno per cento.
Ciò significa che con una velocità di coda di 100 e un tempo di transazione di 5 minuti più o meno per ogni singolo visitatore, dovreste aspettarvi tra i 495 e i 505 utenti simultanei sul vostro sito per circa il 70% del tempo.
Ma i calcoli sono accurati? Ci sono alcune sottigliezze: per esempio, la dimensione del campione che stiamo allegramente elevando al quadrato non è sempre esattamente 500 ogni volta che vengono contati gli utenti concorrenti (cioè in ogni momento), e inoltre una distribuzione normale (gaussiana) può dare tempi di transazione negativi che non si verificano nella vita reale. Per questo motivo, utilizziamo un simulatore di visitatori, secondo per secondo, per effettuare misurazioni e verificare questo tipo di calcoli, e questo ci dice che con le cifre di cui sopra, dovreste aspettarvi tra i 493 e i 507 visitatori il 70% delle volte, quindi i calcoli reggono molto bene! La misurazione dei dati ci dice anche che il vostro sito avrà 500 ± 15 utenti contemporanei almeno il 95% delle volte.
Probabilmente è più stabile della precisione con cui il vostro server web può misurare il numero di persone che utilizzano il vostro sito! Inoltre, la cosa più interessante è che anche se non avete idea di quale sia il tempo medio di transazione o la deviazione standard dei vostri visitatori, queste grandezze matematiche esistono indipendentemente dal fatto che le conosciate o meno e otterrete comunque un carico stabile.
Il risultato è che Queue-Fair fornirà il numero di visitatori al minuto desiderato con una precisione praticamente perfetta, con il risultato di un numero molto costante di utenti contemporanei sul vostro sito e un carico stabile del server web su cui avete il controllo totale.
Evviva!
E ora un avvertimento. Vale la pena notare che la stabilità del numero di utenti contemporanei sul vostro sito - e quindi la stabilità del carico del vostro server - dipende in modo critico dall'accuratezza con cui il vostro fornitore di Sala d'attesa virtuale vi invia il numero di visitatori che desiderate ogni minuto, e questo è quindi un fattore chiave quando scegliete una piattaforma di Sala d'attesa virtuale. Poiché forniamo la Sala d'attesa virtuale più accurata al mondo, nessuno meglio di Queue-Fair impedisce ai vostri server di ingolfarsi.
Cosa succede se non sai quanti utenti concorrenti può gestire un server, o il tempo di transazione? Puoi guardare la pagina che probabilmente è il tuo collo di bottiglia - di solito quella che è il risultato di un clic su un pulsante "Acquista ora". Usa Google Analytics per trovare i visitatori unici mensili di quella pagina, o conta i tuoi ordini mensili. Dividi questo per 30 * 24 * 60 = 43.200 che è il numero di minuti in un mese (circa). Questa è la tua media di visitatori al minuto per tutto il mese. Moltiplica questo per tre. Questa è la tua media di visitatori al minuto durante le ore di lavoro (circa). Raddoppialo. Questa è probabilmente una cifra sicura da usare per il Queue Rate.
Ad esempio, supponiamo di elaborare 100.000 ordini al mese, ovvero 100.000 clic sul pulsante "Acquista ora". Sono 100.000 / 43.200 = 2,31 ordini al minuto. Si prevede che la maggior parte di questi ordini avvenga durante il giorno e che i server siano più silenziosi di notte, quindi moltiplicate per 3 e otterrete 7 ordini al minuto come stima approssimativa di quanto sia occupato il vostro server durante l'orario di lavoro. Se la cifra risultante è inferiore a 50: ci saranno picchi e cali di domanda, quindi se il vostro server non è notevolmente lento nelle ore di punta, moltiplicate per 2 per ottenere 14 utenti attivi al minuto. Se la cifra è superiore a 50: i picchi e le flessioni da un minuto all'altro saranno minori in confronto, e non è sicuro raddoppiare questo valore. Il numero ottenuto è probabilmente una cifra sicura per la velocità di coda e corrisponde al numero di richieste al secondo che si può gestire in modo sicuro; si può sempre aumentare se si scopre che i sistemi sono ancora reattivi per le prestazioni degli utenti finali a quella velocità.
Se i tuoi ordini hanno un timestamp, puoi anche guardare il massimo degli ordini che hai preso in un singolo minuto nell'ultimo mese - ma usalo con cautela perché non saprai quanti ordini puoi aver perso durante questo minuto a causa del rallentamento dei tuoi server, quindi riducilo del 20%.
Il resto dell'articolo illustra alcuni altri modi per calcolare la velocità di coda.
Vale la pena sottolineare che ci sono almeno due definizioni di "Concurrent Users" nell'uso comune.
Utilizziamo la definizione "il numero di persone impegnate in un flusso di transazioni in qualsiasi momento". Questo è il numero chiave da conoscere per impostare il Queue Rate. È il numero di utenti che stanno visualizzando il vostro sito in questo momento. Il numero di sessioni contemporanee è di solito un po' più grande del numero di connessioni o di utenti contemporanei, perché alcune delle sessioni sono in fase di time-out, aumentando la durata media della sessione.
In contrasto con il numero di richieste contemporanee, che è il numero di richieste HTTP elaborate dal server web in qualsiasi momento. In modo molto confuso, molti tecnici intendono il numero di richieste contemporanee quando dicono il numero di utenti contemporanei.
Poi c'è la voce Connessioni simultanee (o connessioni TCP simultanee alla stessa porta del server sulla scheda di interfaccia di rete), che è il numero di socket TCP/IP aperti sulla porta del server o del servizio backend in qualsiasi momento. Quando si effettuano richieste di pagine, per impostazione predefinita i browser lasciano aperta la connessione in caso di ulteriori richieste da parte della pagina o se l'utente passa a una pagina diversa. Questo riduce il numero di richieste al secondo per aprire nuove connessioni TCP/IP, rendendo il processo del server più efficiente. I timeout per queste connessioni concorrenti variano a seconda del browser, da 60 secondi a "never-close". Il server può anche chiudere automaticamente le connessioni dopo un periodo di inattività. Sui server web Linux è possibile ottenere un conteggio delle connessioni concorrenti alla stessa porta del server con questo comando: netstat -aenp | grep ":80 \|:443 " | wc -l
che potete provare se siete curiosi. Anche in questo caso, alcuni chiamano questo fenomeno "Utenti simultanei", mentre in realtà si tratta di connessioni simultanee.
Infatti, se chiedete al vostro provider di hosting di indicarvi il numero massimo di utenti simultanei gestiti dal vostro server web (il picco di traffico), probabilmente vi darà una cifra per le Sessioni simultanee, le Richieste simultanee o le Connessioni simultanee, per il semplice motivo che non conosce il vostro tempo medio di transazione, il numero di pagine nel flusso di transazioni o qualsiasi altra informazione che gli consentirebbe di dirvi quanti utenti simultanei gestisce il vostro server web. Tutti questi numeri hanno valori diversi.
Se stai chiedendo al tuo fornitore di hosting o al tuo team tecnico informazioni sui livelli massimi di traffico, è super-importante che tu chiarisca se intendono Utenti Concorrenti, Sessioni Concorrenti, Richieste Concorrenti o Connessioni Concorrenti.
Ecco perché. Ogni pagina è una singola richiesta HTTP, ma tutte le immagini, gli script e gli altri file che provengono dalla tua applicazione web e che il browser usa per visualizzare la pagina sono anch'essi richieste HTTP.
Immaginiamo che vi sia stato detto dal vostro team tecnico che il server supporta 500 utenti concorrenti, ma in realtà intendono 500 richieste concorrenti. Con il vostro tempo di transazione di 5 minuti, usate la formula di cui sopra e supponete che il vostro sito possa supportare 100 visitatori al minuto.
Può? No.
Durante il flusso di transazioni, le persone effettuano richieste ai vostri server solo durante il caricamento di ogni pagina. Questo influisce sulla quantità di traffico al secondo o di utenti attivi che il vostro server può gestire. Su un tempo di transazione di cinque minuti, si tratta solo di pochi secondi per un utente medio. Si potrebbe quindi pensare che 500 richieste simultanee significhino che è possibile gestire molti più utenti simultanei, ma forse ci si sbaglia. Capite ora come sia complicato capire la capacità del vostro sito web in termini di traffico o di numero totale di utenti attivi?
Per calcolare il numero massimo di Utenti contemporanei dal numero massimo di Richieste contemporanee, è necessario sapere che
Probabilmente conosci già 1) e 2) - nel nostro esempio sono 6 pagine e 5 minuti. Puoi facilmente contare le pagine che vedi mentre fai una transazione. Se non conosci il tempo medio della transazione, Google Analytics può dirtelo, o puoi controllare i log del tuo server web.
Per 3) e 4), il browser Firefox può aiutare. Cliccate con il tasto destro su una pagina del vostro sito, scegliete Inspect Element e la scheda Network. Poi premi CTRL-SHIFT-R per aggiornare completamente la pagina. Vedrete i tempi di caricamento della rete per ogni elemento della pagina nella lista. Dovete assicurarvi di poter vedere le dimensioni del trasferimento nella colonna Trasferito, altrimenti i file potrebbero essere serviti da una cache che potrebbe incasinare i vostri calcoli. Potresti vedere alcuni script e altre risorse provenire da server diversi dal tuo sito, quindi puoi digitare il nome del dominio del tuo sito nella casella del filtro a sinistra. Per vedere la colonna Durata, clicca con il tasto destro su qualsiasi intestazione di colonna e seleziona Timings -> Duration dal menu a comparsa. Il tuo schermo dovrebbe assomigliare a questo:
La scheda di rete di Firefox per questa pagina, che mostra la durata e il numero di richieste da queue-fair.com
I file utilizzati nella visualizzazione delle tue pagine possono provenire da un certo numero di siti diversi, quindi vuoi anche usare il filtro in alto a sinistra per mostrare solo quelli del tuo sito - ma solo se sei sicuro che quei file da altri siti non sono la ragione per il caricamento lento della pagina, o parte del tuo collo di bottiglia.
Firefox conta le richieste per voi nella parte inferiore sinistra del display, e mostra 36 richieste HTTP soloper questa pagina.
È necessario eseguire questa operazione per ogni pagina del flusso di transazioni - contare il totale e dividere per il numero di pagine per trovare il numero medio di richieste HTTP per ogni pagina, numero 3) del nostro elenco. Ora potete capire perché il numero di richieste figlio per ogni pagina HTML è un fattore chiave per la quantità di traffico che il vostro server web è in grado di gestire.
Per il numero 4), devi guardare la colonna Durata e trovare la media di tutte le richieste HTTP per tutte le tue pagine. Se non siete sicuri, assumete mezzo secondo - c'è comunque molta incertezza in questo (vedi sotto).
Diamo alcuni numeri di esempio. Abbiamo già detto che nel flusso di processo del server di esempio ci sono sei pagine dinamiche, cioè 1), e che il tempo medio di transazione è di cinque minuti, cioè 2). Assumiamo 36 richieste HTTP per pagina per il punto 3) e mezzo secondo per il tempo di elaborazione del server per ogni richiesta HTTP, ovvero il punto 4).
Con questi numeri, un server che può gestire 500 richieste concorrenti può gestire 500 / (0,5 secondi) = 1000 richieste HTTP al secondo, che sono 60.000 richieste HTTP al minuto, quando è completamente al massimo.
Durante i cinque minuti di transazione, può gestire 5 * 60.000 = 300.000 richieste HTTP. Sembra molto, vero?
Ma, per ogni visitatore, ci sono sei pagine con una media di 36 richieste HTTP ciascuna, quindi sono 6 * 36 = 216 richieste
Quindi, la capacità di 300.000 richieste HTTP può in teoria gestire 300.000 / 216 = 1.389 utenti concorrenti
Ehi, è fantastico! Pensavamo di poter avere solo un tasso di coda di 100, ma 1.389 / 5 minuti = 278 visitatori al minuto, quindi possiamo avere un tasso di coda più alto!
Beh, probabilmente no. Per prima cosa, i vostri visitatori non invieranno ordinatamente richieste a intervalli di esattamente mezzo secondo, come il calcolo di cui sopra presuppone. Ancora più importante, avrete misurato i vostri dati di input quando il sito non è occupato. Spazzatura dentro, spazzatura fuori.
Quando il sito è occupato, il server impiega più tempo per elaborare le richieste - avrete notato questo su altri siti quando le cose sono occupate, che si aspetta più a lungo per le pagine. Questo aumenta il tempo medio che il tuo server impiega per elaborare una singola richiesta HTTP (4), il che diminuisce il throughput massimo. Quindi prendi i 278 visitatori al minuto e dimezzali. Poi dimezzalo di nuovo. Probabilmente stai realisticamente guardando circa 70 nuovi visitatori al minuto al massimo carico.
Altri fattori di confusione sono il caching, che significa che i browser dei visitatori non devono effettuare ogni singola richiesta per ogni singola pagina: ciò significa che il server ha bisogno di meno risorse e può aumentare il numero di nuovi visitatori al minuto che il server può gestire. Anche i bilanciatori di carico che distribuiscono il carico su più server e il servizio di contenuti statici piuttosto che di pagine dinamiche possono accelerare il processo del server, poiché ogni server richiede meno risorse.
Scoprirete anche che non tutte le pagine richiedono lo stesso tempo per essere completate, poiché alcune richiedono meno risorse di altre per essere prodotte e servite. Le ricerche nel database, le interrogazioni di ricerca e gli aggiornamenti richiedono il tempo più lungo, quindi avrete un collo di bottiglia da qualche parte nel vostro processo in cui le persone si accumulano, in attesa che i dati della carta di credito vengano elaborati e gli ordini memorizzati, o in attesa che venga verificata la disponibilità. Ogni flusso di transazioni ha una fase più lenta, quindi c'è sempre un collo di bottiglia da qualche parte, e c'è sempre un valore massimo alla domanda su quanti utenti contemporanei può gestire un server web, e ci possono essere diversi limiti. In questo caso, è necessario impostare una velocità di coda sufficientemente bassa per garantire che il server abbia la capacità di processare un numero sufficiente di persone simultaneamente per la fase più lenta del processo, in modo che le persone non si accumulino lì. In caso contrario, il server web può letteralmente bloccarsi.
La nostra esperienza è che, andando alla loro prima vendita, tutti sopravvalutano la capacità dei loro server di far fronte ad alti volumi di traffico.
Tutti.
Individuare con precisione la durata media delle sessioni e le prestazioni dell'utente finale in caso di traffico lento o di picco non è cosa da deboli di cuore. La cosa migliore da fare è eseguire un vero e proprio test di carico, con clienti "finti" che eseguono il processo di ordinazione durante il test di carico esattamente come farebbero nella vita reale, effettuando le stesse richieste HTTP nello stesso ordine, con le stesse attese tra le pagine durante il test di carico come nella vita reale, e tenendo d'occhio il carico del processore, il throughput IO e i tempi di risposta man mano che aumenta il numero di visitatori virtuali. A questo scopo si può usare Apache JMeter (noi apprezziamo anche K6 per carichi più leggeri o macchine più lente), ma qualunque sia lo strumento utilizzato, è lungo e difficile imitare il comportamento di ogni singolo utente nel modo giusto (soprattutto per le complessità della cache). Anche in questo caso, prendete il vostro numero massimo e dimezzatelo.
In assenza di ciò, sbagliate sul lato della cautela.
È possibile modificare facilmente la velocità di coda per qualsiasi coda Queue-Fair in qualsiasi momento utilizzando il portale Queue-Fair. Iniziate con 10 visitatori al minuto, o con il vostro tasso di transazione in un giorno normale, vedete come va per un po' di tempo dopo la messa in vendita dei biglietti e se tutto sembra a posto, il carico del processore è basso, il database sql è a posto e (soprattutto) le pagine sono reattive quando si preme CTRL-SHIFT-R, aumentatelo di non più del 20%, aspettate un po' e ripetete. Presto troverete la velocità effettiva di cui avete bisogno durante questo "bilanciamento del carico" (vedete cosa abbiamo fatto?) e ricordate che, dal punto di vista dell'esperienza del cliente, va bene aumentare la velocità di coda, perché questo fa sì che le attese stimate dei clienti in coda si riducano e tutti sono felici di vedere un tempo di risposta che offre un'attesa stimata più breve.
Ciò che si vuole evitare di fare è impostare il Queue Rate troppo alto per poi trovarsi nella posizione di doverlo abbassare, poiché questo a) significa che le persone che usano il sito sperimentano un caricamento lento delle pagine, e b) causa l'aumento delle attese stimate. Tutte le persone in coda sospireranno!
Ricordate che ci sarà un collo di bottiglia in qualche punto del processo d'ordine - ogni transazione ha una fase più lenta - e che in quel punto si accumuleranno più sessioni. Quello che non volete fare è arrivare a un minuto dalla vendita dei biglietti, vedere che il carico del processore del server è ben al di sotto del numero massimo e aumentare la velocità. Probabilmente i visitatori non sono arrivati fino al pulsante "Acquista ora". Aspettate che il vostro database sql riporti i nuovi ordini a una velocità uguale o simile a quella della vostra velocità di coda ed eseguite le misurazioni e i test di reattività in quel momento. Ricordate che ogni volta che aumentate la velocità, i visitatori in più impiegheranno lo stesso tempo per raggiungere il vostro collo di bottiglia, quindi non sarete in grado di valutare con precisione le prestazioni del vostro server alla nuova velocità fino a quando non sarà trascorso questo tempo.
Abbiamo già discusso come sia meglio aumentare gradualmente il Queue Rate una volta che la coda si è aperta. Probabilmente sei consapevole che i tuoi server hanno un limite che non può essere superato senza che il sistema vada in crash e potresti anche essere consapevole di quale sia il limite - ma quello che potresti non sapere è che quando il carico si avvicina a questo limite, di solito c'è un segno molto piccolo - spesso solo qualche errore o avvertimento, o un carico del processore superiore all'80%.
Quando i servizi web falliscono, tendono a "scattare" o a bloccarsi molto rapidamente. Questo accade normalmente perché una volta che il vostro sistema non può più elaborare le richieste alla stessa velocità con cui arrivano, si accumulano le code interne di elaborazione. Il vostro sistema deve quindi fare il lavoro di elaborare, gestire e memorizzare le sue code interne così come le richieste, e questo è ciò che porta i server oltre il limite. Molto rapidamente. Una volta che ciò accade, i vostri server possono per un certo tempo essere in grado di rispondere con una pagina di errore, ma questo non vi aiuta perché i visitatori che la vedono premono immediatamente Refresh, aggravando il carico.
Anche prima di allora, se i visitatori impiegano più di un secondo per vedere le vostre pagine, premono Refresh. Quando un visitatore preme refresh, il server web non sa che il visitatore non sta più aspettando la risposta alla richiesta originale. Se vengono ricevute sia la richiesta originale che quella di aggiornamento, il server web le elaborerà entrambe. Ciò significa più lavoro per il server web, risposte ancora più lente per tutti i visitatori e un numero maggiore di persone che effettuano il refresh, con il risultato di un circolo vizioso che manda in tilt il server web prima ancora che inizi a inviare risposte di errore.
Quindi, non spingete i vostri server più del necessario. Il rischio di ottenere quell'ultimo 20% di capacità di tempo della cpu di solito non vale la pena. Se la dimensione della coda mostrata nel portale Queue-Fair (la figura e la linea gialla di attesa nei grafici) sta diminuendo o anche solo aumentando più lentamente, minuto dopo minuto, e il tempo di attesa mostrato è di 50 minuti o meno, allora state elaborando gli ordini abbastanza velocemente e la coda alla fine si svuoterà e smetterà di mostrare le pagine di coda automaticamente, senza che dobbiate fare nulla e senza che dobbiate dire al vostro capo che l'avete spinta troppo e l'avete rotta. Alla fine ci arriverete, purché la velocità del fronte della coda sia superiore al numero di adesioni al minuto (entrambi sono mostrati nel portale Queue-Fair): il punto di svolta è di solito almeno qualche minuto dopo ogni evento. Se si vende un prodotto in quantità limitata, è probabile che si esaurisca prima che venga raggiunto il punto di svolta.
La buona notizia è che se per sbaglio impostate una velocità di coda troppo alta e i vostri server vanno in tilt, Queue-Fair può aiutarvi a tornare rapidamente operativi: basta mettere la coda in attesa finché i vostri server non saranno di nuovo pronti a gestire i visitatori. In modalità di attesa, le persone in coda vedono una pagina speciale di attesa che potete progettare prima dell'evento online. Nessuno viene fatto passare dalla parte anteriore della coda quando è in attesa, ma i nuovi visitatori di Internet possono comunque unirsi alla coda in fondo, per essere messi in coda in modo corretto una volta che il blocco è stato eliminato, cosa che avverrà molto rapidamente perché Queue-Fair sta proteggendo il vostro sito dalla domanda. La pagina di attesa è un'esperienza utente superiore rispetto all'impostazione di un tasso di coda molto basso, soprattutto se la aggiornate per dire ai visitatori a che ora prevedete di riaprire la coda, cosa facile da fare con l'editor della pagina del portale, anche quando centinaia di migliaia di persone sono già in coda - e in modalità di attesa potete anche farle passare una alla volta con l'esclusivo pulsante Ammetti uno di Queue-Fair, se necessario, mentre il vostro sistema si riprende dal blocco.
Quindi, se i vostri server hanno bisogno di una pausa durante il vostro evento, la pagina Hold è proprio quello che vi serve per questo, e aiuterà i vostri server a recuperare più rapidamente.
In questo articolo abbiamo spiegato perché una coda basata sul tasso è sempre la strada da percorrere, e abbiamo dato due metodi per calcolare il tasso di cui avete bisogno, ma a meno che non abbiate fatto un completo e accurato test di carico dei visitatori virtuali sul vostro intero flusso di transazioni, e siate davvero super extra mega sicuri di questo, il nostro consiglio è sempre lo stesso:
Se vendi un prodotto in quantità limitata, non hai bisogno di prestare attenzione nemmeno al passo 7.
Questo è per la tua prima coda, quando non conosci l'effettivo massimo Queue Rate che il tuo sistema può supportare. Per le code successive, una volta che hai misurato il Queue Rate che il tuo sistema può effettivamente gestire, potresti essere in grado di usare di nuovo la stessa cifra - ma solo se nulla è cambiato nel tuo sistema. In pratica il tuo sistema è probabilmente in costante sviluppo e modifica, e potresti non sapere come i recenti cambiamenti abbiano influenzato il tuo massimo Queue Rate - quindi perché non iniziare dalla metà della cifra misurata in precedenza e ripetere il processo di cui sopra?
Ecco quindi come utilizzare Queue-Fair per rendere la vostra vendita online piacevole e sicura, e ricordate che è sempre meglio essere sicuri che dispiaciuti.
Inventata e brevettata nel 2004, Queue-Fair è la sala d'attesa virtuale originale, che fornisce la gestione delle code online per siti web e applicazioni molto frequentati.
2024 The Fair Queue People Ltd. - Tutti i diritti riservati.
Fa parte della famiglia di soluzioni per code Orderly - OrderlyQ - OrderlyStats - WeQ4U
