¿Mejores prácticas para optimizar los sitios LAMP para la velocidad?

Question

Quiero saber cuando se construye un sitio típico en la pila LAMP, cómo se optimiza para los mejores tiempos de carga posibles. Me estoy imaginando un sitio típico impulsado por DB.

Este es un aspecto de alto nivel y probablemente podría cuestionarse y dejar que lo descomponga en cada capa de la pila.

L - A nivel del sistema, (configuración y sistema de archivos) ¿puede usted hacer para mejorar la velocidad? Una cosa que se me ocurre es el tamaño de las imágenes, ¿la compresión aquí puede ayudar a optimizar todo?

A - Tiene que haber un montón de configuraciones relacionadas con la velocidad del sitio aquí en el servidor web. No es mi Forte. Probablemente dependa mucho de la cantidad de sitios que se ejecutan al mismo tiempo.

M - MySQL en un sitio basado en bases de datos, el rendimiento de la base de datos es la clave. ¿Hay un mejor enfoque de normalización, es decir, usando tablas de enlaces? Los desarrolladores web suelen hacer simples tablas monolíticas que se parecen a 1NF y esto puede matar el rendimiento.

P - además de los ajustes de rendimiento como el almacenamiento en caché, ¿qué puede hacer el programador para afectar el rendimiento a un alto nivel? Realmente me gustaría saber si los enfoques de diseño de MVC afectan el rendimiento más que rápido y sucio. Otros consejos simples como sesiones más rápidas que las cookies serían interesantes de conocer.

Obviamente tienes que ponerte los detalles y encontrar qué código te está ralentizando. También me doy cuenta de que muchos sitios tienen muchas características de rendimiento diferentes, pero asumamos un sitio típico que tiene más lecturas que escrituras.

Me pregunto si podemos compilar un conjunto de mejores prácticas y esperar que las personas relacionen otras preguntas para que podamos elaborar una lista de verificación de manera efectiva.

Mi objetivo es ver si, además de los problemas habituales de rendimiento, podemos ver algunas cosas raras que quizás no creas que vayan juntas con un resumen de las mejores prácticas.

Así que mi pregunta es, si comenzaras desde cero, ¿cómo harías seguro que tu sitio LAMP fue rápido?

Answer 1

Aquí hay algunas cosas personales que siempre configuré en mis aplicaciones LAMP.

• Instalar mod_deflate para Apache, y no utilizan controladores de gzip de PHP. mod_deflate le permitirá a contenido estático compresa, como javascript/css/html estática, así como la salida habitual PHP dinámico y es una cosa menos que tiene que preocuparse acerca en el código.

• ¡Tenga cuidado con los archivos .htaccess! La habilitación de archivos .htaccess para los directorios en su aplicación significa que Apache tiene que escanear el sistema de archivos constantemente, buscando las directivas .htaccess . Es mucho mejor colocar las directivas dentro de la configuración principal o una configuración vhost , donde se cargan una vez. Cada vez que puede deshacerse de un archivo de acceso de nivel de directorio moviendo en un archivo de configuración principal, , usted ahorra tiempo de acceso al disco.

• Preparar capa de base de datos de su aplicación para utilizar un administrador de conexión de algún tipo (yo uso un Singleton para mayoría de las aplicaciones). No es muy difícil hacerlo, y al reducir el número de las conexiones de bases de datos, su aplicación abre recursos.

• Si cree que su aplicación va a ver una carga significativa, memcached puede realizar milagros. Tenga esto en cuenta mientras escribe su código ... quizás un día en lugar de crear los objetos sobre la marcha, los obtendrá de memcached. Un poco de previsión hará que la implementación sea sencilla.

• Una vez que su aplicación está en marcha, ajuste el tiempo de consulta lenta de MySQL a un pequeño número y supervisar el registro de consultas lentas diligencia. Esto le mostrará de dónde provienen las consultas sobre problemas de , y le permitirá optimizar sus consultas e índices antes de que se convierta en un problema.

• Para tweakers de rendimiento serio, querrá compilar PHP desde la fuente. La instalación desde un paquete instala un lote de librerías que nunca puede usar .Desde entornos PHP son cargan en cada caso de una rosca Apache, incluso una memoria de 5 MB de cabeza de bibliotecas adicionales rápidamente se convierte en 250 MB de memoria perdida cuando hay 50 hilos Apache en existencia. Guardo una lista de mi estándar ./configure línea que uso cuando construyendo PHP here, y lo encuentro se adapta a la mayoría de mis aplicaciones. El inconveniente de es que si terminas en necesitando una biblioteca, tienes que recompilar PHP para obtenerla. Analice su código y pruébelo en un entorno de desarrollo para asegurarse de tener todo lo que necesita.

• Minifica tu Javascript.

• Prepárese para mover contenido estático, como imágenes y video, a un servidor web no dinámico . Escriba su código para que las URL de las imágenes y el video se configuren fácilmente para señalar en otro servidor en el futuro. Un servidor web optimizado para contenido estático puede servir fácilmente decenas o incluso cientos de veces más rápido que un servidor de contenido dinámico .

Eso es lo que puedo pensar en mi cabeza. Buscar en Google las mejores prácticas de PHP encontrará muchos consejos sobre cómo escribir códigos más rápidos/mejores (por ejemplo: echo es más rápido que print).

Answer 2

Yo recomiendo empezar con http://highscalability.com/

En cuanto a sus sugerencias:

compresión de las imágenes, definitivamente no. Tipo de archivos de ajuste del sistema, sí, eso podría tener algún efecto, pero mínimo. Pero en realidad lo mejor es usar proxy inverso en memoria, o incluso mejor CDN.

Para Apache básicamente solo carga los módulos que necesita. No cargues nada más. Al igual que con PHP, solo puede usar bifurcar MPM, es importante mantenerlo delgado. En cuanto a la configuración óptima, debes ajustarla a una aplicación específica, hardware, etc. Si tienes suficiente CPU, es recomendable que uses mod_deflate. Más rápido el servidor puede enviar datos al cliente, más rápido puede comenzar a procesar la próxima solicitud.

Answer 3

He usado MysqlTuner para análisis de rendimiento en mis servidores MySQL y su dado una buena penetración en nuevos temas para google, así como hacer sus propias recomendaciones

Answer 4

Un recurso puede que encuentre útil es el YDN set of performance rules.

Answer 5

No olvide que sus usuarios estarán a miles de millas de distancia de su servidor y descargue docenas de archivos para representar una sola página. Esa latencia y la sobrecarga de renderizar la página en sus navegadores puede ser mayor que la cantidad de tiempo que pasa recolectando la información y generando la página.

Consulte las páginas de Yahoo Developer Network acerca de Best Practices for Speeding Up Your Web Site, y el YSlow tool para ver qué parte de la descarga del sitio lleva tiempo.

Answer 6

¡No olvide apagar Atime para su sistema de archivos!

Answer 7

En primer lugar, tenga en cuenta que el rendimiento es un proceso iterativo. No crea una aplicación web en una sola pasada, la ejecuta y nunca vuelve a trabajar en ella. Por el contrario, comienza siendo pequeño y aborda problemas de rendimiento a medida que su sitio crece.

Ahora, en aspectos específicos:

1. perfil. Identifica tus cuellos de botella. Éste es el paso más importante. Debes enfocar tu esfuerzo donde obtendrás los mejores resultados. Debe tener algún tipo de solución de monitoreo en su lugar (como cactus o munin), que le dé visibilidad de lo que está sucediendo en su (s) servidor (es)
2. Caché, caché, caché. Probablemente descubrirá que el acceso a la base de datos es su cuello de botella más grande en el back-end, pero debe verificarlo por su cuenta. Afortunadamente, probablemente descubrirá que gran parte del tráfico se destina a un pequeño conjunto de recursos. Puede almacenar en caché esos recursos en algo así como memcached, ahorrándose el hit de la base de datos, y dando como resultado un mejor rendimiento de back-end.
3. Como otros han mencionado anteriormente, eche un vistazo a las reglas de rendimiento de YDN. Considere recoger el accompanying book. Esto lo ayudará con el rendimiento de la interfaz
4. Instale PHP APC, y asegúrese de que esté configurado con memoria suficiente para contener todos los códigos de bytes compilados de PHP. Recientemente descubrimos que nuestra instalación de APC no tenía suficiente ram; dándole suficiente para reducir el tiempo de CPU a la mitad y la actividad del disco en un 10%
5. Asegúrese de que las tablas de la base de datos estén correctamente indexadas. Esto va de la mano con la supervisión del registro lento de consultas.

Lo anterior te llevará muy lejos. Es decir, incluso un sitio bastante db-heavy debería ser capaz de sobrevivir a una página de inicio en un único servidor modestamente específico si ya has hecho lo anterior.

Eventualmente llegará a un punto en el que la configuración de apache predeterminada no siempre podrá mantenerse al día con las solicitudes entrantes. Cuando llegue a esta pared, hay dos cosas que hacer:

1. Como arriba, perfil. Supervise su actividad de apache: debe tener una idea de cuántas conexiones están activas en un momento dado, además de la cantidad máxima de conexiones activas cuando recibe ráfagas repentinas de tráfico
2. Configure apache con esto en mente. Esta es la mejor guía para la configuración de Apache que he visto: Practical mod_perl chapter 11
3. Tome tanta carga de apache como pueda. Apache es demasiado resistente para servir contenido estático de manera eficiente. Debería utilizar un proxy inverso más liviano (como squid) o un servidor web (lighttpd o nginx) para servir contenido estático y para encargarse de alimentar a los clientes con cucharones. Esto deja a Apache para hacer lo que mejor sabe hacer: ejecutar tu código. Nuevamente, el libro mod_perl hace un buen trabajo de explaining this.

Una vez que ha llegado hasta aquí, en gran medida es un problema de almacenamiento en caché más, y vigilando su base de datos. Eventualmente, superarás un solo servidor. En primer lugar, probablemente agregará más cuadros frontales, todos respaldados por un solo servidor de base de datos. Entonces vas a tener que empezar a repartir la carga de tu base de datos, probablemente por fragmentación. Para obtener una descripción general excelente de este proceso de crecimiento, consulte this livejournal presentation

Para obtener una visión más detallada de lo anterior, consulte Building Scalable Web Sites, de Cal Henderson, de la fama de Flickr. Google tiene portions of the book available for preview

Answer 8

Recomendaría el uso de Jet Profiler for MySQL para encontrar cualquier consulta incorrecta. Lo he usado con éxito en algunos de mis sitios. Realmente útil y mucho más fácil de digerir que el registro lento de consultas.