Perché usare una sala d'attesa virtuale basata sulle tariffe?

Quanti utenti simultanei può gestire un server web?

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

Quanto è preciso un sistema di code basato sul tasso?

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.

Un modo semplice per calcolare il tasso di coda

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.

Errore #1: Utenti contemporanei vs. Richieste contemporanee vs. Connessioni contemporanee vs. Sessioni contemporanee

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.

Sbagliare questo può mandare in crash il tuo sito web!

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?

Convertire le richieste concorrenti in utenti concorrenti

Per calcolare il numero massimo di Utenti contemporanei dal numero massimo di Richieste contemporanee, è necessario sapere che

1. Il numero di pagine nel suo flusso di transazioni
2. Il tempo medio di transazione del visitatore dalla prima all'ultima pagina del tuo flusso
3. Quante richieste compongono ogni pagina, in media
4. Il tempo medio che il tuo server impiega per elaborare una singola richiesta HTTP

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).

Fare i conti

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

Errore #2: I server web diventano più lenti con il carico

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.

Quindi cosa devo fare?

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!

Errore #3: Aumentare il tasso troppo rapidamente dopo l'apertura di una coda

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.

Errore #4: Schiodare i vostri server

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.

Conclusione

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:

1. Iniziate con un Queue Rate impostato a 10, o il vostro tasso di transazioni in un giorno più normale.
2. Guarda il carico del tuo processore e altri indicatori di performance.
3. Aspettate che i nuovi ordini vengano registrati nel vostro database sql a una velocità uguale o simile a quella della vostra frequenza di coda.
4. Premi CTRL-SHIFT-R sulle tue pagine per controllare la reattività.
5. Aumentate il Queue Rate di non più del 20%.
6. Torna al punto 2 e aspetta di nuovo.
7. Una volta che la dimensione della coda diminuisce o aumenta costantemente meno rapidamente ogni minuto, e il tempo di attesa mostrato è inferiore a 50 minuti, non c'è bisogno di andare più veloce.
8. Siediti e rilassati! Queue-Fair ti copre.

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.