Barrapunto

Es más. Cada vez veo menos literatura sobre optimización en general. No solo en PHP. Supongo que será consecuencia de que tal vez cada vez es menos importante.

Optimizing php es una busqueda con 724000 resultados en Google.
El tema es bastante amplio: desde cómo optimizar un sistema para ejecutar php, hasta como optimizar las propias aplicaciones php.
Por ello, lo primero seria identificar tu cuello de botella: el sistema o la aplicación ( o ambas cosas).

De poco serviria optimizar un servidor con 256 Mb de RAM y procesador mononucleo, si luego quieres que tenga cientos de transacciones por segundo.
Todo el hardware, el software de sistemas y el software de aplicacion debe estar "equilibrado" y proporcionado.
Por eso no existe ningun botón mágico en el PHP que acelere su rendimiento.

Este año en la campus party de valencia, el señor Rasmus Lerdford [wikipedia.org] nos dio una clase magistral de optimización y seguridad.

A más de alguno lo hundió en la mie***, por según él, no hacer esas tareas tan "cotidianas" de optimización.

Te dejo las trasparencias que colgó: http://talks.php.net/show/cp08/ [php.net]

Por lo que comentas, probablemente tu cuello de botella sea precisamente el hosting compartido. Yo sólo he tenido que optimizar consultas a la base de datos, a la hora de mostrar datos estadísticos con consultas complejas. El rendimiento de PHP en general es muy bueno...

Yo he utilizado el plugin de FireFox YSlow para medir el rendimiento de una web. Puede que te sea de ayuda... Incluso da consejos... Recomiendo echarle un vistazo.

Una parte de la optimización no te la puede dar ningún libro, ya que és la que depende del algoritmo de tu programa, y optimizarlo depende de tu experiencia y conocimientos como programador.

Otra parte de la optimización la conseguirás afinando parámetros e instalando una caché de opcode (código intermedio de php): APC [php.net], eAccelerator [eaccelerator.net], Xcache [lighttpd.net] son las más populares y están disponibles para cualquier distribución. Quizás en sus páginas encuentres alguna utilidad para medir el rendimiento. Sino la encuentras, lo puedes hacer como lo hacíamos en tiemos remotos cuando no había IDEs: a inicio de algoritmo que una variable guarde el tiempo actual, y a final de algoritmo otra variable capture el tiempo. Entonces lo restas e imprimes.

Hay unas cuantas utilidades que sirven para medir el rendimiento global de respuesta en caso que tu entorno sea servidor web + php + servidor de bases de datos: ab, curl, ...

Existe como mínimo un optimizador de opcode: Zen optimizer [zend.com], pero creo que es de pago.

En cuanto a bibliografia a mi me gusta afinando Lamp [xtec.net] que no es un texto sino una presentación. En su última página encontrarás algo de bibliografía adicional.

A la hora de optimizar tienes que tener en cuenta una cosa: que quieres optimizar. En resumidas cuentas existen dos tiempos a medir (tiempo y recussos van de la mano y lo mas facil es medir tiempos). Tenemos tiempo de servidor (PHP+BBDD) y tiempo cliente (HTML + JS). Ten esto muy claro y aprende a usar firebug para hacer mediciones. Muchas veces pasa que nos volvemos locos optimizando tiempos del servidor cuando el verdadero cuello de botella esta en el cliente. Mis consejos son los siguietes:

• Optimiza las SQL. Preocupate por los indices, toma tiempos de ejecucion, usa trazas para ver cuantas SQL haces por peticion (a veces te llevas sorpresas desagradables)
• Limita la memoria RAM que usa PHP (en el php.ini). Esto te evita que por error hagas bucles infinitos y dejes tirada la máquina. Por lo demas el rendimiento de PHP es muy bueno (ojo hablo de php no de sql) y muy mal lo tienes que hacer para generar cuellos de botella aqui (a no ser que estes muy limitado de ram o de procesador y entonces si que tienes que optimizar todo)
• Firebug+Yslow es tu amigo
• leete el libro High Performance Web Sites de Steve Souders. Mejor dicho aprendetelo de memoria y mirate todas las conferencias que encuetres de Steve Soulders en youtuve. Es de lo mejorcito que se ha escrito sobre optimización de la parte cliente.

Lo primero es usar un profiler para ver que partes del código tardan más en ejecutarse. Afortunadamente, Xdebug [xdebug.org] hace exactamente eso.

Hay que instalarlo siguiendo las instrucciones y luego añadir en el .htaccess de tu sitio las líneas:

php_value xdebug.profiler_output_dir /home/web/tmp
php_value xdebug.profiler_output_name cachegrind.out.2
php_value xdebug.profiler_enable 1

o similar. Luego, puedes abrir el archivo resultante en kcachegrind (kde) [sourceforge.net] o wincachegrind (windows) [sourceforge.net] para ver cuales son las llamadas que llevan más tiempo.

En todo caso, es bueno usar una cache de objetos para php como php-accelerator [php-accelerator.co.uk], que suele conseguir un orden de magnitud de ventaja sobre php no cacheado.

Hola a todos y muchas gracias por vuestras respuestas.

En la pregunta original a barrapunto, comentaba que el problema me lo encontré cuando quise pasar de un alojamiento compartido (Arsys y similares) que más o menos funcionaba bien, a un máquina dedicada en Amazon EC2, cuyo rendimiento en PHP era escandalosamente lento.

En concreto yo usé phpspeed para medir el rendimiento. No sé si es un buen benchmark, pero el caso es que concuerda bastante bien con mis tiempos de ejecución en distintos servidores de mis scripts reales más complejos que tiran de PHP y MYSQL.

Las cifras que me resultaron para un hosting compartido barato, en piensasolutions (marca "blanca" de arsys) son:

http://developer.amazonwebservices.com/connect/ser vlet/JiveServlet/download/30-25897-105578-2092/per formance_5dollar_shared_hosting.jpg [amazonwebservices.com]

mientras que en una máquina básica en Amazon EC2 con Fedora Core 6 obtuve esto:

http://developer.amazonwebservices.com/connect/ser vlet/JiveServlet/download/30-25897-105578-2093/per formance_ec2_instance.jpg [amazonwebservices.com]

Aplicando optimizadores, aceleradores, tweaks de configuración, etc, etc, conseguí fácilmente multiplicar por 10 el rendimiento de MYSQL, pero sólo duplicar el de PHP, que está muy lejos del hosting compartido.

Gracias de nuevo por vuestros posts.

Instala Zend Platform en tu servidor local de pruebas. Para desarrollo no hace falta pagar por una licencia. Cómo usar Zend Platform para analizar tus aplicaciones se escapa del objetivo de este comentario, pero la documentación es abundante y de calidad.

PHP es rápido, pero los programadores hacemos cada tontería. pero bueno usar algunos free por aquí y por aya pueden ayudar cuando el problema es RAM. pero mi favorito es esas míticas comillas dobles (") que normalmente al cambiarlas por comillas sencillas ganas un par de milisegunditos que al final del día pueden ser horas. También un Code cache (APC, TurckMMcache, Xcache, los demas o no son libres o ya apesta el muertito) acelera la aplicación, funciona para FastCGI o apache con PHP como modulo, básicamente lo que hacen es tomar el código PHP ya "parseado" y guardar esa copia, entonces te ahorras el análisis sintaxico de cada archivo cada ves. E visto casos donde usar Bcompiler te acelera también la ejecución, es cosa de probar. Si no es buen OPcoder. También es necesario checar las cosas con xdebug, el es tu amigo, sabe donde se quiebran las cosas, donde están los hoyos negros de los recursos. También recordar que para optimizar necesitas realmente conocer el lenguaje, hacer un cambio para acelerar por hacerlo, hay que saber como va a modificar eso el comportamiento general. El ultimo consejo, componentes binarios son mas rápidos (ADOdb tiene, y su versión en "PHP pure" puede ser algo lenta) La DB y el acceso a disco tienden a ser los verdadero cuellos de botella (mas db) usa un objetcache (memcache, tugelaCache o el que traen los opcode). Y como muchos ya dijeron, leer mucha documentación. Enlaces? ya mucha gente publico algunos, Y lo demás preguntenle a su buscador favorito. Pero recomendaría estas notas. http://www.emezeta.com/articulos/funciones-php-opt imizar-codigo [emezeta.com] http://reinholdweber.com/?p=3 [reinholdweber.com] http://www.tufuncion.com/optimizar-codigo [tufuncion.com] Recomendaciones finales. Recuerda hay dos maneras de optimizar. una eliminando las cosas que se tragan recursos, o pasando esa carga a otras areas (DB a memcache es un buen ejemplo) si haces esto ultimo recuerda. Transferencia es mas barata que procesador, y disco duro extra todavía es mas barato que el ancho de banda. Usar Gzip al vuelo es un desperdicio tremendo de procesador no justificable, mejor trágate el ancho de banda. pero mejor aun, usa un cache de las cosas ya comprimidas, gastas poquito procesador, poquito ancho de banda, y apenas poco mas disco duro..

Yo creo que la mayoria del cuello de botella esta en las BBDD externas. A esto hay dos salidas: o bien dejas de usar BBDD o bien usas una embedida como SQLite. Si por lo que sea no puedes, trata de optimizar tu acceso a BBDD lo maximo. Por ejemplo reutiliza conexiones, haz benchmarks usando bsdsockets o sockets unix, etc.

Por otro lado, si tanto te preocupa optimizar tendras que revisar tu codigo poniendole cronometros de tiempo en las entradas y salidas de cada zona y por ultimo mucho se habla de ASP y PHP, pero si REALMENTE QUIERES POTENCIA DE PROCESO te agarras el gcc y te haces un FAST-CGI... mas rapido que eso NO HAY NADA (bueno... ensamblador jejeje). Por supuesto lleva trabajo: y ojo, porque con C el gasto de memoria se te puede disparar, aunque tambien es el que -bien programado- consume menos. Tienes infinidad de librerias, etc.

Por ultimo, se me olvidaba... mira que tu hosting tenga una conexion de calidad y no quede en el culo del mundo. Muchas veces el lag es alto y tambien influye... todo influye en realidad.

Joer, igual es error mío de base, pero Apache no hace eso con su librería php? Quizá hableis de php a pelo (yo lo asocio siempre a servido por apache). A ver si voy a estar equivocado de siempre y me sacais de un error profundo. Un saludo

Hombre, si comenta que su servidor es linux, creo que va a tener un grave problema para pasarse a ASP, jeje.

De todas formas, también existen herramientas similares para PHP, sólo que no suelen ir empaquetadas en un único mega-producto como es Visual Studio. No obstante, algunos entornos como NetBeans y Aptana (eclipse + plugins) también da una funcionalidad similar a la que comentas.

En cualquier caso, la mayor parte de los problemas de rendimiento son o por la base de datos o por problemas de base que son muy costosos de cambiar.

En fin, suerte con ello...

En cualquier plataforma no, pero si en Linux, Mac, Windows entre otros => Mono [mono-project.com]