Prado Vs. Pradolite

Menu del giorno: Benchmarking

Il vero tallone d’achille di prado v2.X erano le performances, che ne sconsigliavano l’uso per siti con un elevato numero di accessi conconrrenziali, soprattutto se non si possedeva un server dedicato.

Prado V3 , oltre ad essere gia di per sè estremamente più veloce, mette a dispozione delle nuove features proprio per l’ottimizzazione delle prestazioni.

Una di queste è il caching dei componenti su database Sqlite, per attivarle basta dichiarare nel config dell’applicazione il seguente frammento di codice:

<module id="cache" class="System.Caching.TSqliteCache" />


Un’atra feature consiste in pradolite, è uno shell script in php (in /buildscripts/phpbuilder/) che legge i file che vengono utilizzati nell’applicazione e genera un unico file con tutte le classi utilizzate, rimuove i commenti e i vari debug e log.

Una volta richiamato (con php build.php) genererà un file pradolite.php nella dir del framework.Basta includerlo al posto di prado.php.

Qui di seguito trovate 2 benchamrk che ho effetuato su una pagina di prado che effettua alcune operazioni base, come accesso/query a database, localizzazione di componenti etc.

Con prado.php (1000 richieste simultanee)
Connection Times (ms)

              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   156  163  25.1    159     428
Waiting:      139  145  23.4    142     397
Total:        156  163  25.1    159     428

Percentage of the requests served within a certain time (ms)
50% 159
66% 160
75% 160
80% 161
90% 162
95% 167
98% 223
99% 256
100% 428 (longest request)

Con pradolite.php(1000 richieste simultanee)
Connection Times (ms)

              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   143  149  14.3    146     311
Waiting:      128  132  11.0    130     229
Total:        143  149  14.3    146     311

Percentage of the requests served within a certain time (ms)
50% 146
66% 147
75% 147
80% 148
90% 152
95% 175
98% 202
99% 225
100% 311 (longest request)

Sinceramente mi sarei aspettato qualcosina di più =). Tuttavia un incremento evidente lo si puo notare con l’aumentare del numero di richieste.
Rimane comunque un ampio margine di miglioramento, come il caching dell’output (che puo essere implementato facilmente estendendo TSqliteCache), l’inclusione in pradolite delle classi custom e se si dispone un server dedicato acceleratori come APC o Zend Optimizer, che hanno dimostrato di diminuire il tempo di esecuzione degli script di 10 volte.