Hice un sitio web Asp.net MVC y lo alojé en un proveedor de alojamiento compartido. Como mi sitio web rodea una idea muy genérica, podría tener varios usuarios concurrentes en algún momento en el futuro.
Entonces, estaba pensando en una forma de probar el rendimiento de mi sitio web en carga. Como cómo funcionará el sitio cuando 100 o 1000 usuarios estén en línea al mismo tiempo y naveguen por el sitio web. Esto también me hará comprender si mis consultas LINQ están bien escritas o no.
Respuestas:
En primer lugar, el término adecuado es prueba de esfuerzo . Hay bastantes soluciones para las pruebas de estrés del sitio web, una solución alojada que recomendaría es loadimpact . Lo que hacen es bombardear su sitio con solicitudes de varios servidores en todo el mundo y brindarle un informe analítico de cómo su sitio manejó el estrés. Tienen una prueba gratuita, donde puede obtener una idea general, pero para más tendrá que pagar una tarifa de suscripción.
Este tipo de pruebas sólo probar el sitio web de los visitantes punto de vista, para obtener más información específica que debe perfilar su aplicación a nivel local, y yo no tengo nada más que añadir a las respuestas anteriores, estoy usando jmeter así .
Y, por último, como cualquier desarrollador web consciente del rendimiento, debe echar un vistazo a YSlow :
YSlow analiza el rendimiento de la página web examinando todos los componentes de la página, incluidos los componentes creados dinámicamente mediante JavaScript. Mide el rendimiento de la página y ofrece sugerencias de mejora.
YSlow for Firefox está integrado en la herramienta de desarrollo web Firebug para Firefox.
La mayoría de las veces, encuentro que Javascript es el cuello de botella real y no el código de fondo o la base de datos. Por supuesto, las consultas mal escritas pueden ser una gran penalización de rendimiento, pero después de tratarlas, siempre ejecute YSlow y siga sus sugerencias, es un salvavidas.
Otras lecturas:
en StackOverflow, por supuesto!
Está en un alojamiento compartido, por lo que es poco probable que pueda ejecutar pruebas que sean indicativas del rendimiento, ya que no hay garantía del nivel de recursos a los que su aplicación tendrá acceso en cualquier momento.
Sin embargo, lo que haría en esa situación es comenzar ejecutando una prueba aislada en una caja dedicada (esta puede ser su propia computadora portátil); use una herramienta como el conjunto de pruebas de carga de Visual Studio o JMeter (que personalmente no puedo soportar), y cree un conjunto de pruebas que represente una ruta típica a través de su aplicación (debe poder obtener información sobre una ruta típica a través del uso de Google Analytics. Si esto no está disponible, puede usar uno que considere probable, pero recuerde que esto no proporcionará una línea de base tan precisa). Luego haga una prueba de aceleración, comience con 1 usuario, luego agregue usuarios lentamente hasta alcanzar su carga máxima estimada. Eso debería mostrarle qué tan bien se sostiene su sistema en su conjunto (personalmente me gusta llevarlo un poco más lejos para asegurarme de que tengo algo de margen).
Lo último que querrá hacer es ejecutar una herramienta de creación de perfiles como ANTS performance profiler mientras ejecuta la prueba (tenga en cuenta que esto agrega algo de sobrecarga). Esto le permitirá identificar consultas y métodos de larga duración, lo que le dará sugerencias sobre dónde su aplicación es realmente lenta (un consejo: casi nunca es realmente donde cree que estará).
El problema principal que tendrá es, como dije antes, que está en un alojamiento compartido, por lo que será casi imposible hacer una emulación realista del entorno en vivo. Sin embargo, si su aplicación tiene una cantidad decente de espacio libre en un entorno similar a sus recursos prometidos, debe tener cierta confianza en que el código puede mantenerse en su alojamiento, incluso si alcanza los límites de su entorno antes de lo esperado.
Puede buscar herramientas como JMeter o The Grinder .
Solo he usado JMeter hasta ahora, es una herramienta gráfica que le permite crear planes de prueba con bastante facilidad. Puede simular múltiples usuarios con múltiples hilos. También puede registrar los usos típicos de su sitio al vincular su navegador con un proxy JMeter y hacer el trabajo real, por lo que no necesita escribir las solicitudes desde cero. El Grinder está basado en script si recuerdo bien, también podría ser una buena opción.
También me gusta Loadimpact para pruebas de estrés. Una cosa que tiendo a usar para verificaciones rápidas en mi sitio es Apache Bench. Cuando quiera realizar algunas pruebas finales, buscaré un servicio de pago.
Mi trabajo también invirtió en WebLoads, que es muy costoso pero nos permite probar todos nuestros sitios internamente. Aunque no lo recomiendo.
Un script de Autohotkey (AHK) puede simular un usuario humano. Déjalo correr todo el día.
Puede dejar que se ejecute en varios cuadros para simular algunos usuarios. Lo bueno es que el estilo de prueba está completamente bajo su control. Puede tener 1 script AHK enviando spam a una función de informe y ver si afecta a los usuarios de otras funciones.
Aunque no estoy familiarizado con las capacidades de enhebrado de AHK, simular a miles de usuarios podría ser difícil. Puede estar obligado por la cantidad de computadoras que tiene.