2013-07-08 15 views
5

Sto utilizzando Play Framework 2.1 per sviluppare la mia app. È una struttura abbastanza facile da usare. Sono in grado di sviluppare rapidamente la mia app. Ma ho anche incontrato alcuni problemi di scalabilità. Sembra che Play 2.1 non funzioni velocemente come richiesto. Forse è perché non sapevo sintonizzare la performance.Come ottimizzare la scalabilità dell'app Play Framework?

Il mio problema è il seguente: Ho un'API per accedere a un utente con la sua email.

Ho usato Apache Benchmark (ab) per utilizzare la performance. Una singola richiesta richiede circa 230ms. Quando ci sono 5 richieste simultanee, il tempo di risposta è ancora abbastanza veloce, circa 280ms.

Concurrency Level:  5 
Time taken for tests: 0.306 seconds 
Complete requests:  5 
Failed requests:  0 
Write errors:   0 
Total transferred:  3495 bytes 
Total POSTed:   1065 
HTML transferred:  3135 bytes 
Requests per second: 16.34 [#/sec] (mean) 
Time per request:  306.009 [ms] (mean) 
Time per request:  61.202 [ms] (mean, across all concurrent requests) 
Transfer rate:   11.15 [Kbytes/sec] received 
         3.40 kb/s sent 
         14.55 kb/s total 

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  1 1 0.1  1  1 
Processing: 280 290 13.8 292  305 
Waiting:  278 288 13.7 291  304 
Total:  280 291 13.9 293  306 

Tuttavia, quando ho utilizzato 100 richieste simultanee, ho ottenuto risultati molto cattivi.

Concurrency Level:  100 
Time taken for tests: 4.243 seconds 
Complete requests:  100 
Failed requests:  0 
Write errors:   0 
Total transferred:  69900 bytes 
Total POSTed:   21300 
HTML transferred:  62700 bytes 
Requests per second: 23.57 [#/sec] (mean) 
Time per request:  4243.058 [ms] (mean) 
Time per request:  42.431 [ms] (mean, across all concurrent requests) 
Transfer rate:   16.09 [Kbytes/sec] received 
         4.90 kb/s sent 
         20.99 kb/s total 

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  1 62 31.5  83  89 
Processing: 996 3744 544.7 3902 4146 
Waiting:  995 3727 542.0 3894 4146 
Total:  1084 3806 542.6 3968 4204 

Macchina server: Intel i7, 8 core, 2,8 GHz, memoria da 8 GB. Ho usato le impostazioni predefinite del framework di gioco. Qualcuno sa come sintonizzare le prestazioni del gioco?

Penso che si riferisce alla dimensione del pool di thread. Il documento dice che la dimensione del pool di thread predefinita di play è # core. In questo caso, il tempo previsto per gestire tutte le 100 richieste è:

230ms * (100/8) = 2875ms 

Quindi, devo aumentare la dimensione del pool di thread di default? Ma il documento dice che dovrei ottenere le migliori prestazioni quando la dimensione del pool è uguale a # core.

Inoltre, la dimensione del pool di thread di netty (server web di riproduzione) influisce sulle prestazioni? Non ho trovato alcuna informazione sul suo valore predefinito. Qualcuno sa come è configurato?

Grazie!

+0

Sembra che la tua domanda riguardi la scalabilità anziché le prestazioni. Per quanto riguarda le prestazioni, anche IMHO 230ms/req non è così veloce, quindi controllerei anche qual è la ragione di ciò. Hai qualche indizio su cosa ti stai prendendo la maggior parte del tempo, ad es. chiamate di back-end, calcolo app specifico o rendering di template? – MartinGrotzke

+1

Assicurati di eseguire il benchmark rispetto a Play in modalità PROD eseguendo 'play start'. La modalità DEV ha un sacco di overhead per l'auto-ricarica. –

risposta

6

La configurazione dei thread predefiniti di riproduzione è progettata per le applicazioni che utilizzano API asincrone.

Se si effettuano molte chiamate di blocco (in genere chiamate di database JDBC "standard"), è necessario regolare il ThreadPool predefinito o eseguire le chiamate DB in un altro ThreadPool specificamente configurato.

Per comprendere tutti questi meccanismi, posso suggerire di leggere la sezione Thread Pools della documentazione di Play Framework. Contiene informazioni molto utili su questo argomento.

0

-Xmx32000m ad esempio esegue la JVM con 32 GB di memoria heap.

-Xmx256m è l'impostazione predefinita per la modalità di debug in modo che sia possibile modificarla in base a quanto si desidera che si espanda nello spazio di memoria RAM del server. A seconda della velocità I/O della macchina, i cicli di raccolta dei dati inutili possono sembrare pause se c'è molto da pulire, ma in genere ~ 20 ms e non sono visibili a seconda dello scopo dell'app.