PlataformaMoodleenlaUPC:Estudiosobre ArquitecturayRendimiento

ProjectesTecnolgics,UPCnet.SL marcos.montero@upcnet.es

MarcosMonteroTorres

Abstract. ProyectodediseoeimplantacindeunaarquitecturaMoodlecon capacidadparadarservicioauncolectivode30.000usuariosbajocriteriosde escalabilidad,rendimiento yalta disponibilidad.Almargendel diseode la arquitectura, se definen y desarrollan unas pruebas de rendimiento que nos permitan mejorarla eficienciadel sistemaydeterminarde manerafiable la validezdelaplataformarespectoaladimensindelentornoconantelacin suficienteasupuestaenexplotacin.Asimismo,sepretendepoderrepetireste tipo de estudios de rendimiento para realizarlos de forma habitual previo a futurasmodificacionesdelaplataformaMoodle. Keywords: Moodle, rendimiento, Jmeter, Campus Digital, UPC, UPCnet, Atenea.

1Introduccin
Duranteelcurso2005/2006laUPCrealizunproyectopilotodeimplantacindeuna nuevaplataformadecampusdigitalbasadaenMoodle.Estepilototenaun mbito limitadodentrodelauniversidad,ofrecindoseunnmerolimitadodeasignaturasa un colectivo formado por 4.700 alumnos y 700 profesores. Una vez decidida su utilizacincomoherramientadeelearningparatodalauniversidad,seprocedi a disearunproyectoparaacometerlaextensindelnuevocampusdigital(conocido comoAtenea)atodalacomunidadUPC. Ensunuevafase,elcampusdigitaldeberadarservicioauncolectivode30.000 estudiantesy3.000profesores,ofreciendounnmeroaproximadode4.000cursos Moodle.Laplataformadefinitivaparaofreceresteserviciodebadecumplirunaserie derequisitosencuantoarendimiento,escalabilidadydisponibilidadquegarantizasen elcorrectofuncionamientodeMoodlebajolasnuevascondicionesypermitierandar respuestaconfacilidadafuturasampliacionesdelservicio,yafueraennmerode usuarios,asignaturasocapacidaddecarga. Laentradaenfuncionamientodelsistemadefinitivoseprodujoenseptiembrede2006 ydurantelosmesesanterioressellev elproyectodediseodelaplataformayel estudioderendimientoparagarantizarsucorrectodimensionado.

VIJornadesdeProgramariLliurehttp://www.jornadespl.org1

2ArquitecturaHardware

2.1Arquitecturaduranteelpiloto Ensuprimeraversin,laarquitecturadesoporteaMoodleestabaformadapor2 capasdiferenciadas: CapadeFrontend:formadapor3servidoresDebian+Apache.Existeun nombre DNS genrico para el campus que contiene las IPs de los 3 servidores.Elrepartodelacargaentrelosfrontendsserealizadeforma transparentea travs del RoundRobbinqueproporcionaelmecanismode resolucindelDNS. CapadeBackend:formadapor1 nicoservidordeBasesdedatosconun SGBD PostgreSQL ms un espacio de disco exportado por NFS al que accedenlos3frontends.ElservidordeBackendtienelosdatosubicadosen sendasparticioneslocalesconRAID5.

Fig.1.ArquitecturadelaplataformaMoodleUPCduranteelproyectopiloto

VIJornadesdeProgramariLliurehttp://www.jornadespl.org2

2.2Arquitecturaactual Enlanuevaarquitecturasemantienenlosconceptosbsicosdelpiloto:una nica instanciadeMoodleparadarservicioatodalacomunidadUPCyseparacinfsicade losservidoreswebyservidoresdebasesdedatos.Ahora,adems,sehaceespecial nfasisenmejorarlasposibilidadesdeescalabilidad,distribucindelacargayalta disponibilidad. Laarquitecturadefinitivaconstade4capasdiferenciadas: Balanceodecarga: Seincorporaunclusterformadopor2servidoresLinuxconLVS+HAquese encargandebalanceareltrficoentrelosdiferentesFrontendsHTTP.Permiten distribuirlacargademanerainteligente,as comomejorarladisponibilidad eliminando de forma dinmica los Frontends que no se encuentren en funcionamiento. Tambin permiten crecer o decrecer (por necesidades de mantenimiento,p.ej)alsistemadeformatransparente,consloaadiroeliminar nodosalconjuntodeFrontendsysinimpactoenelservicio. FrontendsHTTP Mantienelamismaestructurahardwarequetenaanteriormente.Est formada por3servidoresLinuxconDebian+Apache.Setratadeservidorescon2CPU Xeon 2,8Ghz y 4Gb de RAM. Se han realizado ciertas mejoras a nivel de softwarequesecomentanmsadelanteenestedocumento. Backend Formadapor2servidores,deloscualesslounoofreceservicioalcampus: 1servidor Backendprimario.6Gb de RAM y 4CPUs. Contiene el SGBDpostgreSQLv8.1yunaplacaHBAEmulexLPE9802de2Gbit parasuconexinaunaredSAN. 1 servidor Backend de backup. Se trata de una mquina de caractersticas hardware muy similares a la anterior y configuracin idntica. La eleccin de esta disposicin vino determinada por el hecho de que en el momento de la implantacin de Moodle en la UPC los nicos candidatos disponibles (debido a limitaciones impuestas por Moodle) para su utilizacin comoSGBDeranMySQLyPostgreSQL.Ningunadeestas2plataformasofrece todavaunsoporteparaclusteringsuficientementemaduro(nidecomplejidad asumible). Por este motivo se opt por la utilizacin de un sistema sin alta disponibilidadautomatizada.Unnicoservidorseencargadegestionarelacceso alosdatos,perosehadotadoalaplataformadeunnododebackupque,junto conelalmacenamientoenSAN,garanticeunarpidarecuperacindelservicioen casodeaverahardware.

VIJornadesdeProgramariLliurehttp://www.jornadespl.org3

AlmacenamientoSAN LosdatosseencuentranubicadosenvolmenesespecficosenunaSANformada porunDiskarrayFDA2400Bully2SwitchesfiberchannelBrocadeSilkworm 3850. Los volmenes de datos estn formados por particiones RAID6 (que ofrecen2discosderedundancia)conuntamao120Gbparalabasededatosy 200Gbparaelsistemadeficherosmoodledata.

Fig.2.ArquitecturaactualdelaplataformaMoodleenlaUPC.

VIJornadesdeProgramariLliurehttp://www.jornadespl.org4

3.Herramientadesimulacin

3.1Criteriosdeseleccin Laeleccindelaherramientadesimulacinvienedeterminadaporsucapacidadpara llevar a cabounas pruebas realistas que nos permitan verificar el rendimiento de MoodleparatodalaUPC.Losfactoresfundamentalesquesehantenidoencuenta paraellosonlossiguientes: Posibilidaddeestableceryverificarcriteriosdecalidaddeuso:porejemplo, la generacin de estadsticas en base al tiempo de respuesta para cada peticinHTTPoelnmero/porcentajedepeticioneserrneas. Gestin de concurrencia de usuarios: la herramienta debe ser capaz de simularaccesossimultneosalsistemaporpartedeusuariosdiferentes.Debe podergestionarsuautenticacinylascaractersticaspropiasdecadaunode ellos. Escalabilidad:Esimprescindiblequelaherramientaseacapazdegenerar simulacionesconcargasmuyelevadaspararesponderalasnecesidadescada vezmayoresdelentornodelcampusdigital. Posibilidadderealizar pruebasrealistas:nosirvecualquiersimulacin.No basta con lanzar peticiones HTTP al azar al sistema. Para garantizar la fiabilidaddeltestesnecesarioutilizarpatronesdenavegacinsemajantesa losdelosusuariosdelsistema,contemplartiemposdesesinsimilaresalos suyos e incluso intervalos entre diferentes peticiones lo ms prximos posiblesalarealidad.Endefinitiva,esimportantepoderdisearperfilesde usoadaptadosalentornodeexplotacinyquelaherramientaseacapazde reproducirlosagranescala.

3.2Jmeter LaherramientaseleccionadapararealizarlaspruebasderendimientohasidoApache Jmeter.Desarrolladaporla ApacheSoftwareFoundation,setratadeunaaplicacin 100%Javaqueseutilizahabitualmentepararealizarpruebasfuncionalesymedir rendimientos.Fueoriginalmentediseadaparatestearaplicacionesweb,perodesde entonceshaevolucionadoincrementandosufuncionalidadylostiposdepruebasalos quepuedeaplicarse.

VIJornadesdeProgramariLliurehttp://www.jornadespl.org5

Puedeutilizarseparasimularcondicionesdecargamuyelevadaenservidores,redeso aplicacionesconcretas,paracomprobarsucapacidadoanalizarelrendimientogeneral bajodiferentescondicionesdecarga. Suscaractersticasprincipalessonlassiguientes: Modelado de la carga. A partir de logs reales de Apache o generando usuariosmodeloespecficosparanuestraaplicacin. Autenticacinygestindecookiesparacadausuario. Permiteverificacindecriteriosdecalidad. Posibilidaddeinstalacinenclusterparasimulacionesquerequierancargas muyelevadas.

4.Pruebasderendimiento
La realizacin de las pruebas de rendimiento del sistema tena dos objetivos complementarios: el primero, certificar la validez de la arquitectura tecnolgica escogidaparasoportarvolmenesdecargaadecuadossegnlamagnituddelcolectivo dealumnos/profesoresdelaUPC(30.000alumnos,3.000profesores);elsegundo, detectarlosaspectosmejorablesdelaplataformaparadotarladelacapacidadde respuestasuficienteyunavezconseguidaesta,tenerunaidealomsexactaposiblede loselementossusceptiblesdemejoraenfuturasampliaciones. 4.1Preparacindelescenariodepruebas Comopasoprevioparalarealizacindelaspruebasdecarga,seelaborunperfilde usodelcampusdigitalbasadoenlosdatosrealesdeutilizacindelsistemaduranteel proyectopiloto.Laintencineraconseguirinformacinlomsfiableposiblesobreel estilodenavegacindelosusuariosenelcampus:tiemposdesesin,seccionesms accedidas,intervalosentrepeticiones,etc. Paraconseguirestosdatosfuenecesarioseleccionarlosperodosdemayoractividad duranteladuracindelproyectopiloto.Seextrajeronloslogsdelosservidoresweby seeliminaronlasentradascorrespondientesalosperodosnolectivos.Conayudade unprogramadeestadsticasweb(Awstats)seseleccionaronlosperodosconmayores niveles de concurrencia y, a partir de estos datos, se obtuvieron los siguientes parmetros: Tiempomediodesesin:7,25mins 50,26Hits/usuario 90%entradaspertenecientesaalumnos,10%aprofesores listadeURLsmsaccedidas

VIJornadesdeProgramariLliurehttp://www.jornadespl.org6

Unavezdeterminadoslosaspectosmsrelevantesquedefinenelcomportamientode los usuarios, se elaboraron 2 perfiles de navegacin diferenciados para distinguir profesoresyalumnos.ElaccesodeotrosperfilesdeusoaMoodleestanmarginal respectodeestosdosquenoseconsider necesariasuinclusinenlaspruebasde carga. Laelaboracindelosperfilessehizocombinandolosresultadosextradosdelestudio deloslogsconnavegacinespecficaaportadaporusuariosexperimentadoseneluso deMoodle.Deestaformasepretendagarantizarunnivelmnimodeaccesoalas reasmsimportantesdelcampusencadasesin. Los siguientes pasos fueron montar un entorno de pruebas reducido (formado exclusivamentepor1frontendy1backend)ytrasladaraesteunacopiadelaBasede Datosdeexplotacin.Sobreestabasededatosconsucontenidontegro,seaadieron untotalde3.000usuariosdeprueba(300profesoresyelrestoalumnos)matriculados endiversasasignaturascreadasexpresamenteparalaprueba.Elobjetivoeradisponer deunabasededatosquenotuvieratablasreciencreadasyconlosdatosmnimos, sino que tuviera el tamao y posible degradacin propia del uso habitual pero incrementadosconlosnuevosusuariosyasignaturas.

4.2 Ejecucindelaspruebas:CuellosdebotellaySolucionesimplementadas Unavezestablecidoelescenariodepruebas,comenz unplandeejecucindelas mismasdurante2meses,utilizandoprimerounentornodetestyrealizando2pruebas finalesenelentornodeexplotacinyaconsuconfiguracindefinitiva. Lacomplejidaddelaspruebasfueincrementndosedemaneragradual.Comenzando connivelesdeconcurrenciamuysencillos(1nicousuarioparacomprobarlavalidez de los perfiles, 1020 usuarios simultneos, 50100 usuarios, 200 usuarios... ) y finalizandoconlas2pruebasagranescalasobreelentornorealdeexplotacin. Estaaproximacingradualseescogi porquenospermitairdescubriendopasoa paso los distintos cuellos de botella del sistema y proponer las soluciones ms adecuadasparasolventarlosantesdeacometerlasiguienteprueba.Deestaforma,el sistema iba mejorando su rendimiento progresivamente y en el momento de realizacindelos2testsdefinitivossobreelentornodeexplotacinyasedisponade unsistemacompletamenteafinadoentodossuscomponentes. Para las pruebas definitivas sobre el entorno de explotacin se utiliz una configuracindeJmeterenclusterparapodergenerarlacarganecesaria.Elobjetivo era comprobar que el sistema era capaz de atender 1.000 usuarios de Moodle trabajando simultneamente, para lo que se realizaron pruebas de las siguientes caractersticas:

VIJornadesdeProgramariLliurehttp://www.jornadespl.org7

#PCclusterJmeter #Hits/seg Prueba1 Prueba2 12 18 600 800

#Hits/hora 2.100.000 2.900.000

Usuariosconcurrentes 1200 1500

Tabla1.Caractersticasdelaspruebasdecarga. Cabedestacarquelasimultaneidadnohacereferenciaameraspeticioneshttp,sinoa lacantidaddeusuariosqueseencuentranenelsistemaejecutandopartedeunasesin talycomolahemosdefinidopreviamenteenlosperfiles.Esdecir,estamosante1200 o1500sesionesde7minutosydeusuariosdiferentesqueseejecutandemanera solapadaeneltiempo. Acontinuacinseresumenloscuellosdebotellamsimportantesquesedetectaron enlaplataformaconformeavanzabanlaspruebasylassolucionesqueseaportaron paracadaunodeellos.Sepresentanagrupadossegnlacapadelaplataformaenla quesehaactuado:

Balanceadoresdecarga: Una vez instalados los balanceadores, las actuaciones sobre ellos consistieron en afinaralmximolosvaloresdelosdiferentestimeoutsdeldirectoryendefinirun testadecuadoparalacomprobacindelserviciohttp(ennuestrocaso,laconsultade unarchivo.gif). FrontendsHTTP: InstalacindeunaceleradorPHP.(PHPeAccelerator) PuestoqueelcdigoMoodleest basadoenPHPcasiensutotalidad,estaesla medidadetuningmsevidente.Aunas,losratiosdemejoraobservadoscuando se instala un acelerador pueden variar dependiendo de diversos factores. En nuestraspruebasseobservabaunamejorasustancialperonoexcesiva(alrededor deun15%deincrementodelacapacidaddelsistemarespectoalaspruebassin acelerador). ProcesosdeApache. Eselobjetivoprioritariodelaactuacin.Lacapacidaddeconcurrenciadelweb serverdepende,engranmedida(elaprovechamientodelaCPUyamejoragracias alaceleradorPHP)delamemoriadisponible. AunqueApacheesunservidorwebdemagnficasprestaciones,lautilizacinde PHP nos impone algunas restricciones: puesto que PHP no es un producto

VIJornadesdeProgramariLliurehttp://www.jornadespl.org8

consideradothreadsafe,noesposibleejecutarApachebajoelmdulo mpm worker,queesdondeconsigueunmayorrendimiento.Moodle(PHP,enrealidad) nos obliga a utilizar el mdulo mpmprefork, pasando a usar Apache en multiprocesoenlugardemultithread.Estoquieredecirqueparaatendercada peticinHTTPApachelanzaunprocesohijoqueconsumememoriaadicional. As,lacantidaddeprocesosApachequepuedetenernuestrosistematienecomo lmitefsicolamemoriadisponibledivididaentrelamemoriaocupadaporunode estosprocesos. Ennuestrasmedicionesseobserv queelpesodeunprocesoApacheoscilaba entrelos10y12Mb(llegandoinclusoa15Mbsegnlascondicionesdelsistema). Suponiendounsistemacon3Gblibresdememoria,podramostenernomsde 300procesosenmarchaencadaFrontend. Para incrementar este lmite sin aumentar la memoria fsica de nuestros servidores,seexamin condetalleeltrficoHTTPysedetermin quemsdel 50% de las peticiones que deba atender el servidor web corresponden a contenidoesttico.Concretamenteimgenesdepocotamao(gif,png,jpg...)que sesirvenunayotravezyseencuentranencabeceras,piesdepgina,iconos, logos,etc. Como solucin para aumentar la capacidad del sistema se instal en los servidores Frontend un segundo servidor Apache con una configuracin extremadamentesimple:secompilexpresamentesinlamayorpartedemdulos quellevaunservidorestndar,detalmaneraquedebidoaestasimplicidad,sus procesossloocupan2MbytesdeRAM. Esteservidorquellamamostinyapachepasaaserelservidorwebqueatiende enelpuerto80.Paracadapeticinquelellegalonicoquehacees:determinarsi se trata de contenido esttico o dinmico, servir la peticin si se trata de contenidoesttico,yenotrocaso,pasarlaalservidorapacheestndar(queahora correenelpuerto8080). Con este mecanismo, la mayor parte de las peticiones HTTP que recibe el sistema,lasatiendeunservidorcuyosprocesossloocupan2Mbytesdememoria en lugar de los 1012Mbytes anteriores; gracias a ello se incrementa considerablemente el nmero de peticiones que es capaz de atender simultneamenteelsistema. Backend: LasactuacionesenelBackendseorientaronbsicamenteabuscarlaconfiguracin necesariaparagarantizarqueelSGBDpudierasoportarunnmeromuyelevadode conexionessimultneas.Ennuestrocaso,1.500conexiones. Para conseguirlo, aparte de la configuracin del servidor PostgreSQL hubo que modificarlosvaloresdedeterminadosparmetrosreferentesalagestindememoria enelkerneldelinux.

VIJornadesdeProgramariLliurehttp://www.jornadespl.org9

LaexperienciahademostradoqueelnmerodeconexionesalaBasededatossuele mantenerseennivelesconsiderablementebajosinclusocuandotenemosunnmero muyelevadodepeticionessimultneasalsistema.Sielservidortienememoriay CPUsuficiente,suelenservirsemuyrpido. Sinembargo,condicionantesexternospuedenhacerquesuduracinseamayory,por tanto,sunmeroseincrementemuyrpidamenteencondicionesdecargaelevada.Es por esto que es importante que el sistema sea capaz de absorber muchas simultneamente. De todas formas, un nmero muy elevado de conexiones postgreSQLdeformasostenidahabitualmenteconstituyeunbuenindiciodequeel sistematienealgnproblema(yaseadebidoahardware,lentitudenlared,faltade algn ndiceenalgunatabla,consultasmuycostosas,malfuncionamientodealgn mdulodeMoodle,etc.)

5.Conclusiones

5.1Validezdelaplataformaycifrasactualesdeuso. Laconclusinmsobviaesque,unavezpuestasenfuncionamientotodaslasmedidas demejorayrealizadas laspruebas derendimiento,tenamoslacertezadequela nuevaplataformaMoodletenacapacidadsuficienteparaasumirlacargaprevistauna vezincorporadoslaprcticatotalidaddelalumnadoyasignaturasalcampusdigital. Dehecho,lascifrasextradasduranteelprimercuatrimestredeusodelnuevoCampus Digitalsonsuficientementeclarificadorasyrefrendanestaconclusindatrasda.A continuacinpuedenversealgunosdatos:

Usuariosdistintos Diario Semanal Mensual 12.000 20.000 25.000

N merodelogins Registrodeactividad 32.000 140.000 400.000 320.000 1.200.000 4.500.000

Tabla2.Utilizacinactualdelaplataforma Elxitodelaplataformaesincuestionable:segnseobservaenlatablaanterior,cada dautilizanlaplataformaAtenea1/3deltotaldealumnosdelaUPC,algunosdelos cualeslohacenmsdeunavez.Yenunmeslaprcticatotalidaddelosalumnosha accedidoalcampusalmenosenunaocasin.

VIJornadesdeProgramariLliurehttp://www.jornadespl.org10

De hecho, en los das laborables el nmero de sesiones Moodle establecidas se encuentra en valores cercanos a 1.000 de manera sistemtica durante la prctica totalidaddeltiempocomprendidoentrelas10:00hylas22:00h. Enpocasdeusointensivodelaplataforma(afinaldecuatrimestre)sehanproducido picosdemsde2.000usuarios simultneos enel sistemadeformasostenidasin apenasimpactoenlacargaoenlavelocidadderespuestadelosservidores. Alobservarlatablacondetenimiento,quedapatentequeconsemejantescifrasde accesodiarias,forzosamentelacomplejidadyduracindelassesionesrealesenla actualidaddifiereenciertamedida(ynecesariamentealabaja)delmodeloquese utiliz pararealizarlaspruebasdelsistema.Eslgicoqueunavezlaplataformase extiendeaunpblicomuchomsamplioysegeneralizasuutilizacin,lospatrones deusovarensustancialmente.Elaccesomsfrecuentellevaconsigoelrepartodel trabajoentrelasdiferentessesioneseimplica,tantolareduccindelacomplejidadde lastareasqueserealizanenunasesin,comounadisminucinenladuracindela misma.Encualquiercaso,estasreduccionessecompensanconelincrementoglobal depeticionesy,enestasnuevascondiciones,elsistematodavadebegarantizar(como de hecho sucede) la capacidad suficiente para atender la elevada demanda de conexionesalsistema. 5.2Otrasconclusiones:factoresclavedexito. Almargendelasconclusionesrelativasalavalidezonodelaplataformaescogida, existen unconjuntode resultados (ms bien lecciones) extraidos de este proyecto quiznotanevidentesperoquepuedentenertantaomsimportanciaquelaprimera:

Perfilesdeusuario:factorclavedexito. Conseguirunosperfilesdeusuariolomsajustadosposiblealarealidad(ocomo mnimo,alarealidadquenosinteresareproducir)eselfactormsimportanteala horaderealizarlaspruebasderendimientoconciertagarantade xito.Aunquehay queserconscientedequesetratadepruebasdelaboratorio,esimportantereproducir elescenariodelaformamsrealistaposible. Notodoslosmdulos deMoodletienenelmismoimpactoenelrendimientodel sistemayportanto,esimportantedaracadacomponenteunpesosimilarenlas pruebasalquetieneenelusodiario. Cambiosenplataformaosoftrequierennuevaspruebas. Unapruebaderendimientodenuestraplataformarealizadahoyslotienevalidez mientras noseproduzcaningunavariacinenlos elementosdelsistema,yasean hardwareosoftware.

VIJornadesdeProgramariLliurehttp://www.jornadespl.org11

Aadir procesadores, memoria, o incrementar la velocidad de la red tendrn un impacto(lamayorpartedelasvecespositivo)enelrendimiento.Peroesmuydifcil decuantificarapriori. Loscambiosenelsoftware,yaseanporcambiodeversindeMoodle,utilizacinde nuevosmdulos,cambiosenversionesdelwebserver,elservidordebasesdedatoso cualquierotrocomponentedesoftwarebase...sondelicadosysuinfluenciaenel comportamientofinaldelcampusdigitalenmuchoscasosesunaincgnita. Porestemotivo,cualquiercambioenelsistemarequieredenuevaspruebasparaque podamosestarsegurosdequelaplataformaseguircomportndosecomoesperamos. Aunas,hayqueserconscientedequenosiempreesnecesarioacometerunproyecto enorme para hacer estas comprobaciones. Dependiendo de la dimensin de los cambios podemos, desde decidir no hacerlas, hasta realizar algunas pruebas de pequeacomplejidadquenossirvanexclusivamenteparacompararelrendimiento entrelasversionesyaconocidasylasnuevas. Necesidaddeunentornodepruebasestable. Paradotaraesteproyectodeunaciertacontinuidad,esrecomendabledisponerdeun entornodetestestable.Loidealseradisponerdeunarplicaexactadelentornode explotacin, pero eso no siempre es fcil de conseguir. De hecho, tampoco es imprescindible, aunque s que es importante que ambos entornos sean fcilmente comparables (p.ej, no montar un entorno de pruebas basado en un servidor que integre Frontend y Backend si nuestro entorno de explotacin tiene estos componentes separados). De esta forma ser posible extrapolar los resultados obtenidosenlaspruebasyminimizarlanecesidadderecurriralentornoreal,cuya disponibilidadparaestostemassueleestarmuyrestringida.

VIJornadesdeProgramariLliurehttp://www.jornadespl.org12