Al considerar el uso de contadores de rendimiento como el sitio basado en .NET de mis empresas, me preguntaba qué tan grande es la sobrecarga de usarlos.¿Cuál es el impacto en el rendimiento de los Contadores de rendimiento
¿Quiero que mi sitio actualice continuamente sus contadores o me conviene solo hacerlo cuando mido?
El impacto en el rendimiento es insignificante en la actualización. La intención de Microsoft es que siempre escriba en los contadores de rendimiento. Es la supervisión de (o la captura de) esos contadores de rendimiento lo que provocará una degradación del rendimiento. Entonces, solo cuando utilizas algo como perfmon para capturar los datos.
En efecto, los objetos del contador de rendimiento tendrán el efecto de "hacerlo solo cuando midas".
Lo que he encontrado es que no es tan lento para la mayoría de las aplicaciones. No pondría uno en un círculo cerrado, o algo que se llama miles de veces por segundo.
En segundo lugar, descubrí que crear contadores de rendimiento programáticamente es muy lento, así que asegúrese de crearlos antes de la mano y no en el código.
Estoy de acuerdo con famoushamsandwich, pero agregaría que siempre que su frecuencia de muestreo sea razonable (5 segundos o más) y monitoree un conjunto razonable de contadores, entonces el impacto de la medición también es insignificante (en la mayoría de los casos) .
Un contador de rendimiento es solo un puntero a 4/8 bytes en la memoria compartida (también conocido como archivo mapeado en memoria), por lo que su costo es muy similar al de acceder a una variante int/larga.
La sobrecarga de la configuración de los contadores de rendimiento generalmente no es lo suficientemente alta como para preocuparse (configuración de una región de memoria compartida y algunos objetos .NET, junto con la sobrecarga de CLR porque CLR realmente hace la gestión por usted). Aquí me refiero a clases como PerformanceCounter.
La sobrecarga de registrar los contadores de rendimiento puede ser decentemente lenta, pero en general no es una preocupación porque se pretende que ocurra una vez en el tiempo de configuración porque quiere cambiar el estado de toda la máquina. Será eclipsado por cualquier copia que hagas. En general, no es algo que quieras hacer en tiempo de ejecución. Aquí me refiero a PerformanceCounterInstaller.
La sobrecarga de actualizar un contador de rendimiento generalmente se reduce al costo de realizar una operación de enclavamiento en la memoria compartida. Esto es más lento que el acceso a la memoria normal, pero es una primitiva del procesador (así es como se obtienen operaciones atómicas en todo el subsistema de memoria, incluidas las cachés). En general, este costo no es alto de qué preocuparse. Podría ser 10 veces más una operación de memoria normal, posiblemente peor dependiendo de la actualización y de la competencia entre subprocesos y CPU. Pero considere esto, es literalmente imposible hacer algo mejor que las operaciones entrelazadas para la comunicación entre procesos con actualizaciones atómicas, y no se mantienen bloqueos. Aquí me refiero a PerformanceCounter.Increment y métodos similares.
La sobrecarga de leer un contador de rendimiento generalmente es una lectura de la memoria compartida. Como han dicho otros, desea muestrear en un período razonable (al igual que cualquier otro muestreo), pero solo piense en PerfMon y trate de mantener el muestreo en una escala humana (piense segundos en vez de milisegundos) y probablemente no tendrá ningún problemas.
Finalmente, una apelación a la experiencia: los contadores de rendimiento son tan livianos que se usan en todas partes en Windows, desde el kernel hasta los controladores y las aplicaciones del usuario. Microsoft confía en ellos internamente.
Asesoramiento: La verdadera pregunta con contadores de rendimiento es la curva de aprendizaje en la comprensión (que es moderada) y una medición de las cosas correctas (parece fácil pero a menudo te equivocas).
He probado esto MUCHO.
En una antigua máquina compaq 1Ghz 1, pude crear aproximadamente 10,000 contadores y monitorearlos remotamente para un uso de CPU de aproximadamente 20%. Estos no son contadores personalizados, solo revisan CPU o lo que sea.
Básicamente, puede controlar todos los contadores en cualquier máquina más nueva decente con muy poco impacto.
La instanciación del objeto puede llevar mucho tiempo de unos pocos segundos a unos minutos. Te sugiero que multipliques esto por todos los contadores que recolectes; de lo contrario, tu aplicación se quedará ahí para siempre creando estos objetos. No estoy seguro de qué es lo que hace MS una vez que lo creas, sino que puedes hacerlo por 1000 contadores con 1000 hilos en el mismo tiempo que puedes hacerlo por 1 contador y 1 hilo.
Gracias. ¿Puede, por casualidad, señalarme algunos números? Tengo curiosidad sobre lo bien que lo obtuvieron ... – Boaz
Nunca lo he visto demostrado, pero no tengo motivos para dudarlo. Sería simple probar en una aplicación. – dpurrington
Hola dpurrington. Al decir "es la supervisión ... que causará una degradación del rendimiento", ¿quiere decir que la degradación se verá en el proceso que actualiza/publica los contadores o por el proceso que los está monitoreando? – urig