El problema del volumen de datos que nunca pudiste probar



Más de una vez programamos algo pensando que está funcionando ok, que la solución fue bien pensada, que está todo como debería. Lo probamos, "en local funciona", armamos el deploy y lo mandamos al servidor sin volver a pensar en él.

Pero siempre, siempre, hay un problema de performance, y les puedo contar mil y una historias de problemas semejantes. Nadie testea una puta mierda con volúmen, nadie le da importancia y todo empieza a fallar.

Como sabrán algunos este blog no utiliza Wordpress, lo programé todo de cero y todavía sobrevive porque lo hackeo constantemente, un cachito aquí, otro allá, y más o menos sobrevive al paso del tiempo. Pero para cuestiones laborales o de otros clientes siempre utilizo Wordpress y un clásico allí son los plugins.

No voy a meterme en detalles técnicos demasiado complejos pero me dan ganas de contar un poco cómo es este tema para aquellos que putean desde el otro lado y no entienden qué está sucediendo en realidad, es como un pequeño rant para programadores, implementadores y usuarios que putean a diario :D



Les cuento la historia de un pequeño plugin, el mismo lo habíamos comprado para un cliente, vendía lo que necesitábamos que hiciera así que era el ideal, miramos el puntaje, estaba bien calificado, venga, diez dólares solucionarían todo.

Lo instalamos, anduvo todo perfecto, entregamos el sitio y, como habitualmente se hace en estos casos, no volvimos a entrar hasta que el cliente no nos pidió algún cambio.

Imaginen entrar al panel de administración de un sitio y que tarde, literalmente, 20 segundos en entrar en cada cosa. Digo veinte segundos porque instalé un plugin para medir los tiempos y ver qué cuernos pasaba. Cada click eran 20 segundos.

¿Qué estaba pasando? Yo había instalado todo, el primer día andaba genial ¿Qué se rompió? ¿Alguna actualización?

Investigando un poco di con lo que es el problema habitual de los plugins de Wordpress: Estan programados como el orto por malos programadores paranoicos que quieren cobrarse licencias por todo pero no se preocupan por la performance de sus plugins.

La situación era la siguiente, el plugin consultaba el servidor del desarrollador para ver si había una versión más nueva y así poder ofrecértela para que pagues por otra cosa o, por si no tenías licencia, para reclamarte un serial KEY. El Key lo tenemos, el plugin lo compramos, pero esta confirmación la chequeaba TODAS LAS VECES que una página se mostraba.

Si entrabas al dashboard, consultaba, si entrabas a editar una nota, consultaba, le dabas guardar, volvía a consultar. Algo que no tenía NADA que ver con la sección del administrador donde estabas, consultaba igual. Esto es prácticamente un ataque DDOS al servidor del desarrollador, dos personas trabajando en el sitio eran una bomba, por lo que cada consulta se tardaba 14 segundos en completarse.

WTF? 14 segundos para preguntar algo que deberías consultar una vez al día con suerte? Edité el código del plugin, le comenté la cosulta, le emparché un poco aquí y allá y listo.

¿Saben quién más hace esto?

El mismo puto Wordpress.

Todo el tiempo hace al menos cuatro consultas a api.wordpress.org (que a todo esto es super inseguro) verificando si hay algún parche de seguridad, en vez de hacerlo aleatoriamente o cada cierto tiempo lo hace al cargar cada página del wp-admin, pero como la velocidad de respuesta depende mucho de la conexión entre un servidor y otro (el del cliente es una mierda lenta insostenible, pero no es mío, no puedo cambiárselo) cada una de estas consultas se llevaba 1 segundo y pico extra, ahí tenía los 20 segundos totales.

Estos 4-5 segundos varían, a veces baja a 0.2 seg, algo super aceptable, otras veces sube hasta 5 seg, inaceptable, pero es el costo de la misma plataforma y de mantenerla actualizada. No estoy precisamente de acuerdo con el método.



La cuestión es que ninguno de estos sistemas tenía en cuenta el volúmen de usuarios, cuando se encontró con un escenario real todo falló e indagar cual es el problema en el código de otro es una mierda.

Otro plugin guardaba un log con la actividad de no se qué, cargaba el log en memoria apenas uno entraba al admin, no cuando uno consultaba las estadísticas de ese plugin, las cargaba SIEMPRE. Otro ejemplo de programar como el orto. Tengan en cuenta que la mayoría de sistemas que guardan data en una base de datos y ésta no se pasa a archivo nunca (la data vieja) van llenando el servidor al punto que una consulta se vuelve imposible. Esto no lo chequea nadie en ningún sistema porque nadie se molesta en generar un set de datos de prueba de millones de registros, mucho trabajo! nunca va a pasar!

En este mismo blog, y por mi propia culpa, en una época hacía miles de consultas innecesarias. Me di cuenta cuando me atacaron el sitio. Un día me cansé e implementé una caché bien simple, archivos .html guardados para cada usuario o para anónimos, duran unos minutos, pero si recibo un DDOS el servidor lo único que "gasta" es en preguntarse si existe una sesión de usuario y sino busca un archivo, sólo genera de nuevo la página si el archivo es muy viejo. Ahorro del 90% de uso de procesador más o menos :D

Ante la circunstancia de alto tráfico nos damos cuenta del problema real, hoy no hay sitio con Wordpress que no tenga que implementar alguna forma de caché, este blog puede funcionar sin problemas sin caché, sólo que me conviene tenerlo por las dudas de un DDOS.

Pero claro, yo no me la paso pidiéndole a sitios de terceros data de un update o cosas por el estilo, cada vez que alguien programa dependiendo de un tercero es cuando se da el problema principal y el código de terceros sólo preocupados en vender una licencia más está haciendo mierda la performance de muchos sitios.

Ahora bien, si creías que mucho cuidado sobre tu software podía solucionar esto, tal vez no sea posible. El mejor ejemplo está en la sonda Schiaparelli que se hizo puré contra Marte hace un par de semanas, la razón del error fue un sensor que emitió tal volumen de información al cruzar la tenue atmósfera marciana que el procesador se confundió y abrió paracaídas y preparó el proceso de aterrizaje cuando todavía estaba a 3km de la superficie. La saturación provocó un cuelgue y la destrucción de la sonda algo que en las decenas de pruebas previas no saltó a la luz.



Otra circunstancia con la que seguro muchos ya se encontraron es cuando un "mago" de estos que meten código sin entenderlo pide servidores a mansalva para que su software funcione bien, como si el problema fuere siempre que la máquina no alcanza. Vuelvo a ese plugin, seguramente con un servidor bestial nunca se iba a notar el problema, estaríamos usando mil veces más recursos de los necesarios, pero no se notaría.

Creo que eso es lo más importante que aprendí en la facultad cuando todavía cursaba, esa época en la que nos daban 8Kb de RAM para ordenar un millón de registros, cosas así, uno debía pensar la solución sin reventar la memoria, algo que hoy en día ya casi ni se analiza.

Hemos ido perdiendo el control en capas y capas de código que no entendemos, detrás de frameworks y abstracciones, probando cosas nuevas sin haber terminado el trabajo con las viejas, y como dice un programador que conozco, todo el software está roto. Lo importante es entender siempre esto.

Si te gustó esta nota podés...
Invitame un café en cafecito.app


Otros posts que podrían llegar a gustarte...

Comentarios

  • ezeq     05/12/2016 - 10:43:41 Revisado: 05/12/2016 - 11:29:56

    Es un sublime CLAP CLAP!
    Lo postulo para los premios Fabio.
    Que si no existen todavía deberíamos crearlos.:D
    Edito el comment para agregar.
    Yo particularmente testeo todo en un server local con 512mb de ram y un procesador viejito. Si anda ahi y se mueve bien, puede ver la luz.
    Nadie le da bola hoy por hoy a lo que ocupa de ram, lo que "pesa" en datos y lo que consume en consultas como decías mas arriba.
    Todo está apoyado en la nube y después pasa como fue hace unas semanas que cayó google y no andaba el cabsha en ningún lado. (Por citar solo un ejemplo)

  • carlosromanxyz     05/12/2016 - 11:59:41

    Discrepo en decir que WordPress es inseguro, sin embargo te encuentro toda la razón en el 99% de tu post. Aunque mi discrepancia, va derechamente enfocada a lo siguiente:

    He trabajado en varias agencias y últimamente estoy trabajando en modo freelance en lo cual he detectado que diseñadores gráficos que nada saben de performance y programación, están vendiendo sitios WordPress plagados de plugins, claramente al cliente final le interesa más tener un sitio bonito lleno de color -y barato-, que un sitio con buen back. Personalmente detesto los plugins, uso los que son necesarios, para no reinventar la rueda, pero siento que la culpa es netamente del área de diseño.

    Las agencias ya no buscan programadores, buscan "diseñadores gráficos con experiencia en WordPress".

  • Fabio Baccaglioni     05/12/2016 - 12:30:12

    carlosromanxyz dijo:

    Discrepo en decir que WordPress es inseguro, sin embargo te encuentro toda la razón en el 99% de tu post. Aunque mi discrepancia, va derechamente enfocada a lo siguiente:

    He trabajado en varias agencias y últimamente estoy trabajando en modo freelance en lo cual he detectado que diseñadores gráficos que nada saben de performance y programación, están vendiendo sitios WordPress plagados de plugins, claramente al cliente final le interesa más tener un sitio bonito lleno de color -y barato-, que un sitio con buen back. Personalmente detesto los plugins, uso los que son necesarios, para no reinventar la rueda, pero siento que la culpa es netamente del área de diseño.

    Las agencias ya no buscan programadores, buscan "diseñadores gráficos con experiencia en WordPress".


    bueno, es verdad, pero una plataforma que te habilita a malas prácticas es una plataforma relativamente insegura, el mejor ejemplo de esto ha sido siempre Windows.

    Wordpress tiene en su propio sitio de descargas decenas de plugins sin chequear, sin actualizaciones, totalmente vulnerables y que se la pasan haciendo truquitos "seo" truchos para posicionarse por encima de plugins mejor programados, todo sea por venderte luego una versión PRO.

    También trato de evitar la parva de plugins enormes que hay, pero a veces algún cliente ya tiene un sitio montado sobre alguna de estas cosas y sin HORRIBLES a la hora de trabajar con gran volúmen de datos.

    Ni hablar, como bien decís, esta tendencia a diseñadores que sepan utilizar un WP y no un programador que te lo implemente. En mi actual trabajo tenemos separado diseño de implementación justamente para evitar este tipo de quilombos, igual nos pasa que, cada tanto, lo que tenemos que hacer es tomar el moco de una agencia floja de papeles y tratar de arreglarlo.

    También tuvimos el caso de cliente con hosting oficial que no funciona ni para atrás, les instalás un WP base y tarda 3-4 segundos en armar una home pelada :P siempre alguno así aparece.

    La vulnerabilidad de WP que comento (y enlazo) es puramente del core, ya no de los plugins.

  • Mariano     05/12/2016 - 13:41:56

    Es como vos decís, pagan 10 dolares por un plugin o theme pedorro y lo venden a precio de oro como una pagina personalizada. Después les piden cambios específicos y salen llorando a contratar alguien que sepa lo que hace en PHP para salvar el curro.
    De esos casos tengo millones, me llaman con un WP prendido fuego, lleno de plugins pagos rotos y hay que empezar a arreglar por las buenas. Para que encima después te pateen el pago final 3 o 4 meses mientras pilotean de vender algún otra bosta con humo para pagarte lo que te deben.

  • bardiel84     05/12/2016 - 14:54:46

    Es la posta, tengo un cliente que le arme un sitio con WP, que funcaba, te quemaba los ojos (el diseño no es lo mio)
    pero consumía 70 mb diarios con aprox 300/500 hits.
    Una amiga le hizo un sitio nuevo super diseño 3000....y me cuadruplico el consumo diario, las ganas de mandarlos a freir churros.....por favor.

  • Gustavo V     05/12/2016 - 15:03:38

    cierto que hay mucho mas laburo en front end que en el backend...

    pero justamente por todas estas mierdas es que elegi dedicarme al backend.

    en mi trabajo actual procesamos cantidades ingentes de informacion y el hardware es fijo (N GB de RAM, X capacidad de procesamiento, etc)

    una idea del volumen: 40 TB de manera diaria, en 1 (si una) hora...

    lenguaje: C++, mas optimizado (con buenas practicas) que juego de PC.

    y lo que veo en la gente que programa en "lenguajes modernos" (java, .net) es que no tienen la mas palida idea de como funciona por abajo del framework, la respuesta de ellos es: ponele mas hardware

  • bardiel84     05/12/2016 - 15:12:56

    Montones de veces los desarrolladores transfieren su vagancia a la infraestructura.
    Me ha pasado de gente que en vez de revisar porque se cuelga la aplicación, sugieren que la solución sea un kill y restart de la misma, total una vez por semana en horarios no críticos sale andando terminas con ganas de agarrarte a las piñas.

  • José Zanni     05/12/2016 - 15:52:47

    Wordpress está de moda...

    Hace unos 3 años tuve un peuqeñe período de encandilamiento con WP y sus plantillas maravillosas llenas de plugins fantásticos.

    Pero aprendí la lección :P

    Ahora sigo usando WP como gestor pero intento meter lo mínimo de plugins y de tantas cosas que le mete por defecto.

  • José Zanni     05/12/2016 - 15:53:53

    Y efectivamente, es cierto que muchos programadores desconocen lo mínimo a la hora de optimizar,.

  • Danbat     05/12/2016 - 16:46:10

    El jueves pasado me le planté a mi jefe y le dije varias de estas cosas en la cara (los frameworks, depender de plugins que no sabés cómo están hechos). No le gustó para nada lo que dije. No se si habrá algún cambio, los "magos" que meten código sin entenderlo son amigos suyos, pero al menos me desquité.

  • Guillermo     05/12/2016 - 17:53:15

    Mariano dijo:

    Es como vos decís, pagan 10 dolares por un plugin o theme pedorro y lo venden a precio de oro como una pagina personalizada. Después les piden cambios específicos y salen llorando a contratar alguien que sepa lo que hace en PHP para salvar el curro.
    De esos casos tengo millones, me llaman con un WP prendido fuego, lleno de plugins pagos rotos y hay que empezar a arreglar por las buenas. Para que encima después te pateen el pago final 3 o 4 meses mientras pilotean de vender algún otra bosta con humo para pagarte lo que te deben.


  • Diego Hernan     05/12/2016 - 20:37:02

    Me tomo el atrevimiento, en hacer un comentario porque parece que hubiera escrito yo el articulo con todo respeto Fabio.
    Yo vengo de la vieja camada, donde abria solo lineas de codigo que hacian maravillas, un simple .com que recupera info del viejo y conocido chernobyl. Cuando todos te decian no hay arreglo formatea y listo. Yo recuperaba info con un solo .com de un conocido ruso.

    Yo creo que es tal cual como dice Fabio, no puede ser que no optimicen la información. Programadores eran los de antes donde en unos pocos mb si no dije kb no quiero ser sorete pero si algunos te metían en unos pocos kb magia pura.

    Un claro ejemplo fue la creciente de la capacidad del almacenamiento y estoy hablando solo para la época que hablo de los discos rígidos fue demasiado rápido, y muchos dejaron de optimizar. Para que vamos a optimizar si hay lugar de sobra.

    Asi hoy en dia hay juegos que ocupan varios GB y los ejecutas y pensas, pero esto es? Me estan cargando.
    Lo mismo sucede con las aplicaciones, a vos te parece que un visor de PDF puede pesar 90mb? cuando otro pesa solo 5mb u otro 10mb.

    No tengo mucho para agregar el articulo lo dice todo. La verdad clap clap. Me senti identificado al 100%

    Saludos gente!

  • Leonardo     05/12/2016 - 21:01:07

    Excelente raconto de los problemas mas comunes.... pero es porque no se enseña a programar en forma eficiente o economa? o porque no importa ?? tan sol odesidia del programador.
    Tengo 45 años... empece en esto de la programacion con una sinclar 1000, pero lo que mas desarollo mi concepto de ahorrar recursos fue programar el microscontrolador 8051... el mismo estaba en una balanza electronica y habia que hacer realmente magia para lograr procesar varios subtotales, manejar los IO , con un solo puntero de 16 bits.
    Luego profesionalmente pase por varios lenguajes, de mayor o menor jerarquia.. pero una costumbre fue medir consumo de recursos como una prueba de funcionamiento, en especial por los memory leaks.

    Hoy en dia en muchos caso me toca tener que "hacer de bombero" con soft hechos por "importantes Software Factories".... que los entregan con escasos test integrales y donde al tener seis meses / un año de uso... se planchan...y luego del segundo pedido de amplicacion de memoria virtual RAM o CPU...recien empiezan a decir.. No será un problema de performance de la APP?, (otro vicio de la panacea (falsa¿?) de la virtualizacion - aunque eso deba ser tema para otra blog.)

    Creo que se debería enseñar mucho mas desarollar o adquirir sentido comun (el menos comun de los sentidos), obvio que no se puede generalizar, soy Ingeniero Electronico ( que ademas programa ...), pero esta especialidad te enseña que cuando te equivocas... lo mas probable es que vuele quemado un micro o un transistor.. no existe el CTRL+Z o el F12 corregir y volver a probar.. y ver que onda... Cosa demasiado habitual en muchos programadores.

    Gracias Fabio

  • elgendo87     05/12/2016 - 23:37:24

    No estoy con la programación, pero me doy cuenta... los programadores (no todos claro), se cagan en todo. "Necesitamos Intel Xeon, 32gb de ram, 48 unidades de disco duro mega raid en espejo hipercubico holografico", el sistema termina usando 2gb de ram, un poco mas para las bases de datos y a veces el cpu pasa de 10%. Pero como no tienen ni idea de cuanta potencia real va a necesitar el programa, que gaste el cliente. Y me ha pasado que le echan la culpa a la red cuando alguna consulta pedorra tarda mucho y no, es el soft que se cuelga y se queda haciendo boludeces.

    por otro lado tenes las app para android, que consumen cualquier barbaridad de memoria para no hacer nada, total ahora los celulares vienen con ram de sobra... para correr NUESTRA app. y el resto???

    Saludos :D

  • Fabio Baccaglioni     06/12/2016 - 00:45:31

    Diego Hernan dijo:

    Me tomo el atrevimiento, en hacer un comentario porque parece que hubiera escrito yo el articulo con todo respeto Fabio.
    Yo vengo de la vieja camada, donde abria solo lineas de codigo que hacian maravillas, un simple .com que recupera info del viejo y conocido chernobyl. Cuando todos te decian no hay arreglo formatea y listo. Yo recuperaba info con un solo .com de un conocido ruso.

    Yo creo que es tal cual como dice Fabio, no puede ser que no optimicen la información. Programadores eran los de antes donde en unos pocos mb si no dije kb no quiero ser sorete pero si algunos te metían en unos pocos kb magia pura.

    Un claro ejemplo fue la creciente de la capacidad del almacenamiento y estoy hablando solo para la época que hablo de los discos rígidos fue demasiado rápido, y muchos dejaron de optimizar. Para que vamos a optimizar si hay lugar de sobra.

    Asi hoy en dia hay juegos que ocupan varios GB y los ejecutas y pensas, pero esto es? Me estan cargando.
    Lo mismo sucede con las aplicaciones, a vos te parece que un visor de PDF puede pesar 90mb? cuando otro pesa solo 5mb u otro 10mb.

    No tengo mucho para agregar el articulo lo dice todo. La verdad clap clap. Me senti identificado al 100%

    Saludos gente!


    para darte una idea, en LinksDV.com además del intercambio de links programé un lector de feeds. En una sola tabla manejo 1.5GB de datos de todos los feeds, no se cuelga y entrega datos relativamente rápido (nunca supera el segundo).

    Es un hosting de Digital Ocean por 10 dólares al mes, puedo manejar esa tabla, entre otras, sin que se trabe, no tengo idea cómo hacen algunos programadores para colgar un MySQL pero una vez en charla con uno lo entendí: él nunca escribía las consultas, se las dejaba al framework que "se encarga de todo".

    Así, pues, el dicho "en local me funciona bien" tiene total sentido :P claro, nunca un escenario realista, nunca.

  • Lelale     06/12/2016 - 08:25:19

    Fabio Baccaglioni dijo:

    Diego Hernan dijo:
    Me tomo el atrevimiento, en hacer un comentario porque parece que hubiera escrito yo el articulo con todo respeto Fabio.
    Yo vengo de la vieja camada, donde abria solo lineas de codigo que hacian maravillas, un simple .com que recupera info del viejo y conocido chernobyl. Cuando todos te decian no hay arreglo formatea y listo. Yo recuperaba info con un solo .com de un conocido ruso.

    Yo creo que es tal cual como dice Fabio, no puede ser que no optimicen la información. Programadores eran los de antes donde en unos pocos mb si no dije kb no quiero ser sorete pero si algunos te metían en unos pocos kb magia pura.

    Un claro ejemplo fue la creciente de la capacidad del almacenamiento y estoy hablando solo para la época que hablo de los discos rígidos fue demasiado rápido, y muchos dejaron de optimizar. Para que vamos a optimizar si hay lugar de sobra.

    Asi hoy en dia hay juegos que ocupan varios GB y los ejecutas y pensas, pero esto es? Me estan cargando.
    Lo mismo sucede con las aplicaciones, a vos te parece que un visor de PDF puede pesar 90mb? cuando otro pesa solo 5mb u otro 10mb.

    No tengo mucho para agregar el articulo lo dice todo. La verdad clap clap. Me senti identificado al 100%

    Saludos gente!


    para darte una idea, en LinksDV.com además del intercambio de links programé un lector de feeds. En una sola tabla manejo 1.5GB de datos de todos los feeds, no se cuelga y entrega datos relativamente rápido (nunca supera el segundo).

    Es un hosting de Digital Ocean por 10 dólares al mes, puedo manejar esa tabla, entre otras, sin que se trabe, no tengo idea cómo hacen algunos programadores para colgar un MySQL pero una vez en charla con uno lo entendí: él nunca escribía las consultas, se las dejaba al framework que "se encarga de todo".

    Así, pues, el dicho "en local me funciona bien" tiene total sentido :P claro, nunca un escenario realista, nunca.

    El framework o la falta de práctica de MySQL, o sea ¿Cuantos hay que por bestias hacen una query de 5 páginas A4 donde tienen un árbol de 40 subselect, donde encima los campos donde buscan son todas claves compuestas y no tenés un solo index en alguna tabla para acelerar la cosa en tablas con mas de 5 o 6 millones de registros cada una?

    "¡En localhost anda!" ... probado con 5 registros cada tabla :|

    El ingeniero que tenemos de team leader nos obligó a programar en maquinas virtuales con pocos recursos, la puteada es constante, pero lo que largamos ahí funciona bien por que si no anda en local, menos va a andar en producción.

  • Nico Prida     06/12/2016 - 11:23:05 Revisado: 06/12/2016 - 11:24:51

    Muy buen post

  • LOMAX     07/12/2016 - 01:22:03

    De acuerdo pero...
    El problema no es solo "nadie testea", "no se enseña", "decidia", es aterior a todo eso, lo podriamos resumir en "no se tiene puta idea, pero igual alguien va pagar por ello", despues por distintos factores vieno lo otro.
    La gran mayoria de desarrolladores en arg., por lo menos, no tiene estudios tecnicos adecuados, falta gente capaz en serio, gente que conozca teoria de desarrollo, patrones, testing, deploy continuo, devops, stress, load balance, seguridad, DB, SO, etc, no importa el lenguaje, el que desarrolla debe saber todo eso y mas.
    Seamos honestos, cuanta gente de toda la que conocen del palo, esta en ese nivel???
    Se deja de optimizar, por que los tiempos de desarrollos deben ser mas cortos (lo quiero ya), por que los recursos son mas baratos (hard y personas), tiene la cualpa el diseñador que programa y cobra dos mangos al cliente que mas no quiere/puede pagar? Quien la pasa peor, el primero que mando fruta y cobro o el programador, que tiene salir a salvar el dia por dos mangos?? Somos libres de elegir que hacer y que no!! ya se, no es el punto de la nota, pero quizas deberiamos aprender a decir mas NO, o por lo menos saber como manejarlo.

    Al margen, algunas herramientas que uso, por que tambien me toca cada tanto agarrar muertos ajenos!
    GITLab, PHPStorm, Jenkins, docker, ansible, RunDesk, Apache AB, jmeter, W3AF, y linux claro, estoy probando phabricator, lo recomiento para equipos de desarrollo.

  • Francisco     07/12/2016 - 10:48:22

    Yo trabajo como sysadmin y no te das una idea la bronca que me da cuando te preguntan a vos porque lo que hicieron anda para el culo o se la pasa vomitando dumps.

  • El exiliado en mexico     09/02/2017 - 09:24:09

    Sorry , por que esto es viejisimo, pero contame que usas para optimizar ya que tengo unos wordpress que dan lastima y nunca me puse a investigar por que no tengo idea

  • Fabio Baccaglioni     09/02/2017 - 10:23:23

    El exiliado en mexico dijo:

    Sorry , por que esto es viejisimo, pero contame que usas para optimizar ya que tengo unos wordpress que dan lastima y nunca me puse a investigar por que no tengo idea


    opciones:

    1.- instalar query monitor para ver cuales son tus slows query directamente desde ahí
    2.- wp super cache, al menos para el visitante la página volará, te quedará mejorar la performance en el wp-admin
    3.- sacar plugins o, con los datos que te de el query monitor, identificar cual es el problemático
    4.- si sabés de bases de datos, mirar los querys e identificar por qué columnas se consulta para crear índices que normalmente wordpress no tiene

  • El+exiliado+en+mexico     10/02/2017 - 03:44:37

    Gracias capo me voy a poner a trabajar a ver si puedo mejorar un poco el blog.

    el punto 2 lo tengo puesto ademas de tener esto configurado en el centos

    Instalar mod deflate y comprobación

    apachectl -t -D DUMP_MODULES |grep deflate
    crear /etc/httpd/conf.d/mod_deflate.conf con un nivel de compresión 5
    vim /etc/httpd/conf.d/mod_deflate.conf

    <filesMatch ".(js|html|css)$">
    SetOutputFilter DEFLATE
    </filesMatch>

    DeflateCompressionLevel 5

    Testeando
    wget --header="Accept-Encoding: gzip" https://test.org/wp-content/themes/mitheme/style.css

    y todavía no se como ver los querys que se consultan y wodpress no tiene, ni idea recuerdo aver activado algo para ver los low querys pero después cambiaron a mariadb y no seguí investigando mas.

    Que podría leer para aprender un poco mas sobre el tema y las criticas son bienvenidas

  • Fabio Baccaglioni     10/02/2017 - 10:28:02

    El+exiliado+en+mexico dijo:


    y todavía no se como ver los querys que se consultan y wodpress no tiene, ni idea recuerdo aver activado algo para ver los low querys pero después cambiaron a mariadb y no seguí investigando mas.


    Para eso usá el plugin Query Monitor https://wordpress.org/plugins/query-monitor/

Deje su comentario:

Tranquilo, su email nunca será revelado.
La gente de bien tiene URL, no se olvide del http/https

Negrita Cursiva Imagen Enlace


Comentarios ofensivos o que no hagan al enriquecimiento del post serán borrados/editados por el administrador. Los comentarios son filtrados por ReCaptcha V3.