Test di Carico

Quali fattori influenzano i risultati del test di carico?

• La latenza di rete tra il generatore di carico e il server (si consiglia di eseguire il test in rete locale o in locale)
• La larghezza di banda tra il generatore di carico e il server (si consiglia di eseguire il test in rete locale o in locale)
• Se HTTP keep-alive è abilitato (si consiglia di abilitarlo)
• Se il numero di connessioni simultanee è sufficiente (nell'analisi esterna, è meglio abilitare connessioni simultanee maggiori)
• Se il numero di processi sul server è ragionevole (per il processo "helloworld" si consiglia il numero di processi uguale al numero di CPU, per i processi del database si consiglia di avere quattro volte il numero di CPU o più)
• Le prestazioni intrinseche del servizio (ad esempio, se si utilizza un database esterno)

Cos'è HTTP keep-alive?

Il meccanismo HTTP Keep-Alive è una tecnica utilizzata per inviare più richieste e risposte HTTP su una singola connessione TCP, che ha un grande impatto sui risultati dei test di prestazione; disattivando keep-alive, il QPS può diminuire drasticamente.
Attualmente, i browser hanno keep-alive abilitato per impostazione predefinita, il che significa che dopo che il browser ha visitato un determinato indirizzo HTTP, manterrà temporaneamente la connessione aperta e la riutilizzerà per la richiesta successiva, contribuendo a migliorare le prestazioni.
Si consiglia di abilitare keep-alive durante i test di prestazione.
Inoltre, se keep-alive non è abilitato durante il test di carico, le porte locali del client verranno rapidamente esaurite dallo stato timewait, risultando in un numero totale di richieste che, superata una certa soglia (generalmente circa 28.000), porterà a richieste fallite.

Come abilitare HTTP keep-alive durante il test di carico?

Se si utilizza il programma ab per il test di carico, è necessario aggiungere il parametro -k, ad esempio ab -n100000 -c200 -k http://127.0.0.1:8787/.
apipost deve restituire l'intestazione gzip per abilitare keep-alive (bug di apipost, vedere sotto).
Altri programmi di test di carico in genere hanno keep-alive abilitato per impostazione predefinita.

Perché il QPS è molto basso durante il test di carico esterno?

È normale che il QPS sia basso a causa dell'elevata latenza esterna. Ad esempio, il QPS per il test di carico della pagina baidu potrebbe essere solo di alcune decine.
Si consiglia di eseguire il test di carico in rete locale o in locale, per escludere l'influenza della latenza di rete.
Se si deve eseguire il test di carico in rete esterna, è possibile aumentare il numero di connessioni simultanee per aumentare il throughput (assicurandosi che la larghezza di banda sia sufficiente).

Perché le prestazioni diminuiscono dopo l'uso di un proxy nginx?

L'esecuzione di nginx richiede risorse di sistema. Allo stesso tempo, la comunicazione tra nginx e webman richiede anche risorse.
Tuttavia, le risorse di sistema sono limitate e webman non può accedere a tutte le risorse di sistema; quindi, è normale che le prestazioni complessive del sistema possano diminuire.
Per ridurre al minimo l'impatto sulle prestazioni causato dal proxy nginx, si può considerare di disabilitare i log di nginx (access_log off;),
e abilitare keep-alive tra nginx e webman, vedere proxy nginx.

Inoltre, rispetto a http, https consuma più risorse, poiché https richiede la stretta SSL/TLS, la crittografia e decrittografia dei dati, e il maggiore dimensione dei pacchetti occupa più larghezza di banda, tutto ciò può portare a una diminuzione delle prestazioni.
Se si utilizza una connessione breve (senza abilitare HTTP keep-alive) durante il test di carico, ogni richiesta richiederà comunicazioni aggiuntive per la stretta SSL/TLS, il che ridurrà notevolmente le prestazioni. Si consiglia di abilitare HTTP keep-alive durante il test di carico su https.

Come sapere se il sistema ha raggiunto il limite delle prestazioni?

In generale, se la CPU raggiunge il 100%, significa che le prestazioni del sistema hanno raggiunto il limite. Se c'è ancora spazio libero sulla CPU, significa che non si è ancora raggiunto il limite; in questo caso, è possibile aumentare le connessioni simultanee per aumentare il QPS.
Se aumentando le connessioni simultanee non si riesce ad aumentare il QPS, potrebbe essere a causa del numero insufficiente di processi webman; si consiglia di aumentare adeguatamente il numero di processi webman. Se ancora non si riesce ad aumentare, controllare se la larghezza di banda è sufficiente.

Perché i risultati del mio test di carico mostrano che le prestazioni di webman sono inferiori a quelle del framework gin di go?

I test di techempower mostrano che webman supera gin quasi per il doppio in tutti gli indicatori, come testo puro, query database e aggiornamento database.
Se i tuoi risultati sono diversi, potrebbe essere perché stai utilizzando ORM in webman, il che porta a una perdita di prestazioni significativa; prova a confrontare webman + PDO nativo con gin + SQL nativo.

Di quanto si perde in prestazioni utilizzando ORM in webman?

Di seguito è riportato un set di dati dei test di carico

Ambiente
Server Alibaba Cloud 4 core, 4G, database MySQL locale, interrogazione casuale di un record da 100.000 record e restituzione in formato json, test in locale.

Se si utilizza PDO nativo
webman QPS è 17.800

Se si utilizza Db::table() di laravel
webman QPS scende a 9.400 QPS

Se si usa il Model di laravel
webman QPS scende a 7.200 QPS

I risultati di thinkORM sono simili, senza grandi differenze.

Nota
Anche se l'uso di ORM comporta una certa perdita di prestazioni, per il 99% delle aziende le prestazioni sono già significativamente sovradimensionate; se sei proprio quel 1%, puoi comunque risolvere facilmente il problema aumentando CPU o server.
Dobbiamo trovare un punto di equilibrio tra efficienza di sviluppo, manutenibilità, prestazioni e altri indicatori, piuttosto che perseguire ciecamente le prestazioni.

Perché il QPS è molto basso utilizzando apipost per i test di carico?

Il modulo di test di carico di apipost presenta un bug: se il server non restituisce l'intestazione gzip, non può mantenere keep-alive, causando una diminuzione significativa delle prestazioni.
Una soluzione consiste nel comprimere i dati e aggiungere l'intestazione gzip alla risposta, ad esempio

<?php
namespace app\controller;
class IndexController
{
    public function index()
    {
        return response(gzencode('hello webman'))->withHeader('Content-Encoding', 'gzip');
    }
}

Inoltre, in alcune situazioni, apipost potrebbe non fornire il carico desiderato; ciò si manifesta con lo stesso numero di connessioni simultanee, mentre usando apipost si ottiene un QPS circa inferiore del 50% rispetto ad ab.
Si consiglia di utilizzare ab, wrk o altri software professionali per i test di carico piuttosto che apipost.

Impostare un numero adeguato di processi

Webman abilita per impostazione predefinita un numero di processi pari a cpu*4. In realtà, per testare il processo "helloworld" senza rete IO, il numero di processi uguale al numero di core della CPU offre le prestazioni migliori, poiché riduce i costi di cambio di contesto.
Se ci sono richieste di IO bloccanti come database e redis, il numero di processi può essere impostato da 3 a 8 volte il numero di CPU, poiché in questo caso sono necessari più processi per aumentare la concorrenza, mentre il costo di cambio di contesto è relativamente trascurabile rispetto a IO bloccante.

Alcuni riferimenti per i test di carico

Server Cloud 4 core, 4G, 16 processi, test in locale/rete locale

Dati di test di carico di techempower di terze parti

Esempio di comando per il test di carico

ab

# 100000 richieste, 200 connessioni simultanee, keep-alive abilitato
ab -n100000 -c200 -k http://127.0.0.1:8787/

# 100000 richieste, 200 connessioni simultanee, keep-alive disabilitato
ab -n100000 -c200 http://127.0.0.1:8787/

wrk

# Test di carico con 200 connessioni simultanee per 10 secondi, keep-alive abilitato (predefinito)
wrk -c 200 -d 10s http://example.com