Articles
Django i python: orientat a la feina
Escrit per Aaloy a 03 de June , 2009 a les 6:36 p.m.
Avui, mentre explicava a la gent de l'equip web un grapat d'optimitzacions que podem fer per fer que les nostres aplicacions siguin més ràpides i actualitzables, al mateix temps pensava que en la potència que ens està donant Python i Django gràcies a la seva orientació cap a fer les coses com s'han de fer.
La comparació amb Java, l'altre llenguatge que feim servir, no pot deixar d'estar present, i llevat d'excepcions (poques) he de dir que la combinació Python i Django en surt sempre afavorida davant de Java.
Django està molt orientat a la web, però no de qualsevol manera, està orientat a fer webs que s'han de mantenir i que han d'escalar. Per això veus que és gairebé trivial fer coses que en altres plataformes resulten força costoses: qui no recorda el que s'ha de fer per fer un redirect amb Struts, per exemple?, o la complexitat que té validar formularis tant amb Struts com amb Spring?.
Django està orientat a fer aplicacions pel món real, això vol dir: que surtin ràpides, puguin sofrir moltes modificacions al llarg del seu cicle de vida i que es pugin actualitzar també molt ràpidament.
El bastiment segueix de molt aprop la filosofia de Python, la de mantenir les coses legibles i simples. Hi ha d'haver sempre una manera obvia de fer les coses, i quan fas feina amb Django veus que els 90% dels problemes que et planteja una aplicació web tenen resposta directa. La resta poden dur un poc més de feina, que normalment vol dir fer herència d'alguna classe.
Una de les darreres aplicacions en les que he pogut comparar Java i Python ha estat una aplicació que agafa XML, el manipula i el posa dins una base de dades. L'aplicació original, feta amb Java+Spring+Hibernate, va dur setmanes de feina, mesos si contam el manteniment posterior. Fer el mateix amb Python (lxml+sqlalchemy) ha duit menys de 4 dies-home de feina.
Posar l'aplicació Java en producció també va ser un poc malson per mor de les dependències entre les llibreries. Posar-la en Python dins un virtualenv és pràcticament immediat.
Tampoc ha resistit la comparació el manteniment i la correcció d'errors. El temps que passa per localitzar l'error i fer l'actualització en Python és mínim, en Java multiplicant per 10 o per 20 aquest temps.
Ens queda un tema: el rendiment. Com moltes vegades he dit per aquí el rendiment basta que sigui "prou bo", és a dir, per l'aplicació que estam parlant partíem d'un temps de càrrega d'entre 4 hores en les primeres versions Java, a 30 minuts a les darreres versions amb multi-fil. Amb màquines amb 8 Gb de RAM i menjant-se la màquina tant amb memòria com amb processador.
La versió Python també es feta amb multi-fil, on el nombre de fils és parametritzable, amb pool de connexions i demés. Sols que escrit amb un 10% de les línies de codi. El temps? Doncs 6 minuts i mig. Consum de memòria: mínim, ús de la CPU: intensiu però sense deixar torrada la màquina.
Python està orientat a que les coses es facin i es mantenguin. Per algunes tasques concretes potser no serà la millor solució, però cada vegada estic més convençut que és el primer que s'ha de provar. Si no va prou bé, el prototip ens haurà servir per a conèixer millor l'abast del problema sense haver-hi invertit molt de temps, i sempre som a temps d'optimitzar alguna secció del codi amb C, de maneres per utilitzar codi C (o C++) o bé d'escriure codi intermig que es transformi en codi C compilable n'hi ha força. Al wiki de Cpython (una de les eines que ens permet fer això) n'hi ha un bon grapat.
Enllaços citats
Traducciones/Translations by apertium
5 comentaris, 0 trackbacks (URL) , Tags: Python Django
Comentaris
1 Comentari de paurullan a les 09:06 del Wednesday 3 Jun de 2009
El tema del rendiment es sense cap dubte important però tinc la
sensació que la gent li dóna massa pes. Quan dono classes de
programació una de les primeres coses que els dic és que l'ordre
real d'importància és:
- algorismes
- estructures
- implementacions
- xapusses
No té cap avantatge està fent hiperoptimitzacions línia a línia
si el teu algorisme és quadràtic enllog de logarítmic.
Un cas: classe de 4t, inteŀligència artificial (no faig
l'assignatura però conec les dades de primera mà). Els demanen
que implementin unes búsquedes de camins mínims. Amb la seva
implementació han de calcular el nombre màxim de nodes que poden
posar perque el resultat surti en un màxim de 30 segons. L'alumne
Pep, gestionata mig que li encanta el Java perquè és molt ràpid,
fa la seva pràctica i li surten 15 nodes pel temps màxim. Joan,
true sistemes que està enamorat de Python _i_ sap programar, li
surten 50 nodes. Perquè? Joan ha usat un heap enlloc d'una llista
per desar el graf. Res de Python contra Java: el fet de
centrar-se en el problema li ha permet maxacar al company.
La conclussió és que saber-se posar en la perspectiva correcte,
saber escollir si fixar-se amb els arbres o amb el bosc, és
moltíssim més important que l'eina que uses. El que ocorre és que
moltes eines t'obliguen a centrar-te amb cada matoll.
El fet que multipliquis vàries vegades la teva productivitat no
ve sols pel fet que siguis millor ara que fa uns anys: les eines
són importants. I el pròxim que me digui que Python és un
desastre perque és lent li mostraré aquest apunt (i si és guapa
li donaré el teu telèfon!)
2 Comentari de paurullan a les 09:06 del Wednesday 3 Jun de 2009
Que tal el tema del multifil? He estudiat les millores i els
pools del python2.6 però encara no els he usat mai en
producció.
Has aconseguit algun tipus d'ús amb multiprocés i així
aprofitar els n nuclis?
Li has pegat un cop d'ull darrerament a l'stackless?
3 Comentari de DZPM a les 10:06 del Wednesday 3 Jun de 2009
Veig que els PHP/Perl/RoR ni tan sols els tens en compte a la comparativa.
Si be el desenvolupament es més ràpid que amb Java, no tenen res a fer contra 'import antigravity' ;-)
4 Comentari de aaloy a les 11:06 del Wednesday 3 Jun de 2009
Pau, completament d'acord amb tu. A més afegiria una cosa: l'important és poder centrar-se en el problema a resoldre, que el llenguatge sigui una eina i no part del problema. Això és una de les coses que més m'agraden de Python, que permet concentrar-me en el que s'ha de fer i no pensar en les limitacions que m'imposarà com a llenguatge.
El multiprocés, GIL i demés i ha molta discussió darrerament, hi ha un fil molt interessant a la llista de Python-es http://listas.aditel.org/archivos/python-es/2009-June/024840.html que us recoman.
El multi-fil i el multi-procés no són factors limitants. El problema no està en que el llenguatge sigui millor o pitjor, sinó en la pròpia dificultat de poder paral·lelitzar l'aplicació. Si poden descompondre bé el problema, no passis pena que els nuclis s'aprofitaran d'una manera o altra. En el cas que ens ocupa, trobam que bona part del temps es dedica en obtenir l'XML i en enviar les dades a la BD. Pel parseig de l'XML que és la part de càlcul més intensiva ens n'aprofitam d'això. Així es creen els fils amb quantitat suficient per a que la CPU no estigui ociosa. El nombre va un poc per assaig i error, per aquest problema a partir de 10 ja ni hi havia millora significativa. Tenc ganes de fer que en lloc de threads es facin servir processos (hi ha un port per Python 2.5) i veure què passa. Tanmateix sols es cosa de baixar-me el codi i fer un petits canvis, per curiositat ... Però realment si m'interessessin millor temps el que faria és separar el problema en vàries màquines. El problema de les CPUs és que tanmateix s'acaben per una màquina, de màquines sempre en pots posar més. Hi ha un grup d'interés a Google també: http://groups.google.com/group/python-concurrency?hl=en
David, PHP: no és comparable, potser per fer webs sí, però no per propòsit general. I encara per les webs i fent servir un bastiment tipus Django queda força malament en claretat i fins i tot velocitat. En altres articles en vaig fer cinc cèntims.
Perl/Rails. O millor Perl/Ruby. Dir que tenc una petita mania: que el codi s'ha de poder llegir i ha de ser mantenible. La filosofia de "hi ha d'haver una manera obvia de fer les coses" junt amb la identació de Python i la claretat de la seva sintaxi fa que sigui molt més bo de fer mantenir el codi. Ja sabeu que diuen de Perl, que és un llenguatge "write only", i Ruby/Rails va un poc pel mateix camí. No dic que no se pugui fer codi mantenible tant en Perl com amb Rubi i que no es pugui fer codi mal de fer en Python, el que dic és que és molt més bo de fer fer codi inmantenible en aquets dos llenguatges que en Python.
5 Comentari de converter a les 03:06 del Thursday 4 Jun de 2009
Django is far better than java...