Millorar l’ample de banda i els accessos al WordPress

Una de les feines de tenir el blog en un hosting propi és que, de tant en tant, cal fer de sysadmin per tenir-ho tot al dia i que els consums de xarxa no es disparin.

Fa tres mesos va ser això el que em va passar: va començar a augmentar el consum d’ample de banda, arribant de vegades a la quota que tinc contractada… un desastre! Així que va tocar pujar-se de mànigues i entrar a treballar.

Per algun motiu, els consums anaven sense control, i no era pas per un augment de visites… Després de mirar i mirar, he arribat a la conclusió que tot plegat venia donat per més d’un motiu:

  1. Accés de molts robots molt continuat
  2. Intents d’accés a adreces d’administració
  3. Pes de la pagina massa gran

L’accés d’un número de crawlers gran, que fan accessos tothora, incontrolats, multiplicat pel pes excessiu de la plana va fer que el consum augmentés, sense que ho fessin les visites (les estadístiques d’accés marcaven molt tràfic no registrat -el dels robots- i tamanys de pàgina de fins a 180 KB!, i moltes vegades en hores estranyes).

Després d’aplicar un seguit de mesures, he anat vigilant el consum d’ample de banda i els accessos i han baixat espectacularment (no sé quin tant per cent pot tenir cada factor, però han baixat tant els tamanys de la pagina servida com el número d’accessos per robots i fins i tot els accessos -intents- a adreces d’administració, cgi…)

El controls que he aplicat i els llocs on he trobat informació son aquests:

1. Definir un fitxer robots.txt més refinat que el que hi ha per defecte, indicant

2. Tallar l’accés als robots (o intentar mesurar-lo) mitjançant .htaccess.

3. Reduir el tamany de la plana. En el meu cas, no cal que cada plana sigui una landing page i tingui tota la informació del blog i mil i un artefactes per navegar…

  • Escollir un tema que no sigui gràficament molt carregat (per més caches que posem, si eliminem imatges baixem pes, és així de simple)
  • A nivell de disseny, podem carregar el blog amb efectes de desplegables, carrussels, menús i moltes coses més… però cal plantejar-se si la navegació és la que volem o pot ser carregós.
  • Exemple: un canvi en el plugin d’arxiu (l’anterior –Moo Collapsing Archives– generava una llista sencera, ordenada per mesos i anys de tots els posts… no calia. L’actual –Compact Archives– genera una llista molt més compacta). Només això ha aprimat les planes 100 KB.

L’art de programar

Quan desenvolupem codi moltes vegades ens centrem en cobrir els requeriments que se’ns estan demanant, en el temps requerit. Ens basem en la potència dels ordinadors actuals, en la interconnexió pseudomàgica dels serveis o de terceres funcions que usem com caixes negres, sense saber com funcionen, apliquem patrons i fem proves, i si funciona, voilà, ja està fet i a per les següent coses.

Tenim mètriques, proves d’unitat, uat’s, diagrames i casos d’ús per preveure, veure, justificar i informar del que fem i com funciona, tenim tota una metodologia científica i tècnica al nostre abast.

Però desenvolupar codi no és només això: tots sabem reconèixer una documentació ben feta, aprenem i gaudim quan veiem un codi elegant, ben documentat, indentat i precís, i ens desesperem quan trobem instruccions incomprensibles, repetitives i sense documentació que donen voltes i més voltes, complicant innecessàriament el producte (de vegades això reflecteix un mal treball, de vegades es dissimula el no saber fer, la incomprensió d’allò que es demana o de l’eina que es fa servir amb un codi extremadament complicat, com en un mal discurs d’un polític).

Així, programar és també copsar el problema o la solució que se’ns requereix, i treballar no només per força bruta si no entenent tot l’entorn que rodejarà al nostre producte: interaccions, sessions, peticions concurrents o voluminosos treballs batch. Hi ha part d’art, d’aprenentatge en la programació, hi ha la part d’elegància que rodeja a un bon codi, la robustesa d’una api ben definida i la documentació, en línia i final, comprensible per tothom, quan s’hagi perdut l’entorn on va sorgir la necessitat d’aquell programa.

Oh, sí, és clar: al final un programa és un programa.

Però internament és una seqüència lògica d’instruccions per resoldre un problema, i aquesta solució pot ser més o menys elegant, pot no només donar solució a una finalitat, si no ensenyar en si a com fer les coses. Heus ací la diferència entre un nyap temporal que faci una funció i en la construcció d’una solució duradora i elegant: en com apliquem aquesta lògica.

Qualitat i conservació de les dades

És suficient el tractament i les tècniques de la ciència informàtica per garantir la qualitat i la perdurabilitat de les dades que emmagatzemem?

Històricament s’han desenvolupat teories i mecanismes per garantir la certesa i la exactitud de les dades recollides, la no repetició de les mateixes, s’han estudiat les estructures més òptimes d’emmagatzematge per cada cas i la millor manera de reflectir diferents tipus d’informació. Les formes normals de les bases de dades, els arbres B, les bases de dades relacionals o orientades a objectes o les més modernes distribuïdes, l’estudi de les relacions entre les dades, etc., ja fa molts anys que està inventat i aplicat, cada vegada més refinat i més optimitzat.

A mesura que els volums de dades han anat creixent, s’han anat desenvolupant paral·lelament noves tècniques i motors de cerca, nous índexs i millors automatismes per millorar els temps de resposta, s’han implementat mecanismes per garantir la no pèrdua de les dades (backups, redundàncies, sistemes distribuïts, replicacions de sistemes, miralls on-line) i el ràpid accés a les mateixes, s’ha guanyat en flexibilitat d’accés i ens hem tret de sobre (fins a cert punt) la tirania dels bits, ens permetem el luxe de poder dissenyar bases de dades sense haver-nos de preocupar (en excés) de com s’emmagatzemaran.

Es dissenyen sistemes que capten molta informació per la gestió de determinats processos i sistemes, i que automatitzen cada vegada més feines repetitives i faciliten la optimització de la resta de tasques.

Però és suficient tot això? Tot el tractament de les dades del que parlo dalt és eminentment sintàctic: les dades son correctes a nivell de format, i s’emmagatzema allò que el sistema necessita per als seus processos actuals, si… però es dissenyen encara els sistemes pensant de manera aïllada, des d’un punt de vista eminentment tècnic i utilitari de la informació, però no es pensa (més enllà d’algunes metadades de registre) en complimentar i enriquir la informació amb metadades que donin informació semàntica sobre l’entorn d’aquell conjunt, de manera que facilitin la conservació en un futur de la mateixes dades, o millor dit, no tant la conservació com la comprensió d’aquelles dades i per tant facilitin la integració amb d’altres, o la generació d’encara més informació a partir d’aquestes dades, ja siguin documents, estadístiques o resultats estadístics a partir de mineria de dades. Exemples podrien ser registres de modificacions, generacions d’històrics, signatura de la informació, no-repetició de les dades ja existents en altres llocs…

En resum, cal anar una mica més enllà de la gestió pura i dura de la informació actual: què fem quan una aplicació es migra? Què passa amb les dades velles? Tenen alguna validesa, més enllà del que es passa al següent aplicatiu o versió? Els documentalistes arxivers/gestors de documents ja fa temps que parlen d’aquestes qüestions i que les apliquen a la qualitat de les dades com a documents, i de la preservació i la meta-informació que els mateixos ens poden donar en un futur (la preservació dels documents a llarg termini en entorns digitals és un problema complex)

Cal preguntar-se aleshores si aquests mateixos conceptes no s’haurien d’aplicar també al disseny de les bases de dades de suport a les aplicacions, pensar des d’un primer moment ja en els resultats posteriors i les explotacions que es faran (de ben segur) d’aquelles dades, i per tant no guardar només les dades estrictament necessàries per l’aplicació en aquell moment ans també metadades, informació de registres, disposar-les de manera que es faciliti el creuament posterior amb d’altres dades o es facilitin estudis històrics evolutius i que es garanteixi també la preservació de les dades a llarg termini d’una manera no estrictament tècnica, sinó també semàntica: de què ens serviria tenir tabletes en cuneïforme si no sabem desxifrar-les? de què ens serveix saber llatí si no entenem la societat on es parlava? De la mateixa manera, de què ens serviria tenir conjunts de dades dels quals no sabríem com han evolucionat perquè guarden només una instantània de la informació, no l’evolució històrica, per exemple?

Aquest, a més, és un problema diferent del fet de cercar en quantitats ingents d’informació (la tan actual big data, abans mineria de dades): cercar dades, creuar-les i extreure’n nous resultats, generar nova informació, és important, és clar. Però per tal que la informació resultant d’aquestes operacions tingui qualitat, la informació original, la que nosaltres estem deixant en aquest moment, també ha de tenir-la, el que vol dir tenir en compte alguns dels punts esmentats dalt.

Això, a més, implica un canvi en la cultura de treball de les organitzacions que treballen amb la informació com a principal actiu o eina de gestió:

  • implica crear equips multidisciplinaris en la creació inicial de les bases de dades: informàtics, documentalistes, el propi gestor tradicional de la informació
  • implica que tothom es faci seus els projectes i entengui el que es demana i el que es vol treballar
  • implica una visió no tancada en les pròpies necessitats del moment si no en pensar a llarg termini: emmagatzematge, reserva, utilitat
  • implica conèixer altres sistemes d’informació que treballin amb informació relacionada per veure si els podem enriquir o ens poden aportar quelcom

En definitiva, pensar en les dades de manera no només sintàctica sino també semàntica i de conservació és el camí per garantir una bona qualitat de les mateixes ja en origen i facilitar enormement tasques posteriors de neteja i enriquiment, conservació de documents i/o conjunts autocontinguts i robustos, i per tant en la obertura al públic de dades de més qualitat, ara que s’obre el camí de l’open data i la transparència.

Comunitat i software lliure a les AAPP

Sembla que el nou govern de la Junta de Extremadura no està per mantenir l’herència tecnològica de passades legislatures, basada en la promoció de programari de fonts obertes, si no que pensa més en centrar-se exclusivament en criteris econòmics en buscar proveïdors de programari.

És una llàstima que es perdi tot el que s’ha guanyat fins ara usant aquest model: el més evident pot ser el coneixement tecnològic, el programari, la metodologia i la documentació, els productes i la distribució en sí; però també cal valorar, i molt, el treball d’educació que s’ha fet tant en tots els àmbits de govern afectats (administració, educació, sanitat…) com en la pròpia societat del que és el software lliure.

Centrar-se única i exclusivament en criteris econòmics és una visió de curt termini, que si que podria fer estalviar inicialment despeses (els desenvolupament no son barats, tot i que a la llarga el llicenciament surt car), però que perd de vista el retorn d’aquesta inversió a la societat en coneixement i creació d’empreses, de teixit tecnològic. Això, en el cas d’un govern autonòmic, no s’ha de perdre de vista.

Extremadura és, potser, una de les més conegudes defensores d’aquest model, però hi ha hagut moltes altres que hi han apostat també, amb més o menys ganes, amb més o menys encert: la Junta d’Andalusía fa un treball molt bò, i per aquí encara ronda la Linkat, al País Valencià hi ha Lliurex i qui més qui menys va llençar projectes

A nivell estatal també es treballa amb software lliure, i molts ajuntaments també tenen projectes i aplicacions basades en codi lliure.

Però tots aquests casos, per més de codi lliure que siguin, per més que s’hi basin, l’usin, el desenvolupin i inverteixin, no tenen, moltes vegades, una de les característiques definitòries del software lliure: una comunitat darrere que li doni suport.

Una de les grans objeccions dels responsables tecnològics de les administracions de cara al software lliure és “a qui truco si s’espatlla?”. És un argument comprensible des del punt de vista de poder donar una solució ràpida a un problema important (que superi les capacitats de coneixement d’un departament de TI). Amb el pas del temps, però, aquest argument ha perdut pes perquè cada vegada hi ha més empreses que ofereixen els seus serveis i coneixements dins d’aquest camp, a mesura que l’Administració, ha obert mercat i ha començat a marcar determinada tendència.

Aquestes tendències, però, han vingut marcades per directrius polítiques que poden canviar quan hi ha un canvi de govern.

L’ús del software lliure per una Administració, però, es podria dividir en dos grans grups:

  • Programes d’ús general basats en codi lliure, que es poden emprar en aquella organització: dins d’aquesta categoria poden entrar de navegadors o processadors de text, programes d’edició d’imatges, servidors, bases de dades o entorns de programació… qualsevol eina imaginable (o gairebé) per als usos d’una organització. I sobre aquest tema se n’ha escrit a bastament, sense deixar clos el debat.
  • El programari intern creat per aquella organització per a usos propis: la programació de sistemes tributaris, webs, entorns de relació amb el ciutadà, interconnexió entre Administracions (G2G), sistemes de suport a procediments, arxius digitals… és a dir, tot allò que dóna suport a la feina, processos i informació que usa l’Administració. I aquí torno al problema que citava més amunt: la comunitat. Totes les Administracions es regeixen per similars marcs juridico-legals i totes tenen, si fa no fa, similars atribucions i per tant, similars problemes informàtics a resoldre. Aquests es poden resoldre comprant productes de mercat verticals, tancats, que es poden particularitzar, o bé desenvolupant internament eines.

Aquesta és la gran aposta que va fer el govern extremeny, i que altres AAPP també han fet, en major o menor grau.

En adoptar, però, el software lliure com a eina i filosofía de desenvolupament no s’ha acabat de fer el pas evolutiu cap a una comunitat que en doni suport: tot i comptar amb proveïdors entesos, tot i obrir el codi font i usar estàndards oberts, em demano si aquestes AAPP han estat capaces d’establir també mecanismes de col·laboració amb altres organitzacions del mateix tipus. És clar que existeix col·laboració entre els equips de TI i intercanvi de coneixements, però en general, totes aquestes organitzacions tenen ja un volum considerable de software desenvolupat, un nucli central que és molt difícil canviar, i que condiciona part de les decisions tecnològiques que es puguin prendre a posteriori, com l’adopció de nous llenguatges o eines compatibles amb el core antic.

Així, tot i fer-se l’aposta per un ús del software lliure, emprar-se eines i desenvolupar programari, crear metodologies i existir xarxes i intercanvi de coneixements, el que encara no s’ha pogut crear del tot és una comunitat que permeti interaccionar els tècnics en programes horitzontals, comuns a diferents organitzacions similars i útil per a totes elles, fer una base comuna compartida; això provoca que, tot i usar eines i metodologies i compartir problemàtiques similars, les implementacions encara s’hagin de desenvolupar unitariament, en paral·lel, desaprofitant part del potencial.

Aquest però, no és un problema exclusivament tècnic: la creació d’aquesta comunitat d’intercanvi ha de ser incorporada directament per les Administracions Públiques, i això a vegades és una idea que ni s’entén ni es sap explicar, i que amb programari privatiu no es podria fer.

I la decisió de la Junta d’Extremadura demostra que no s’entén ni en un dels seus bressols.

del.icio.us/recomanats o Shared items de Google?

Els dos últims articles (integrar goolge i del.icio.us, 1 i 2) venien donats per una conversa que vàrem tenir amb uns amics sobre la complementarietat entre els “shared items” del Google Reader i l’emmagatzematge d’adreces d’articles a del.icio.us.

Donat que els dos serveis ofereixen una rss per subscriure’s, i tots dos es poden navegar públicament, els avantatges entre un o altre es limiten, per mi, a l’entorn: si estic usant el Google Reader, m’és més fàcil marcar els articles interessants per d’altres com a shared només amb un clic de ratolí, si estic navegant per internet, es més fàcil fer-ho amb del.icio.us (a amb qualsevol altre servei web de bookmarks), dit d’una altra manera: depèn de si llegeixo fonts on estic subscrit o bé navego lliurement.

Per tant, he decidit separar les dues fonts, fer-les complementàries: d’una banda, usaré els shared items per publicitar aquells articles que trobi interessants, de l’altra seguiré usant els recomanats de del.icio.us per marcar les pàgines recomanades.

Tot és però, contingut que jo trobo interessant, i aquesta classificació que faig no hauria d’afectar que la gent pugui consultar la totalitat d’allò que recomano, per tant, també he creat una nova rss a partir de les dues anteriors (ah!, els pipes de yahoo!).

Aquesta nova distribució es reflexa a la barra de la dreta (La meva blogsfera): només es veuen els últims articles recomanats, però es pot accedir també a les diferents adreces i rss dels recomanats (shareds, pàgines recomanades i tot plegat)