Treballar en el núvol

És possible treballar completament en el núvol? Hi anem o ja hi som? M'he proposat intentar-ho i compartir l'experiència. Demà començo!

Nginx: una alternativa real?

Nginx va guanyant posicions en la quota de mercat, i ha fet la crescuda més gran fins ara vista. Ara nginx controla el 7,50% dels hostnames de l'enquesta feta pels nois de Netcraft. Algunes companyies estan migrant d'Apache cap a nginx -nginx és molt més ràpid servint arxius estàtics i consumeix menys memòria en quant a peticions concurrents-.

Lighttpd és l'únic servidor web que també ha fet una crescuda en hostnames. De totes maneres Apache continua al capdavant de la llista de servidors webs més utilitzats amb un 59,13%, on la seva crescuda ha estat notable a Estats Units i Alemanya -dedueixo que a Alemanya ha crescut pel datacenter de 1and1...-.

Serà possible que nginx acabi destronant al rei?

Quota de mercat dels principals servidors de tots els dominis

Octubre 1995 - Gener 2011

	Desembre 2010	Percentatge	Gener 2011	Percentatge	Canvi
Apache	151,516,152	59.35%	161,591,445	59.13%	-0.23
Microsoft	56,723,544	22.22%	57,392,351	21.00%	-1.22
nginx	16,910,205	6.62%	20,504,634	7.50%	0.88
Google	14,933,865	5.85%	15,112,532	5.53%	-0.32
lighttpd	1,308,935	0.51%	1,866,872	0.68%	0.17

Referències

http://news.netcraft.com/archives/category/web-server-survey/

HTC Desire HD vs iPhone 4

Ja el tinc aquí!! Bé, això m'han dit, que ja ha arribat a casa. Estic impacient per veure'l i comparar-lo amb l'iPhone 4. Encara que estic en trànsit cap a la poma, si les prestacions són millors que les de l'iPhone... per què no escollir l'altre? Així que per ara em quedo amb l'HTC Desire HD!

Cercant i revisant les comparatives a internet així quedarien els guanyadors:

Pantalla: HTC Desire HD
OS: HTC Desire HD
Aplicacions: iPhone4
Processador: HTC Desire HD
So i visió: HTC Desire HD
Serveis web: HTC Desire HD
Càmara: HTC Desire HD
Preu: HTC Desire HD


Serà veritat el que diuen les comparatives? En breu t'ho comento!!

Apache : El rei dels servidors web

No ho dic jo, ho constaten les enquestes fetes per l'equip de netcraft a més de 255.287.546 llocs web. L'última enquesta, del mes de Desembre, ens deixa veure com nginx ha guanyat un 0,59 per cent més de punts i serveix un 6,62 per cent més de hostnames, alguns d'ells provinents de lighttpd.

Apache, el qual tot i haver perdut un 0,01 per cent de punts, es manté líder amb 151.516.152 dominis ocupant un 59,35 per cent de quota de mercat. Uau!!

Qui ha perdut més quota de mercat ha estat Microsoft -més val que us poseu les piles nois de Redmond-, el qual perd un 0,48 per cent de punts tot i haver guanyat 85.564 hostnames. El segon en perdre quota de mercat en un 0,32 per cent ha estat lighttpd, degut a que Savvis ha traspassat servidors a nginx.

Es remarca la crescuda de hostnames que utilitzen l'accelerador HTTP de codi obert Varnish en 545.000, entre ells Facebook, Twitter i eBay.

Aquí us deixo les gràfiques i números perquè extrapoleu les vostres pròpies conclusions:

Quota de mercat dels principals servidors de tots els dominis

Agost 1995 - Desembre 2010

	Novembre 2010	Percentatge	Desembre 2010	Percentatge	Canvi
Apache	148,085,963	59.36%	151,516,152	59.35%	-0.01
Microsoft	56,637,980	22.70%	56,723,544	22.22%	-0.48
nginx	15,058,114	6.04%	16,910,205	6.62%	0.59
Google	14,827,157	5.94%	14,933,865	5.85%	-0.09
lighttpd	2,070,300	0.83%	1,308,935	0.51%	-0.32

Referències

http://news.netcraft.com/

curl-benchmark : Eina de testeig de rendiment web

No he pogut resistir la temptació i m'hi he embarcat... Degut a que al meu lloc de treball es fa servir Windows (que consti que jo sóc del pingüí), ja fa dies que busco una eina que em permeti tenir un punt de referència respecte el rendiment del servidor web. Estem en un punt que tenim els servidors sobresaturats i s'ha de fer alguna cosa per a reduir la càrrega dels mateixos.

Per Linux he trobat les mil i una eines que fan mil i una meravelles tal i com les imagino i necessito, però per Windows tot el que més o menys he trobat que sigui acceptable funciona sota Java. No és que detesti Java del tot, però per exemple els resultats d'utilitzar JMeter no em són massa convincents i sobrecarrega encara més tot el sistema. És una llàstima perquè és una gran eina, però necessita de molts recursos i precisament és l'última cosa esperada d'aquest tipus d'eines.

Amb tot això, on vull anar a parar, és que he desenvolupat una petita eina que s'executa via línia de comandes i que permet obtenir un punt de referència temporal. Li he posat el nom curl-benchmark perquè el cor de la mateixa es basa en la llibreria cURL, la qual permet moltes possibilitats que ni jo encara he descobert, i benchmark perquè permet obtenir un valor de referència a tenir en compte a l'hora de millorar el rendiment d'un servidor, d'un web...

curl-benchmark permet simular tantes peticions HTTP com es vulgui i obtenir una sèrie d'estadístiques per anàlisi de rendiment. Evidentment és open-source i la teniu disponible aquí:

http://curl-benchmark.sourceforge.net/
Intended Audience: Developers, Quality Engineers, Engineering, Information Technology, Telecommunications Industry
License: MIT License
Operating System: Cygwin (MS Windows)
Programming Language: C
Topic: WWW/HTTP, Test and Measurement, Benchmark
Translations: Catalan, English
User Interface: Command-line



Referències

http://www.cygwin.com/
http://curl.haxx.se/
https://computing.llnl.gov/tutorials/pthreads/

Apache 2.2: Optimitzar el rendiment sota Windows

És molt probable que al teu lloc de treball s'hi utilitzi el servidor web Apache per a fer funcionar l'entorn web (intern o extern), el servidor físic on hi està instal·lat tingui com a sistema operatiu una versió del Windows, i que tot vagi força lent degut a la gran quantitat de peticions que rep el servidor. Si és així espero poder-te ajudar en aquesta entrada.

Primer de tot dir-te que el servidor Apache pot funcionar millor en un entorn Linux, degut a que les directives de configuració són majors i permeten acotar més les opcions de rendiment. Si tens la oportunitat de canviar a Linux t'ho recomano, d'altra banda no desesperis, es pot aconseguir una configuració òptima pel servidor web i obtenir un alt rendiment (és clar no com es podria aconseguir amb un Linux ;) ). Tingues en compte que la proposta de configuració que veuràs a continuació no deixa de ser una proposta, és a dir, funciona molt bé en el meu entorn de treball però és possible que hagis d'acabar afinant alguns aspectes per aconseguir un rendiment òptim en el teu.

Banc de proves

És aconsellable que tinguis uns valors de referència quan treballis en tasques d'optimització, per a veure si realment els canvis efectuats tenen un efecte positiu vers al rendiment. Com a banc de proves aconsello utilitzar una aplicació que permeti realitzar una càrrega de peticions considerable al servidor i que retorni uns resultats intel·ligibles, de manera que es puguin comparar amb els resultats de fer la mateixa càrrega de peticions un cop efectuats els canvis que possiblement millorin el rendiment. Ara no entraré en profunditat en descriure com preparar un banc de proves, espero generar una entrada al respecte en breu, però si que t'aconsello un parell d'aplicacions: Curl-Loader i JMeter. La meva preferida, la primera.

Optimització




1. Mòduls innecessaris
Desactiva tots els mòduls que no facis servir, això farà que els processos ocupin menys memòria. Els següents dos mòduls els hauries de tenir desactivats i només activar-los quan necessitis recuperar informació del servidor: mod_info i mod_status. Dins l'arxiu de configuració de l'Apache httpd.conf hi trobaràs la secció Dynamic Shared Object (DSO) Support. Cada mòdul es carrega mitjançant la directiva LoadModule. Per desactivar un mòdul només cal que lo posis els símbol # davant la línia.

2. Cache

Activar algun tipus de cache és imprescindible si es volen aconseguir rendiments òptims. Un sistema col·lapsat pot veure la seva càrrega disminuïda dràsticament activant un proxy-cache, la pròpia cache de l'Apache o un accelerador PHP. Personalment he escollit instal·lar un accelerador PHP, doncs en el meu cas la càrrega de CPU esdevenia al executar-se el procés PHP. De totes les opcions disponibles jo he instal·lat l'eAccelerator i la càrrega ha disminuït notablement.


3. Comprimir contingut retornat

Apache té un mòdul que permet comprimir la informació retornada al navegador, sempre i quant aquest ho permeti. Això permet executar la petició més ràpidament, deixar un procés Apache lliure per una altra petició abans de temps i reduir considerablement l'ampli de banda. Per contra, és possible que augmenti la CPU ja que ha de comprimir cada petició i, potser, la RAM. Activant la següent línia a l'arxiu httpd.conf si el navegador li demana a l'Apache el contingut comprimit se li retornarà comprimit:

LoadModule deflate_module modules/mod_deflate.so

A més aquest mòdul s'ha d'activar i ho pots fer mitjançant la següent directiva:

<Directory "...">
   # Activa el mòdul
   SetOutputFilter DEFLATE
   # Indica quin tipus de contingut s'ha de comprimir
   AddOutputFilterByType DEFLATE text/plain
   AddOutputFilterByType DEFLATE text/xml
   AddOutputFilterByType DEFLATE application/xhtml+xml
   AddOutputFilterByType DEFLATE text/css
   AddOutputFilterByType DEFLATE application/css
   AddOutputFilterByType DEFLATE application/xml
   AddOutputFilterByType DEFLATE image/svg+xml
   AddOutputFilterByType DEFLATE application/rss+xml
   AddOutputFilterByType DEFLATE application/atom_xml
   AddOutputFilterByType DEFLATE application/x-javascript
   AddOutputFilterByType DEFLATE application/javascript
   AddOutputFilterByType DEFLATE text/x-javascript
   AddOutputFilterByType DEFLATE text/javascript
   AddOutputFilterByType DEFLATE application/x-httpd-php
   AddOutputFilterByType DEFLATE application/x-httpd-fastphp
   AddOutputFilterByType DEFLATE application/x-httpd-eruby
   AddOutputFilterByType DEFLATE text/html
   AddOutputFilterByType DEFLATE text/htm
   # S'evita retornar contingut comprimit com imatges o vídeos
   SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
   SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
   SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
   SetEnvIfNoCase Request_URI \.avi$ no-gzip dont-vary
   SetEnvIfNoCase Request_URI \.mov$ no-gzip dont-vary
   SetEnvIfNoCase Request_URI \.mp3$ no-gzip dont-vary
   SetEnvIfNoCase Request_URI \.mp4$ no-gzip dont-vary
   SetEnvIfNoCase Request_URI \.rm$ no-gzip dont-vary
   SetEnvIfNoCase Request_URI \.flv$ no-gzip dont-vary
</Directory>

5. httpd-mpm.conf: ThreadsPerChild, MaxRequestsPerChild, SendBufferSize

El mòdul MPM (Mòdul de Multi Processament) és el que funciona per defecte en sistemes Windows NT. El funcionament és el següent: s'executa permanentment un procés Apache que controla que s'estigui executant un altre procés Apache el qual crea fils per gestionar les peticions. Així és com funciona l'Apache als Windows NT i pocs valors de configuració hi ha per millorar el rendiment en aquest sistema operatiu (als Linux les directrius de configuració són més extenses i específiques per a millorar el rendiment dels processos Apache i els seus fils). Jo proposo les següents modificacions, que faran que el teu servidor processi més volum de peticions. Has de vigilar que el hardware pugui processar les peticions, jugar amb els valors fins a trobar un rendiment estable:

• ThreadsPerChild: Indica el número de fils que es crearan al iniciar el servidor. Personalment utilitzo un valor de 1900, força alt ja que tenim moltes peticions i el hardware aguanta. Aquest valor també està limitat pel sistema operatiu, depenent del valor que necessitis podria ser que hagis de tocar la configuració del sistema operatiu per a poder indicar un valor realment alt.
• MaxRequestsPerChild: 0. Aquest valor indica cada quantes peticions processades el servidor web s'ha de tancar i tornar a obrir per alliberar recursos. Tinc posat que no acabi mai però en realitat hauria de ser un valor molt aproximat al número de peticions diàries entre el número de processos Apache (1 en el cas de Windows NT), de manera que només es torna a iniciar una sola vegada al dia evitant talls de connexions innecessaris. En el meu cas el servidor Apache no consumeix massa memòria i per això està el valor 0.
• SendBufferSize: Aquest valor augmenta la velocitat de transmissió. Un valor correcte és el suficientment alt com per a que hi càpiga el contingut de resposta d'una pàgina web, així s'evita bloquejar i retornar la informació en diferents vegades. Estranyament per un valor de 1460 a mi em funciona molt bé. Aquest buffer també pot venir limitat pel sistema operatiu.

Espero que aquestes línies t'ajudin a millorar el rendiment del teu entorn de treball web!

Referències

http://httpd.apache.org/docs/2.2/
http://en.wikipedia.org/wiki/List_of_PHP_accelerators
http://sourceforge.net/projects/curl-loader/
http://www.softwareqatest.com/qatweb1.html

Android : Modificar arxiu hosts

Molt bé, anem a veure com configurar un emulador Android per a navegar a la nostra intranet. Aquesta modificació, per exemple, ens serà molt útil si volem comprovar com es veu el web que estem desenvolupant en un terminal Android.

Preparació de l'entorn de treball 

1. Descarregar i instal·lar l'Android SDK: El trobaràs en el següent enllaç: http://developer.android.com/sdk/index.html. Instal·la la versió de l'API que necessitis.
2. Crear un Dispositiu Virtual Android: Un dispositiu virtual Android es pot entendre com una màquina virtual on hi ha instal·lat el sistema operatiu Android. Obre un terminal i accedeix al directori tools dins del directori d'instal·lació de l'SDK. Amb la següent comanda podràs crear el dispositiu: android create avd -f -n android1.5 -t android-3 -p c:\. El paràmetre -t indica la versió del sistema operatiu a instal·lar (segons la versió de l'API que hagis instal·lat). Per veure el número o identificador que has d'utilitzar executa la següent comanda i veuràs la llista de targets disponibles: android list targets.
3. Obrir el dispositiu amb l'emulador Android: Al mateix directori trobaràs l'eina emulator que et permetrà obrir el dispositiu creat al pas anterior. Executa la següent comanda per fer córrer un Android al teu ordinador: emulator -avd android1.5 -partition-size 128. Molt important el paràmetre -partition-size per evitar problemes de falta de memòria.

Modificar arxiu hosts al dispositiu

Un cop l'emulador està executant l'Android amb la versió que necessitem ja se li pot modificar l'arxiu hosts. Ara has de sortir del directori tools i entrar al directori platform-tools. Hi trobaràs l'eina adb (Android Debug Bridge) que et permetrà interactuar amb el dispositiu.

Executar les següents comandes:

1. adb devices: Llista els dispositius virtuals o reals accessibles. Necessites executar la comanda per saber l'identificador del dispositiu.
2. adb remount: Permet escriure al dispositiu, d'altra forma apareixerà un error de lectura/escriptura.
3. adb -s emulator-5554 push C:\hosts /etc/hosts: Sobreescriu l'arxiu /etc/hosts del dispositiu virtual emulator-5554 per l'arxiu hosts situat a C:\ de l'ordinador. Pots utilitzar en comptes de push el paràmetre pull amb els directoris intercanviats per obtenir l'arxiu hosts del dispositiu: adb -s emulator-5554 pull /etc/hosts C:\hosts.

Ja ho tens! Amb aquests passos pots modificar l'arxiu hosts per fer comprovacions en plataformes mòbils. També pots utilitzar les comandes anteriors per a modificar altres arxius del dispositiu.

Referències

http://developer.android.com/sdk/index.html
http://developer.android.com/guide/developing/tools/adb.html
http://developer.android.com/guide/developing/tools/avd.html