Cómo encontrar cuellos de botella de rendimiento en el código de C++

Question

Tengo una aplicación de servidor escrita en C++ e implementada en Cent OS. No he escrito ninguna parte de su código, pero necesito optimizar su rendimiento. Su rendimiento actual es aceptable para una pequeña cantidad de usuarios, pero cuando aumenta el número de usuarios, el rendimiento del servidor disminuye drásticamente.

¿Existen herramientas, técnicas o mejores prácticas para descubrir los cuellos de botella?

Answer 1

Las personas generalmente usan perfiladores para determinar los cuellos de botella de rendimiento. Anteriormente, las preguntas de SO que pedían perfiles de C++ son here y here (según el sistema operativo y el compilador que utilice). Para Linux, las personas generalmente usan gprof, simplemente porque viene con el sistema.

Answer 2

Vas a empezar por la construcción de un entorno de prueba de rendimiento si no tiene uno de hardware Producción grado

• . Si no tiene el presupuesto para esto, puede darse por vencido.
• Programa (s) de controlador o dispositivos de hardware que generan un tráfico parecido a la producción a gran velocidad, tan rápido o más rápido que la producción. Dependiendo de su protocolo y caso de uso, esto puede ser fácil o difícil. Una técnica es muestrear algunas solicitudes de producción y reproducirlas, pero esto puede dar resultados poco realistas, ya que dará mayores tasas de aciertos de caché.
• infraestructura circundante como similar a la producción a medida que razonablemente puede obtener

A continuación, reproducir el problema, tal como existe en la producción. Una vez que hayas hecho eso, utiliza un generador de perfiles, etc., como otros han sugerido.

Answer 3

This works, without fail.

Answer 4

me gusta, la respuesta de Mike Dunlavey anterior (por lo Uptick su si usted mina de repunte)

me gustaría elaborar para alguien con prisa con dos métodos:

• Una forma rápida para que los usuarios de gcc muestreen en ese gstack
• auto inspección con SIGALRM combinado con backtrace (manejado por su propio t imer). Hace

---

Sólo unos días hice algo como esto

# while true; do gstack $MYPID; sleep 2; done | logger $PARAMS 

usando PARAMS que van con mis reglas de enrutamiento de syslog para que mis registros de aplicaciones se entremezclan con las pilas (no es una perfecta línea- al día con los eventos)

los resultados fueron en la nariz, que me señaló a un área que pensé que podría ser un problema en absoluto, sino fuera mi cuello de botella debido a misuse of reference in a tr1::bind

En el método de alarma, tenga cuidado con lo que hace en la señal, no use nada que asigne memoria (sin cout/cerr/boost, y use formatos simples (p. "% 08X" con printf)