Cuando uno crea sus primeros script en PHP, los programas corren como el viento. Un par de consultas a la base de datos y la presentación en pantalla de rigor no ocupan más de unas centésimas de segundo. El problema empieza a surgir cuando se ocupan diversas librerías y las consultas a la base de datos se hacen más grandes.
El problema de optimizar un sitio en PHP es complejo, porque intervienen muchos factores.
En esta primera entrega, hablaremos sobre el hardware y dos compañeros inseparables de PHP: el servidor HTTP y los sistemas de bases de datos.

Hardware

En primer lugar, tenemos el hardware. Muchos tenderán a pensar que lo más importante es la velocidad del procesador, pero no es así. Generalmente, los cuellos de botella se producen por memoria y por la velocidad y tipo de acceso a disco duro; en el primer caso, si se supera la cantidad de memoria física del sistema, tendrá que recurrirse a la memoria swap, la cual es mucho más lenta porque implica acceso a disco duro. Para un servidor de desarrollo, que debe correr el servidor HTTP, la base de datos y el navegador, lo mínimo esperable son unos 512Mb en RAM.
En el caso de los discos duros, los discos SCSI presentan mucho mejores prestaciones bajo altas exigencias que los discos IDE (Referencia) . Ahora bien, en un entorno de desarrollo, donde los requerimientos no son altos, un disco IDE tendrá casi las mismas prestaciones que un SCSI.
Actualmente, los discos con interface ATA Serial(SATA), están desplazando a los discos SCSI porque ofrecen mejor relación precio/prestación. En el caso de los sistemas con RAID, SATA puede ser una excelente alternativa cuando lo más importante es la seguridad de lo datos y el costo final, más que el rendimiento.
Otro factor importante, que parece de perogrullo, es que en lo posible no se debe ocupar la máquina servidor en otra cosa. Además, será en general mejor el rendimiento de varias máquinas pequeñas, cada una encargada de una tarea, que una grande que tenga que todo el software. Esto, porque al estar distribuida la carga, es menos probable que se produzca un agotamiento de los recursos. Este es el esquema que utiliza, con gran éxito, Google.
También es necesario considerar la forma en que se configura la red, pero admito mi ignorancia en ese tema :P

Considerando ahora el software, existen dos factores externos a PHP que son importantes de considerar: el servidor HTTP y el sistema de base de datos a utilizar.

Servidor HTTP

Entre los más famosos se cuenta el infaltable Apache, el Internet Information Server de Microsoft, Zeus, etc. Apache es reconocido por su estabilidad, pero en situaciones de alto tráfico presenta menor rendimiento que otros servidores. IIS, bien configurado, puede ser la mejor opción en Windows para PHP. Zeus, en situaciones de alto tráfico, presenta un mejor rendimiento que Apache
Como reglas general, lo mejor es utilizar el máximo número de páginas estáticas posibles, ya que el servidor las entrega con mayor rapidez, casi sin uso de memoria y procesador. Si los recursos lo permiten, es ideal tener dos máquinas, una para los contenidos estáticos (HTML, imágenes y multimedia), en la que debe privilegiarse la velocidad de acceso a los datos, y otra encargada del contenido dinámico, con mayor memoria y capacidad de proceso.

Sistemas de bases de datos

Al igual que en el caso de los servidores, existe infinidad de sistemas de bases de datos, cada una de las cuales presenta sus ventajas en ciertos contextos. Si bien Mysql se caracteriza por tener una gran velocidad, su falta de características más avanzadas, como procedures, triggers y vistas lleva a que mucho del trabajo se lo lleve PHP, siendo posiblemente más eficiente una solución basada en la base de datos. En estos casos, PostgreSQL aparece como una excelente alternativa a tomar en cuenta si desarrollamos sitios de una envergadura mayor.
Ahora bien, en entornos empresariales es probable que nos encontremos con Sql server o con Oracle. Estas bases de datos no se caracterizan por su velocidad, así que no se extrañen que aquella consulta que en MySql volaba, ahora parezca una tortuga; es muy importante estudiar a fondo la documentación de estas bases de datos, para optimizar las consultas.
Es muy importante, al realizar cualquier tipo de test de rendimiento, utilizar la cantidad de datos que esperamos tener en la aplicación ya funcional. Suele ocurrir que una consulta que funciona de maravillas con unos diez datos se vuelva un elefante inmanejable al llegar a las mil tuplas.
En términos concretos, en Mysql es muy importante estudiar el papel de los índices, ya que pueden optimizar de modo dramático el desempeño de la base de datos. También es necesario poner especial atención en variables del servidor como el número de conexiones máximo(max_connections), el número de tablas en el cache (table_cache), el tamaño del buffer de ordenamiento(sort_buffer_size) y de de índices (key_buffer_size), entre las más importantes. Por ejemplo, si tenemos pocas tablas y muchos ordenamientos, hay que disminuir el número de tablas en cache y aumentar el buffer de ordenamiento; en caso de muchas conexiones, hay que disminuir al mínimo el tamaño de todos los buffers. Utilizando un conjunto de consultas típicas, se pueden probar distintas combinaciones hasta encontrar la más adecuada.

En SQL Server, la cantidad de memoria del servidor es importante. En entornos de desarrollo, lo mínimo recomendable es 512Mb. El tema de los índices en esta base de datos no es tan importante como en MySql, porque se generan automáticamente al establecer las relaciones foráneas. En mi experiencia, pareciera que las operaciones de orden son bastante costosas en esta base de datos, así que en general trato de utilizarlas al mínimo indispensable.
Entre los consejos generales para las distintas bases de datos, se encuentran el utilizar el tipo de datos preciso para cada columna (es mucho más lento comparar dos text que dos varchar, por ejemplo), el normalizar la base de datos a la tercera forma, por lo menos, y tratar de usar lo menos posible los campos que acepten NULL, ya que la indexación de estos campos es más lenta.

Hasta acá llegamos con este artículo. En el próximo, abordaremos el uso de sistemas de cache en PHP, tanto en lo referido al almacenamiento del código PHP compilado como a los utilizados en los scripts. Nos vemos!

Links de interés

• Optimizing Apache Server Performance
• Tuning Apache and PHP for Speed on Unix
• Configurar IIS con PHP y Fast-CGI
• SCSI & IDE: Overview and comparison
• Mysql: Optimizing Database Structure

Actualización

1 de Enero de 2005: Algunos comentarios sobre SATA, a petición de hyoga.