Lecciones aprendidas sobre rendimiento en PHP

A partir del artículo publicado por Enrique sobre rendimiento y programación orientada a objetos, me he animado a compartir las lecciones aprendidas que hemos sacado Iñaki Ortiz y yo, de nuestra experiencia tras reescribir www.precriticas.com con el Zend Framework. Precriticas es un proyecto con más de 5000 visitantes únicos diarios (y picos de 8.000) que generan diariamente más de 25.000 recargas de la página.

Lecciones aprendidas:

  • La optimización extrema del código (cambiar print por echos, etc…) apenas mejora el rendimiento.
  • La POO disminuye el rendimiento, pero facilita tanto la programación que es totalmente IMPRESCINDIBLE.
  • No hay que caer en la sobreingeniería (overengineering), ni matar moscas a cañonazos. Quizá no sean soluciones muy elegantes, pero a veces un par de arrays y unas funciones son mucho más eficaces que complejos patrones de diseño orientado a objetos.

Las dos cosas que más eficaces resultan para mejorar rendimiento son:

  1. evitar SQL´s excesivamente costosas (subquerys, demasiados inner join´s) o bucles de SQL´s que se repiten una enorme cantidad de veces innecesariamente. (ojo a prepared statement).
  2. cachear requests (páginas enteras) o las sql´s costosas. (ojo a zend_cache).

Y un apunte sobre Zend_cache. Es muy potente, pero nos ha dado problemas. Al principio funcionó bien, pero si decides cachear muchas páginas, genera miles de archivos y el acceso al sistema de archivos se convierte en un cuello de botella… Ahora mismo no lo estamos utilizando aunque planeamos cachear algunas páginas.

Y una última cosa: a veces uno está pensando en complicadas soluciones (por ejemplo para buscar sql´s costosas) y entonces llega la gente que sabe, y te descubre que basta con activar un log.

Etiquetas:
, ,
Buscador hispano de Zend Framework:.

11 Comentarios

  • 1. Pablo Morales  |  diciembre 15th, 2008 at 2:00 pm

    La verdad que en el articulo que mencionas no encontre algo que me diga este es un problema, y esta es la solucion, solo es una referencia.

    Es claro que el tema rendimiento siempre es importante, en cuanto a cuando preocuparse por eso, creo que la prioridad es que el producto ande y sea estable y seguro, despues lo optimizamos.

    En cuanto a optimizaciones hay muchas tecnicas.

    Zend_Cache, para la metadata de las tablas, para las paginas, etc.

    Memcache.

    Cache con Apache.

    Comprimir los js

    Y sobre todo ser ordenado ya que muchas veces se hace la misma consulta varias veces por eso es importante la POO. Y en este caso Zend Framework, que si tiene un problema en este momento es en cuanto al rendimiento, pero es algo en lo que estan trabajando. Creo haber leido por ahi, que estan tratando de usar Zend_Cache, para Zend_Loader, uno de los puntos flojos de Zend Framework

  • 2. Pablo Morales  |  diciembre 15th, 2008 at 2:03 pm

    Para las busquedas hay que usar sphinx, o Zend_Lucense

  • 3. Lecciones aprendidas sobr&hellip  |  diciembre 22nd, 2008 at 3:51 pm

    [...] el artículo anterior,  Iñaki Ortiz y yo hemos decdido ir publicando, de vez en cuando, nuestras experiencias en el [...]

  • 4. Rubén Moraleda  |  enero 9th, 2009 at 12:17 am

    Luis, estas hablando de una media de 0.3 accesos por segundo, es prácticamente imposible que vayas a notar la diferencia entre un echo y un print, o entre un for y un foreach.

    Esta muy bien optimizar todo para un mejor rendimiento, pero por experiencia, nunca jamás debemos sacrificar la escalabilidad y reusabilidad de nuestro código sólo para poder obtener un mejor rendimiento, salvo en casos de aplicaciones muy críticas. Es común que con el tiempo se vaya modificando, ampliando y reparando una aplicación, por lo que cuanto más claro, mejor.

    Un caso muy concreto es el de personas que abusan del caché, pensando que es el santo grial, tened en cuenta que cachear significa cierto overhead, (acceso a disco, hacer un stat del archivo para ver su fecha, deserializar, regenerar, serializar, y otro acceso a disco). He visto casos en los que se cachea absolutamente todo hasta niveles increibles pensando que eso nos dará mejor rendimiento, pero no es así, por ejemplo, que sentido tiene cachear las páginas superiores a la 2 de un listado de noticias recientes?, si casi nadie va a pasar de 2ª página, sin embargo, tiene mucho sentido cachear la página principal de una web.

    Otro ejemplo, no hay mucha diferencia de rendimiento al cachear un DESC TABLE.

    En cuanto a Zend_Cache, yo lo uso exclusivamente para cachear bloques concretos de información, xmls parseados y alguna que otra página completa. De hecho, desarrolle un sistema similar a Zend_Layout que permite el cacheado de determinados bloques del layout utilizando Zend_Cache. No cachea el php que carga la información del bloque, sino que cachea la vista de ese bloque ya “renderizada”, por ejemplo, lo que sería una columna con noticias, o con los últimos comentarios.

    Por último, para mejorar el rendimiento y si sólo tenemos un servidor, lo que mejor me ha funcionado, es instalar un lighttpd para servir archivos estáticos, es mano de santo.
    En mi blog teneis una guia de instalación por si os interesa:
    http://blog.xplorastudios.com/leer/214/instalacion-y-configuracion-de-lighttpd

    Espero que os hayan servido de algo mis experiencias :)

    Saludos.

  • 5. Luis Artola  |  enero 9th, 2009 at 9:36 am

    Hola Rubén,

    gran comentario. Y tienes razón. Yo al principio me lancé a cachearlo todo. ¿Por qué iba a ser malo? Hasta que descubrí esos “pequeños” problemas de overhead al acceder al disco duro…

    gracias por tu aportación!

  • 6. Rubén Moraleda  |  enero 9th, 2009 at 3:05 pm

    Que tal Luis, no hay de que, es un placer.

    Es muy común cometer ese tipo de errores al principio, yo incluso recuerdo haber montado todo un complejo sistema de cacheo para una web que tenia 3000 visitas al día…. La experiencia es lo que te da esa pequeña “capacidad” para poder decidir qué se debe y qué no se debe cachear, dependerá en gran medida de la aplicación que estemos creando y el uso que se le pretenda dar.

    Saludos.

  • 7. Enrique Place  |  enero 18th, 2009 at 4:29 pm

    De acuerdo con Rubén, esta frase resume lo que intentaba transmitir en el post original:

    “Esta muy bien optimizar todo para un mejor rendimiento, pero por experiencia, nunca jamás debemos sacrificar la escalabilidad y reusabilidad de nuestro código sólo para poder obtener un mejor rendimiento”

  • 8. Blog de PHP - FinderIT &r&hellip  |  marzo 23rd, 2009 at 3:39 pm

    [...] el artículo anterior,  Iñaki Ortiz y yo hemos decdido ir publicando, de vez en cuando, nuestras experiencias en el [...]

  • 9. Gregoy Hidalgo  |  mayo 13th, 2009 at 6:49 am

    La idea de desarrollar una aplicación web, no solo es facilitar la vida de la ó las personas, sino, es importante pensar en el rendimiento de la aplicación cuando sea accesada por muchos usuarios.

    Muy buen artículo.
    Saludos.

  • 10. Pau Gay  |  junio 30th, 2009 at 5:52 pm

    Muchas gracias por los comentarios. Me es verdaderamente útil la experiencia de cada uno de vosotros.

    Mi caso es que tengo una aplicación hecha con Zend y tenemos problemas de rendimiento. No tenemos muchas visitas todavía pero es tremendamente lento!

    Así que voy a ver si pongo en práctica vuestros consejos ;)

    Saludos!

  • 11. Luis Artola  |  junio 30th, 2009 at 7:50 pm

    Hola Pau!

    tengo cuidado… si no tienes muchas visitas y te va lento… puede ser por otros motivos. Quizá no te esté enrutando correctamente y se esté armando un lío… te puede costar encontrar el problema…

Comenta el articulo:

Requerido

Requerido,