Rest vs Soap (II)

Us deixo un enllaç molt interessant sobre l'estat de les API de serveis d'Internet al 2009 i 2010:

http://www.readwriteweb.com/cloud/2010/05/pen-api-madness-the-party-has.php

Fixeu-vos en la gràfica que mostra el número de crides REST vs SOAP.

La màquina virtual de java (I)

Aquests últims dies he estat intentant informar-me de quines són les millor tècniques per optimitzar processos Java. Hi ha molta informació a la web, la majoria està a la pàgina oficial de Sun Oracle.

He intentat fer un petit resum per si a algú li interessa. Lògicament és una petita introducció amb molts de links a les pàgines amb la documentació oficial.

Primer, unes consideracions sobre optimitzacions i "benchmarks" que crec que són importants:

Java SE 6 no va introduïr moltes novetats pel que fa a la API. Bàsicament és una actualització que atacava la performance de Java. Podem veure algunes gràfiques comparant els diferents rendiments a [7]. Per tant, és important que ens assegurem que sempre tinguem la última versió de Java instal·lada al sistema. Un altre tema és que la informació que trobareu aquí parla exclusivament de la VM Hotspot (de Sun). Hi ha altres VM, amb altres rendiments, com podeu veure a [8].

En quant a les monitoritzacions, sempre que provem alguna cosa cal que les dades i l'estat de la màquina sigui el mateix. Tot i això en java cal tenir en compte:

• Warmup: La JVM funciona interpretant codi compil·lat. Segons la modalitat en que s'estigui executant (client o server) detectarà mètodes hot (que s'usen molt sovint) i els compilarà a codi natiu de la màquina per millorar-ne el temps d'execució. Això fa que el rendiment millori a mesura que s'executa el programa.
• Garbage collection (GC): He pogut comprovar que la majoria de tècniques d'optimització en Java tenen a veure amb la gestió del GC i de la memòria. Malauradament el tema és molt complexe i es mereix un post ( o un llibre ) per si sól.
• Mesurament de temps: En cas de que volguem pendre mesures de temps del programa i que no tinguem un profiler a mà Java ofereix dues crides que retornen temps. Es veu però que la System.currentTimeMillis() no és del tot fiable (sobretot en sistemes operatius Windows) i es recomana utilitzar la System.nanoTime().

Finalment tenim la interpretació de resultats. No hi ha prou en executar-lo una vegada. Si es pot s'hauria de fer un anàlisi estadístic (més sobre tot això en un pròxim post).

Un cop feta la introducció al tema, comentaré alguns dels links més interessants que he trobat:

Java Tuning Whitepaper [1], tot i que sigui del 2005, és un molt bon recurs introductori. Molt genèric i fàcil d'entendre. Com ja he dit abans, bàsicament es parla de memòria i de GC.

La màquina virtual de Java té les opcions que formen part dels Ergonomics, que són les opcions que permeten modificar el comportament a l'hora d'executar els divesos programes, les opcions més conegudes són:

• Xms: La quantitat de memòria inicial del programa. Si no donem una mida inicial aquesta serà de 2 Mb.
• Xmx: La quantitat màxima de memòria que la màquina virtual estarà permesa a utilitzar.

Lògicament, hem de vigilar a l'hora d'asignar aquests valors, ja que influiran molt en el rendiment del programa, com més memòria millor, ara bé, com més memòria més haurà de treballar el GC i menys quedarà pel sistema operatiu, cosa que pot ocasionar que el rendiment general del sistema es vegi perjudicat.

Algunes opcions relacionades amb el GC [2]:

• The -XX:+UseParallelGC parallel (throughput) garbage collector.
• The -XX:+UseConcMarkSweepGC concurrent (low pause time) garbage collector (also known as CMS)
• The -XX:+UseSerialGC serial garbage collector (for smaller applications and systems)

Una de les opcions que no coneixia d'abans és la de canviar la mida de les pàgines de memòria, bàsicament modificarem la mida de la TLB (Translation-Lookaside Buffer) que és la part de memòria que manté les traduccions de memòria virtual a memòria física. Ampliant la mida de les pàgines també ampliarem la mida de la TLB, i per tant seran menys fallades a l'hora de buscar adreces de memòria. Pot millorar l'eficiència d'aplicacions que utilitzin molta memòria. Cal tenir en compte que es pot afectar negativament l'eficiència del sistema, ja que l'aplicació pot fer un us execessiu de memòria fent que la resta del sistema es quedi curt, a més no és fàcil de configurar (s'ha de fer canvis a nivell del SO) podeu trobar instruccions aquí [3].

I més opcions llistades a [4], de les quals destacaria:

• XX:+UseFastAccessorMethods: Use optimized versions of GetField.
• XX:+StringCache: Enables caching of commonly allocated strings.

El document també té una secció molt interessant amb exemples explicats [5].

Finalment us deixo una llista de links bastant interessants sobre la JVM:

Referències.

[1] http://java.sun.com/performance/reference/whitepapers/tuning.html

[2] http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

[3] http://java.sun.com/javase/technologies/hotspot/largememory.jsp

[4] http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp#PerformanceTuning

[5] http://java.sun.com/performance/reference/whitepapers/tuning.html#section4.2

[6] http://java.sun.com/performance/reference/whitepapers/6_performance.html

[7] http://java.sun.com/performance/reference/whitepapers/6_performance.html#2.3

[8] http://www.usenix.org/event/jvm02/full_papers/jacob/jacob_html/node12.html

Nou disseny!

Bé, com que n'estava bastant fins als nassos del disseny vell, i sobretot dels problemes que tenia amb les fonts, els paràgrafs i els espais he decidit canviar de plantilla. Espero que aquesta sigui més agradable.

M'ha anat d'un pèl a no muntar el blog a un altre sistema com wordpress o postero.us.

Resum de la NoSQL EU 2010

Fa temps que tenia pendent un post sobre les bases de dades "nosql". Les he tractat una mica per sobre en anteriors posts, i aprofitant que el mes passat vaig poder anar a la NoSQL EU 2010 crec que és un bon moment per reprendre el tema.

Primer de tot, posem-nos en contexte i comencem pel principi.

Què són les bases de dades #Nosql?

Ja n'he parlat en posts anteriors, però podem dir de forma resumida que són unes bases de dades que no segueixen el model relacional, i que per tant, no intenten seguir les normes ACID.

Aquestes bases de dades han sorgit d'un seguit de necessitats molt lligades a uns grans volums d'informació, i per tant, a la distribució i escalabilitat dels sistemes. És per això que molt sovint estan relacionades a frameworks com Hadoop, del qual també n'he parlat en aquest blog.

Hi ha diverses categories de Nosql, ràpidament:

• Key-Value stores: Són taules de hash gegants. Volen ser molt ràpides.
• Document stores: Contenen informació sense esquema, normalment representada en json i indexada per qualsevol tipus dels seus valors.
• Column stores: Model Bigtable.
• Graph databases: Representen un graf amb els seus nodes i connexions.

De què es va parlar a la NoSQL EU 2010.

La conferència va ser organitzada de tal manera que fos més un punt de trobada de programadors interessats en aquesta tecnologia que una conferència de classes magistrals.

Van haver-hi una sèrie de discussions sobre què és aquesta tecnologia i sobretot, què no és, ja que no ha sigut gaire ben rebuda per alguns sectors del món informàtic. S'ha d'admetre que el nom de NOSQL no és que estigui molt ben triat, certament dona una impressió potser una mica massa agresiva, però sembla que s'hagi muntat una espècie de guerra religiosa, en la qual, lògicament no penso entrar. [1] [2] [3]

Dins d'aquest "bloc" més general de la conferència hi va haver una explicació sobre les diferents categories i models de dades i una xerrada molt interessant a càrrec de Werner Vogels (@Werner), CTO d'Amazon, un dels creadors de Dynamo, i probablement una de les persones més importants dins del món dels sistemes distribuïts (opinió personal, feel free a opinar :) .

El tema més tractat i el que va ser més interessant per tothom va ser sens subte els casos d'ús d'aquesta tecnologia i experiències reals, on es va explicar com funcionen aquests sistemes en producció a la BBC, The Guardian i Twitter entre d'altres, com s'han fer per escalar, sobre quins tipus de màquines corren, la càrrega i els problemes que havien tingut els equips que les havien desplegat.

Sensacions de les sessions i idees a destacar.

Bé, sens cap mena de dubte el plat fort va ser la xerrada de Werner Vogels. Molt genèrica sobre sistemes distribuïts, la seva dificultat d'implementació i la seva història, però així mateix molt interessant. Els punts que em van agradar més:

• Va destacar la importància de la col·laboració entre l'academia i la industria, per aconseguir tenir els punt de vista teòric i pràctic per finalment poder arribar a un sistema real i utilitzable.
• La dificultat dels sistemes, i que no hi ha un sistema perfecte, ni hi serà.

I guardo pel final el que em va agradar més i el que em va fer pensar més també:

• Un sistema (distribuït, en producció i crític) ha de ser anti tot. Volent dir que s'ha de fer de tal manera que el sistema aguanti TOT el que li caigui. En uns límits lògicament. Ha d'aguantar caigudes de xarxa, net splits, data centers que es queden sense conexió (això pasa, no m'ho creia, però us puc assegurar que pasa), sistemes de fitxers que es corrompen i bases de dades (relacionals o no) que es queden penjades. Va utilitzar la següent frase per resumir-ho:

  "Si hi ha un problema el dissabte a la nit, el sistema hauria de ser capaç a mantenir-se funcionant fins que l'encarregat del sistema vagi a treballar el dilluns a les 9 del matí".

  Vaig tornar a pensar amb aquesta frase quan el fa dos dissabtes em va sonar el mòbil a les 4 de la matinada (fet verídic).

Si algú vol més informació sobre el tema pot obtenir més informació en els següents links:

• Presentacions de la conferència a slideshare. (la més introductòria)
• My Popescu. Un blog amb noticies sobre el moviment #nosql
• El grup de discussió a google groups.

I lògicament, qualsevol dubte, ja sabeu a on em podeu trobar!