no estoy de acuerdo con Nathan y Freddy en algún grado. Tienen razón en que "las pruebas AJAX" no difieren en absoluto en que se realizan las solicitudes HTTP. Pero no es tan simple. Ver mi artículo en Ajaxian.com en Why Load Testing Ajax is Hard.
JMeter, Pylot y The Grinder son todas excelentes herramientas para generar solicitudes HTTP (yo personalmente recomiendo Pylot). Pero en esencia, no actúan como un navegador y procesan JavaScript, lo que significa que todo lo que hacen es reproducir el tráfico que vieron en un tiempo récord. Si esas solicitudes AJAX fueron exclusivas de esa sesión, es posible que no sean adecuadas/correctas para reproducirlas en grandes volúmenes.
El hecho es que a medida que se introduce más lógica en el navegador, se vuelve mucho más difícil (si no imposible) simular correctamente el tráfico con las herramientas tradicionales de prueba de carga.
En mi artículo, doy un ejemplo simple de lo difícil que es probar algo como la página de inicio de Google cuando desea consultar 1000 de diferentes términos de búsqueda (un objetivo importante durante la prueba de carga).Para hacerlo con JMeter/Pylot/Grinder terminas reescribiendo partes del código AJAX (en tu caso con jQuery) de nuevo en el idioma nativo de la herramienta.
Se vuelve aún más complejo si su objetivo es medir el tiempo de respuesta tal como lo percibe el usuario (lo cual es posiblemente lo más importante al final del día). Para aplicaciones realmente complejas que usan Comet/"Reverse Ajax" (una técnica que mantiene receptáculos abiertos durante largos períodos de tiempo), las herramientas de carga tradicionales no funcionan en absoluto.
Mi empresa, BrowserMob, proporciona una load testing service que utiliza los navegadores Firefox, impulsado por Selenium, para conducir cientos o miles de navegadores reales, que le permite medir el tiempo y el rendimiento de los elementos visuales como se ve en el navegador. También admitimos usuarios virtuales tradicionales (tráfico HTTP oculto) y un navegador simulado (a través del HtmlUnit).
Dicho todo esto, generalmente una combinación de un servicio como BrowserMob más pruebas de carga tradicional es el enfoque correcto. Es decir, los navegadores reales son geniales para una prueba de carga de fidelidad completa, pero nunca serán tan económicos como los "usuarios virtuales", ya que requieren de 10 a 100 veces más RAM y CPU. Ver mi publicación de blog reciente sobre si simulate or not to simulate virtual users.
Espero que ayude!