Manuel Lemos ha publicado en PHPClasses.org un interesante artículo con buenas prácticas a la hora de desarrollar sitios con millones de accesos concurrentes. No creo que éstas prácticas sean exclusivas para php y mysql, por lo que creo que es una lectura interesante para cualquier desarrollador web.
Éstos son los puntos que recomienda. Me he tomado la libertad de citarlos y añadirles comentarios desde mi humilde punto de vista.
-
Evitar el acceso, siempre que sea posible, a las bases de datos. Podemos usar archivos temporales, xml, jason o que mejor nos parezca, siempre que nos sea posible o merezca la pena.
-
Cachear páginas web siempre que sea posible. Esto es vital, habrá que preocuparse sin embargo, por algunas secciones que no sea posible cachear, como resultados de búsqueda, y de borrar archivos de cache que hallan cambiado.
-
Evitar la personalización innecesaria (interfaz de usuario). En algunas aplicaciones es importante dejar al usuario que personalice su “espacio” en nuestra aplicacion, en otras es totalmente inútil. Se puede buscar un equilibrio y dejar solo al usuario personalizar su parte pública.
-
Poner en cola tareas que requieran mucho tiempo de ejecución. Si no requerimos una respuesta visual cara al usuario inmediata, podemos lanzar una tarea asincrónamente sin preocuparnos por la respuesta y recoger -importante- el resultado con un email o un registro en la base de datos al acabar la tarea. Si la tarea puede darnos información en diferentes puntos de su ejecución, podemos usar comet para recuperar la información en caliente y sin refrescar la página.
-
Mover imágenes, CSS y Javascript a un servidor web con tecnologia multi-hilo. Al ser contenido estático, nos interesa que se lea rápido y consuma el mínimo de memoria posible. No está de más, si contamos con presupuesto, tener un balanceo de red entre varios servidores con éste contenido replicado.
-
Minimizar el peso de la aplicación mediante compresión html. A mí esto no me parece buena idea ya que algunos navegadores no lo soportan. Prefiero invertir en otros recursos, que perder usuarios.
-
Separar el servidor de email, Web y de base de datos en diferentes particiones (yo incluso los separaría en diferentes máquinas físicas si es posible. Los vps (Servidores Virtuales) están bien pero el acceso a disco y el rendimiento no es tán óptimo como tener uno real para cada máquina)
-
Distribuir la carga, ya sea mediante NBL (Balance de red) o Clustering con varios nodos activos. Habrá que tener en cuenta las variables de sesión (se deben replicar entre los nodos)
