ab es un poco molesto si su sitio necesita cookies, etc. ab es demasiado simple.
Básicamente, según mi experiencia en la reparación de varios sitios web PHP implosionados, por lo general es así:
1) La gente usa MySQL
Puedes usar totalmente MySQL, facebook y flickr hazlo (a los fanáticos de mysql les encantan) SI CONOCES LOS GOTCHAS que son:
- Si tiene una tabla MyISAM que no es de solo lectura y cualquier consulta de más de 100 us (incluso selecciones), está muerto
En un sitio que arreglé, el tipo había alquilado un servidor de doble núcleo cuádruple porque "su sitio necesita energía". Miro su sitio, miro mi sitio anterior con> 100 000 miembros y un rastreador de torrents que se ejecutaba en un servidor Via C7 micro-half-pizzabox, y le digo que su sitio funciona bien en el Celeron 300 que está en mi sótano. , y eso es incluso excesivo, te lo puedo alquilar por la mitad del precio de tu Xeon, lol.
Resultó que el tipo era un buen desarrollador y un tipo realmente agradable, pero apestaba en MySQL, por lo que su sitio tenía la típica consulta de búsqueda del infierno que puede matar a cualquier sitio web:
- 10 consultas de búsqueda infernales por segundo (tenía como 300 000 miembros en su sitio warez ilegal)
- la consulta de búsqueda del infierno tarda entre 0,1 y 0,2 segundos
- una pequeña corriente de actualizaciones simultáneas a la misma tabla MyISAM para animar las cosas
=> serialización total (bloqueos de escritura MyISAM) de todas las consultas. 1 núcleo 100 %, 7 núcleos inactivos, carga media> 1000 (sí, estaba usando apache), tiempos de página> 30 segundos, funciona.
La solución fue fácil:optimice la consulta de búsqueda desde el infierno, corrija el punto 2) a continuación, cambie a InnoDB, cambie a lighttpd. loadavg cayó a 0.02
2) ACTUALIZACIONES
A nadie le interesan los contadores de páginas. Emita 1 ACTUALIZACIÓN por cada vista de página y estará muerto. Agregue un poco de MyISAM para obtener más efectos. También es un asesino en InnoDB, no se trata de bloquear, sino de sincronizar las esperas de E/S del disco.
3) TEXTO COMPLETO
- MyISAM no se puede usar para tablas de lectura y escritura debido al bloqueo.
- MyISAM es tan confiable como un ramdisk (de hecho, menos:necesita un bloqueo del sistema operativo para corromper un ramdisk, corromper las tablas de MyISAM solo necesita un bloqueo de MySQL o simplemente presionarlo demasiado al mismo tiempo, obtendrá "motor de tabla desconocido error", vi esto muchas veces)
- FULLTEXT no disponible en InnoDB
- Cualquier inserción en un índice FULLTEXT desencadena casi una reconstrucción completa del índice (cuando inserté una publicación en el foro, estaba reconstruyendo 400 MB de índice)
==> Si necesita indexación de texto completo, rendimiento y confiabilidad, use Sphinx o Xapian.
No probé Sphinx (la gente dice cosas buenas sobre él), pero Xapian felizmente busca a través de 4 GB de texto en un instante.
4) La gente usa apache.
Esto combina muy bien con los puntos anteriores.
A diferencia de un servidor adecuado como lighttpd, cuyo uso de la CPU es indetectable (el pésimo Via C7 estaba sirviendo 100 hits HTTP/s y lighttpd usaba menos del 1% de la CPU), apache matará su caja.
Cuando MySQL comienza a morir (muere fácilmente), los clientes comienzan a presionar F5 con fuerza, y pronto tiene alrededor de 1000 procesos de Apache, cada uno con un intérprete de PHP, y cada intérprete de PHP tiene una conexión MySQL inactiva, esperando un bloqueo MyISAM, excepto uno, que está haciendo una ACTUALIZACIÓN trivial de su contador de vistas de página, pero eso lleva algo de tiempo, porque el servidor se ha ido a almorzar intercambiando, debido a los procesos 1000 apache y 1000 php y 1000 mysql.
Lighttpd no usa CPU para páginas estáticas. La única forma de que lighttpd sature su CPU es si lo golpea con fuerza con apachebench a unas 20K solicitudes/s. Luego, Lighttpd habla con algunos, como 10 backends php-fcgi (2-4 por núcleo es bueno) que hablan con algunas conexiones MySQL. Como resultado, todo es mucho más rápido y, cuando se sobrecarga, se degrada con gracia, no de forma explosiva.
Para llegar a la pregunta original, definitivamente desea perfilar sus consultas SQL. Agregue un registro de consultas a su aplicación PHP que muestre (solo para usted) la lista de consultas y el tiempo que toman, y también el tiempo desde el inicio del script PHP hasta su finalización (los encabezados/pies de página son un buen lugar para esto).
Para una página compleja (excluyendo la búsqueda), esperaría aproximadamente 3 ms MySQL y 3 ms PHP, ese es un buen objetivo. Por supuesto, necesita un caché de código compilado de PHP.
Para la carga actual, hay un par de cosas que puede hacer. Las respuestas más caras, pero más detalladas, se proporcionarán a través de una aplicación empresarial como "Gomez".
Sin embargo, si está buscando hacer esto usted mismo, vea mis respuestas anteriores a continuación o use utilidades de shell como:htop, top, w, y utilice Apache server-status
Respuestas anteriores antes de la revisión de la pregunta:
Lo que solicita a veces se denomina creación de perfiles de aplicaciones.
Debe crear una fórmula de memoria aproximada como:
httpd ram + uso de memoria php + uso de proceso mysql =huella total de memoria de solicitud
También necesitará una fórmula de CPU, pero también puede observar la parte superior durante una prueba de carga.
Apache tiene el comando 'ab'.
"ab es una herramienta para evaluar comparativamente su servidor Apache Hypertext Transfer Protocol (HTTP). Está diseñado para darle una idea de cómo funciona su instalación actual de Apache. Esto le muestra especialmente cuántas solicitudes por segundo su instalación de Apache es capaz de atender. " http://httpd.apache.org/docs/2.0/programs/ab.html
Aquí hay una línea de comando de referencia genérica 'ab':
ab -n 10 -c 1 http://www.yoursite.com/
# qty 10 total requests, 1 request at a time
La estrategia es probar la carga por proceso (usuario) en su aplicación desde la solicitud de la página web hasta su finalización. Si puede identificar la cantidad de RAM que utiliza Apache, PHP y MySQL para cada solicitud, entonces puede identificar rápidamente la capacidad de su sistema.
Probablemente tendrá que usar una combinación de herramientas de diagnóstico como vmstat o top o iostat o ps, etc. para tomar una instantánea de lo que demandará una cantidad de solicitudes de su sistema.
Finalmente, querrá instalar Xdebug. Esta herramienta lo ayudará a perfilar el lado php de la aplicación.http://xdebug.org/
Aquí está el tutorial de IBM sobre la instalación de Xdebug:
http://www.ibm.com/developerworks/opensource/library/os-php-fastapps2/