performance - son - tipos de responsabilidades del contador publico
¿Cuál es el impacto en el rendimiento de los contadores de rendimiento? (6)
Al considerar el uso de contadores de rendimiento como el sitio basado en .NET de mis compañías, me preguntaba qué tan grande es la sobrecarga de usarlos.
¿Quiero que mi sitio actualice continuamente sus contadores o me conviene que solo lo haga cuando mida?
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 solo "hacerlo cuando se mide".
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 (la 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 rentabilidad puede ser decentemente lenta, pero en general no es una preocupación, ya que está previsto que ocurra una vez en el momento de la 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 enclavada 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 de los usuarios. Microsoft confía en ellos internamente.
Consejo: La verdadera pregunta con contadores de rendimiento es la curva de aprendizaje en la comprensión (que es moderada) y una que mide las cosas correctas (parece fácil pero a menudo te equivocas).
He probado esto MUCHO.
En una antigua máquina compaq de 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, puedes monitorear todos los contadores en cualquier máquina nueva y 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.
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).
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 la creación programática de contadores de rendimiento es muy lenta, así que asegúrese de crearlos antes de la mano y no en el código.