Consumo de memoria y plugins de WordPress
Publicado el Lunes 03 de Septiembre del 2007 @ 3:20 por Armonth.
Manz me ha preguntado por correo cuánta memoria consume SigT, bueno en realidad lo hizo el martes pero la carpeta spam de Gmail es lo que tiene a veces…
En su momento (y tampoco hace tanto, un par de días) ya dejó instrucciones de cómo ver cuánta memoria consume una petición pero dada la pregunta me he puesto a mirar y sobretodo a curiosear.
WordPress y otros CMS no son ninguna maravilla en consumo de recursos, una instalación limpia de WordPress 2.2.2 sin plugins ni nada consume unos 6089KB por petición, de ahí la necesidad de WP-Cache.
SigT con todo lo que tiene, consume 6742KB en la portada por lo que realmente es poco. Esta tarde (alguno se habrá dado cuenta y me habrá hablado en arameo) he ido haciendo algunas pruebas quitando/poniendo los plugins que utilizo. Veamos cuánto baja la memoria por cada plugin quitado:
- Ultimate Tag Warrior: 6391KB (-351KB). Sin duda uno de los plugins más “pesados” en SigT, principal motivo de una posible migración a WordPress 2.3 cuando sea estable además de aprovechar la integración que conllevará.
- Custom Query String: 6663KB (-79KB).
- Google Sitemaps: 6269KB (-473KB). Ya es sabido que el plugin gasta mucha memoria y eso que uso la versión beta ya que la estable es considerada “un agujero”.
- Markdown: 6563KB (-179KB).
- Role Manager: 6591KB (-151KB).
- Search Meter: 6632KB (-110KB).
Custom Query String, Official Comments, Paged Comment Edit y Fancy Titles consumen menos de 100KB. Y para el final, Akismet: 6552KB (-190KB).
Lo que me llama la atención es que — aunque es obvio que no es así — algunos plugins no deberían aumentar el consumo de memoria en páginas donde no son llamados para nada.
Por ejemplo el “Search Meter” solamente se encarga de recoger datos cuando se realiza una búsqueda, pero en el momento de procesar la página principal (el HOME) no debería cargarse nada ya que lo único que se carga en la página es un formulario a la espera de que se use.
Y siguiendo esa lógica lo mismo pasa para Official Comments (debería cargarse en las páginas con comentarios hechos por usuarios registrados), Paged Comment Edit / Role Manager (en el Dashboard), Google Sitemaps (al generar el sitemap), etcétera.
Supongo que la explicación es sencilla pero no veo lógico ese comportamiento. Un plugin dedicado a generar un fichero cada vez que se publica algo no debería cargarse en memoria cuando no se publica nada…
De todas formas, el consumo se puede asumir, he quitado el Search Meter (no lo usaba) y el resto son imprescindibles salvo el UTW que desaparecerá si al final doy el paso hacía la versión 2.3 de WordPress.
11 Comentarios (feed)
-
IRCarren nos comenta:
Me encanta poder leer posts a altas horas…
Perdón por la ignorancia pero cuando te refieres a consumo de memoria… es memoria RAM, verdad?
Cuanta memoria te permite consumir un hosting? Me parece que tu estás en DREAMHOST y es por saber si alguna vez haciendo pruebas te pasaste y te avisan o no hay limite?
En un post de Compuglobalhipermeganet explicaba que no le dejaron colgar un buscador de Mysql llamado Sphinx por consumo de memoria.
-
Armonth nos comenta:
Sí, memoria RAM. Sobre lo que te permite consumir, hay varios matices pero hablando en general para cualquier hosting:
- Lo primero es que lo que suelen limitar es vía PHP lo que un script puede consumir como máximo.
- Luego, si haces un uso muy alto (por encima de sus parámetros) te dan toques y/o terminan el servicio.En Dreamhost no hay ningún límite de ese tipo pero no pongo en duda de que si por usar demasiada memoria provocase fallos me darían algún toque u algo…
-
Reboot nos comenta:
¿Cómo calculas la memoria que te chupa?
-
Reboot nos comenta:
Doh, no me contestes, me pasa por leer sin las gafas… ._.
-
Croc nos comenta:
Me imagino que el consumo de memoria dependerá también de la versión de PHP que se utilice, ya que no estará igual de optimizado la versión 4.3.3 que la 5.1.2. ¿Con qué versión se han obtenido esos resultados?
¿Las cantidades son invaribles entre peticiones? Es decir, ¿2 peticiones iguales totalmente independientes arrojan las mismas cantidades? Aunque WP-Cache esté deshabilitado, supongo que hay otras varias cosas que pueden influir variablemente en el consumo, desde Apache, pasando por la forma que integre PHP (CGI o mod), e incluso MySQL puede que afecte a la capa de abstracción de la base de datos de WP.
Supongo que la cantidad de memoria será virtual y no real.
Un saludo!
-
Manz nos comenta:
Me permito contestar a algunas de las preguntas de Croc (Si alguien cree que me equivoco, que me avise):
> Me imagino que el consumo de memoria dependerá también de la versión de PHP que se utilice, ya que no estará igual de optimizado la versión 4.3.3 que la 5.1.2.
Según tengo entendido y mediante las pruebas que he hecho, PHP4 obtiene menos consumo de memoria para un mismo script que PHP5, aunque éste último es mucho más eficiente para la mayoría de las tareas (y tiene un gran número de detalles mejorados).
> ¿Las cantidades son invariables entre peticiones? Es decir, ¿2 peticiones iguales totalmente independientes arrojan las mismas cantidades?
Depende un poco del estado del servidor, pero normalmente si varía es despreciable, son sólo entre 1~3 Kb.
> Aunque WP-Cache esté deshabilitado, supongo que hay otras varias cosas que pueden influir variablemente en el consumo, desde Apache, pasando por la forma que integre PHP (CGI o mod), e incluso MySQL puede que afecte a la capa de abstracción de la base de datos de WP.
Efectivamente, tareas como la gestión del apache, el número de reglas de denegación de acceso (control de ips, host -sobre todo tareas de nslookup-), llamadas a modrewrite, etc. consumen memoria. Para esto lo mejor es guardar una variable al inicio del script PHP y al final del script restar el consumo final al de la variable. Asi obtendríamos el consumo real del script PHP.
——-
Por experiencia personal, en Dreamhost no hay restricción de este tipo. Simplemente cuando consumes mucha CPU/RAM pueden avisarte para que bloquees ciertas IPs o revises el consumo de tus scripts.
Saludos,
-
Manz nos comenta:
Y ahora, centrándome en el artículo:
Una llamada (que creo que usa bastante el Wordpress) de include sirve para cargar un script PHP en otro, leyendo su contenido y evaluandolo.
La diferencia principal podría ser que un script que contiene sólo HTML podría ser cargado con una llamada a readfile (mucho más eficiente porque no evalua), sin embargo, una llamada include verifica linea por linea el código PHP y lo evalua.
Esto puede ser bastante costoso en términos de memoria, sobre todo en include de ficheros muy largos (Hagan la prueba, coloquen un memory_get_usage() antes de ciertos includes, y otros despues).
Técnicas para evitar esto se basan en el uso de funciones como isset(), donde por ejemplo, en el caso de plugins que miren los referer tendrian que hacer primero una comprobación para saber si existe la variable superglobal _SERVER[’HTTP_REFERER’] y si es asi, cargar con un bloque e include el plugin.
Yo estoy bastante contento con mi CMS, apenas consume entre 200-400kb por petición :)
Un Saludo,
-
Armonth nos comenta:
A lo dicho Manz: las pruebas se han hecho en la versión 4.x con mod_php que hay actualmente en WordPress y es consumo total (todo, mod_rewrite y demás incluido)…
-
Manz nos comenta:
A ver si más gente se anima a comentar sus resultados para tener una idea de diferentes CMS como Movable Type, WP con diferentes plugins, etc…
-
alex nos comenta:
En mi caso, con 19 plugins activos, WordPress consume alrededor de 8000 KB.
-
Brian nos comenta:
entonces, hay manera facil de prevenir la llamada de los plugins que cagarse en los casos en que no se debe cagar?
