Llegint llegint he anat a parar a una plana que compara els principals bastiments (frameworks) PHP entre sí per demostrar com n'és de ràpid el KumbiaPHP comparat amb els altres.

Com que el codi utilitzat per les proves està disponible, doncs he vist que era un simple hello world, així que he creat un projecte hello_world a appfusedjango per poder comparar amb Django.

Disclaimer: La velocitat d'execució no ho és tot. Segur segur, que fet en x ben optimitzat l'aplicació y és més ràpida per aquesta prova. Això no és per veure qui la té més llarga, sols intent comparar coses més o manco semblants per saber on estam. Disclaimer 2: Qui en sap d'aquest tipus de proves és la gent que es dedica més a sistemes, en Bernat o en Guillem, per exemple :)

Amb què he fet les proves?

• La màquina es un PPC 64 de 2 MHz amb 1 Gb de RAM utilitzat Ubuntu 9.1 i Gnome com a Desktop. És a dir, no he fet servir un servidor i hi ha moltes coses executant-se.
• Python 2.5.2 (r252:60911, Jul 31 2008, 17:33:15) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
• Com que em feia peresa muntar i configurar l'Apache he fet servir un servidor fet amb Django, el CherryPy, concretament el mòdul WSGI que podeu trobar al Django-Cerise sense executar-ho amb mode daemon per tenir major facilitat de modificar la quantitat de threads.
• La versió de Django és la trunk
• Per a les proves finals he optimitzat l'aplicació llevant tot el codi de depuració i middlewares que no es feien servir com el del la compressió gzip.

L'aplicació

L'aplicació no té cachés (tot a dummy i sense per-site-cache) i he fet que la plana en generar-se passi per la vista per a que es faci tot el recorregut MVT.

Els resultats:

executam ab -c 10 -t 60 http://localhost:8088/ cada vegada:

1. Aplicació amb codi extra, servidor amb 10 threads 277 req/s
2. Aplicació amb codi extra, servidor amb 3 threads 285 req/s
3. Aplicació amb codi extra, servidor amb 5 threads 285 req/s
4. Aplicació optimitzada, servidor amb 5 threads 334 req/s
5. Aplicació optimitzada, servidor amb 3 threads 331 req/s

KumbiaPHP, el més ràpid de la comparativa PHP treu 34 req/s, casualitat? He fet alguna cosa malament? Potser, però no sóc el primer, hi ha gent que també ha notat un fort augment del rendiment en passar de PHP a Django.

I una de les proves:

ab -c 10 -t 60 http://localhost:8088/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Finished 20009 requests

Server Software:        CherryPy/3.0.3
Server Hostname:        localhost
Server Port:            8088

Document Path:          /
Document Length:        266 bytes

Concurrency Level:      10
Time taken for tests:   60.003 seconds
Complete requests:      20009
Failed requests:        0
Write errors:           0
Total transferred:      7723474 bytes
HTML transferred:       5322394 bytes
Requests per second:    333.47 [#/sec] (mean)
Time per request:       29.988 [ms] (mean)
Time per request:       2.999 [ms] (mean, across all concurrent requests)
Transfer rate:          125.70 [Kbytes/sec] received

Connection Times (ms)
          min  mean[+/-sd] median   max
Connect:        0    2  82.1      0    3001
Processing:     4   27  41.7     24    2295
Waiting:        0   25  41.5     21    2291
Total:          5   30  92.1     24    3038

Percentage of the requests served within a certain time (ms)
  50%     24
  66%     28
  75%     30
  80%     32
  90%     37
  95%     43
  98%     50
  99%     59
 100%   3038 (longest request)
(development)aaloy@G5:/tmp/djangocerise-master/src$ ab -c 10 -t 60 http://localhost:8088/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Finished 19863 requests

Server Software:        CherryPy/3.0.3
Server Hostname:        localhost
Server Port:            8088

Document Path:          /
Document Length:        266 bytes

Concurrency Level:      10
Time taken for tests:   60.006 seconds
Complete requests:      19863
Failed requests:        0
Write errors:           0
Total transferred:      7667358 bytes
HTML transferred:       5283558 bytes
Requests per second:    331.02 [#/sec] (mean)
Time per request:       30.210 [ms] (mean)
Time per request:       3.021 [ms] (mean, across all concurrent requests)
Transfer rate:          124.78 [Kbytes/sec] received

Connection Times (ms)
          min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       3
Processing:    12   30   9.0     29     361
Waiting:       10   28   8.7     27     361
Total:         12   30   9.1     29     362

Percentage of the requests served within a certain time (ms)
  50%     29
  66%     31
  75%     33
  80%     34
  90%     37
  95%     40
  98%     44
  99%     47
 100%    362 (longest request)

Supòs que ja ningú dubta de la importància dels test unitaris a l'hora de programar. Els tests ens permeten provar que el que feim és correcte i repetir-ho tantes vegades com volguem i de manera controlada.

Els tests són una part important dels mecanismes de refactorització d'aplicacions, ja que ens asseguren que l'aplicació funciona de la mateixa manera abans i després de refactoritzar.

Els test, però, tenen un problema, fins ara els test unitaris s'han d'escriure d'una determinada manera, recordar les llibreries que has d'importar, com fer un testsuite. Per mi això significa anar a la documentació del pyUnit cada vegada o copiar un test anterior. És el que té dedicar-se a gestionar projectes, que no pots tenir al cap coses que sols fas servir de tant en tant, ja que sols dediques una quantitat mínima d'hores a programar.

Davant aquesta necessitat de fer tests sense tenir que preocupar-nos de la fontaneria intrínseca del pyUnit una de les millors opcions que hi ha és la llibreria nose. Vull dir, si sé que nose és perfecte per la feina (acudit fàcil).

Per fer un test típic basta recordar el següent:

• la sintaxis dels assert de Python: assert condicio, missatge.
• que gairebé qualsevol funció o classes que contengui test o Test separat amb quió baix és una funció testejable.
• Que un test falla quan l'assert falla
• Que fent un nosetest -v nom executarem els tests en mode verbose del paquet o funció que li indiquem

La documentació és molt més àmplia, indica quan capturar la sortida, com fer l'equivalent al setup i al teardown dels pyUnit, capturar excepcions, etc. Però el 80% de vegades aquestes quatre coses que indic seran més que suficients.

La llibreria nose ens permet escriure els tests de la manera que estam tots acostumats quan escrivim codi per provar una funció, en nivell de formalització i cerimònia comparat amb els unittests clàssics és mínima, i per tant afavoreix que poguem convertir el codi de proves informal a codi per a la realització de test unitaris amb tant sols reanomenar la classe o funció que hem escrit, i moltes vegades ni tan sols això, ja que, no sé vosaltres, però jo ja tenia la mania de anomenar test a les funcions de prova :)