Pregunta

Soy bastante nuevo en el desarrollo de .NET en general. Me gustaría hacer algunos instrumentos en mi aplicación web para ajustar el rendimiento, especialmente en relación con el almacenamiento en caché. He escrito muchos UserControls personalizados generados dinámicamente que me gustaría probar el almacenamiento en caché de diferentes maneras, posiblemente por declaración de página ASPX o mediante programación.

También tengo muchas consultas de Oracle que dependen unas de otras y me gustaría analizar los resultados de almacenamiento en caché de esas para ver qué ofrecerá las mejores ganancias de rendimiento.

¿Cuál sería la mejor manera de hacer esto? De alguna manera, no creo que usar un cronómetro para ver cuánto tiempo tarda IE en cargar la página es la mejor idea. No tendré idea de si mi almacenamiento en caché está siendo golpeado o fallado, aparte del retraso percibido. ¿VS2008 tiene herramientas integradas para ayudar?

¿Fue útil?

Solución

Un proyecto en el que trabajé recientemente necesitaba verificar los tiempos de nuestras consultas SQL y enviarlas al oyente de depuración en modo de depuración. De esta forma, podríamos evaluar los tiempos de las consultas SQL y cuánto tiempo tardaron en ejecutarse, así como depurar el código de nuestro sitio web.

Hice esto al centralizar las consultas SQL en un método contenedor para los 3 tipos de métodos SQL que utilizamos:

  • ExecuteQuery
  • ExecuteNonQuery
  • ExecuteScalar

Utilizaron la clase Cronómetro, pero también había código para transformar la consulta en una declaración SQL, similar a la que se ve en SQL Server Profiler.

Cada método fue similar al siguiente:

protected static object ExecuteScalar(SqlCommand comm, SqlParameter[] sqlParameters)
{
    Stopwatch st = new Stopwatch();
    bool errorDetected = false;

    try
    {
         comm.Parameters.Add(sqlParameters);

         using(comm)
         {
              st.Start();
              object returnValue = comm.ExecuteScalar();
              st.Stop();
              return returnValue;
         }
    }
    catch(Exception)
    {
         errorDetected = true;
         st.Stop();
         throw;
    }
    finally
    {
         string output = GetSqlStringForParameters(sqlParameters,st.Elapsed,QueryType.Scalar);

         if(errorDetected)
         {
              Debug.WriteLine("/*SQL (Errored)*/" + output,"DataAccess.SqlAdapter.ExecuteScalar");
         }
         else
         {
              Debug.WriteLine("/*SQL*/" + output,"DataAccess.SqlAdapter.ExecuteScalar");
         }
    } 
}

Esto generaría nuestras declaraciones SQL en DebugView.exe de esta manera:

/*SQL*/ exec spsGetOrder @OrderNumber='234567' -- Rows returned = 1 ;  1 params |--> completed NonQuery in 0.0016144 seconds. 

La belleza de esto es que, aunque sí, hay un cuello de botella para estas declaraciones, podemos pegar la consulta directamente en el generador de perfiles SQL y obtener el resultado de la consulta. También significa que si tiene una herramienta para ver los archivos de registro, puede usar expresiones regulares para controlar dónde el tiempo necesario es de cierto rango.

Entonces, si desea buscar consultas que demoren más de 0,5 segundos, puede buscar el término:

" en 0. [5-9] \ d + " < - Todo más grande que 0.5 segundos o " en [1-9]. \ d + " < - Todo más grande que 1 segundo

Esto nos ha ayudado a centrar nuestros esfuerzos inmensamente. También nos ayuda a identificar si un problema está relacionado con la base de datos, o según lo dispuesto anteriormente, un problema de ASP.NET.

Finalmente, hay una herramienta llamada Fiddler que también puede ayudarlo a diagnosticar páginas a medida que llegan a su computadora . Esto le brinda información como el tamaño del archivo, referencias a imágenes / CSS, tiempos de descarga. Esto también es muy útil para diagnosticar problemas de tamaño de ViewState.

Espero que esto ayude

Otros consejos

La forma en que generalmente abordo esto es habilitando el seguimiento de ASP.NET. Hay una guía bastante buena para habilitar esto aquí . Es bastante detallado y lo mejor de todo es gratis.

Una cosa en la que enfocarse es en el tamaño de la página (especialmente su estado de vista), que es una parte importante de cuánto tiempo demora la página en descargarse una vez que el código se ha ejecutado. La otra es qué tan rápido se procesan ciertas partes del código que se pueden lograr haciendo llamadas a Trace.Write antes y después del código que se está probando.

La parte de prueba de rendimiento del uso del rastreo de ASP.NET es realmente solo una guía, ya que no es fácilmente repetible, pero no obstante es una buena. Si desea intensificarlo, hay herramientas en Visual Studio 2008 Team System que podrían ser mejores (aunque no las he usado). También hay JetBrains dotTrace y ANTS Profiler .

AppDynamics es un muy buen monitor de rendimiento de aplicaciones, que puede instrumentar sus aplicaciones .NET sin configuración. Creo que Will podría resolver su problema con esa herramienta. http://www.appdynamics.com/

He tenido muy buenas experiencias con New Relic . Instalación muy simple, tablero extremadamente claro en su sitio, y si se aloja en Rackspace o Amazon Clouds, generalmente ofrecen actualizaciones gratuitas a las cuentas Pro. ¡Compruébalo!

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top