Pregunta

He escrito una implementación de servidor TCP usando la cual creé una aplicación que funciona como servicio de eco TCP.

Ahora quiero probar este servidor de eco en términos de

  • Cuántas conexiones puede manejar
  • ¿Cuál es el tiempo de respuesta?
  • Cuánta memoria y CPU usa

¿Puede sugerir algún método / herramienta estándar para probar este servidor de eco? Entiendo que tanto la implementación del servidor TCP como la del servidor echo son una práctica bastante estándar, así que espero encontrar herramientas establecidas para probarla.

P.S .: puedo escribir mi propia aplicación de prueba pero no quiero hacerlo porque si veo algún problema, necesito asegurarme de que es mi servidor el que lo está haciendo mal. No quiero terminar probando mi cliente de prueba primero.

Escribí esta implementación usando C # y .NET 3.5 aunque creo que no importa con referencia a la pregunta.

¿Fue útil?

Solución

Tengo una herramienta gratuita que podría ayudarte. Lo uso para probar servidores que están construidos con mi marco de servidor C ++. La herramienta está disponible aquí: http: // www. lenholgate.com/blog/2005/11/windows-tcpip-server-performance.html . Le permite crear un número configurable de conexiones a su servidor de destino a una velocidad configurable y luego enviar datos en cada conexión (nuevamente a una velocidad configurable).

Si encuentra que la mejor manera de usarlo es ejecutarlo en una máquina diferente al servidor (bastante obvio, lo sé, pero ...) y posiblemente ejecutar múltiples copias en varias máquinas diferentes. Tenga en cuenta que si descubre que no puede realizar más de alrededor de 4000 conexiones, es muy probable que necesite modificar su configuración de registro MAX_USER_PORT en la máquina que ejecuta el cliente.

Una vez que haya probado su código TCP, es posible que necesite probar el protocolo que admite su servidor. Escribí una herramienta de prueba para este tipo de situación en C # que está disponible en CodeProject ( http: //www.codeproject.com/KB/IP/testingsocketservers.aspx ). Esto le permite escribir un " plugin " para admitir su protocolo y manejar las cosas agnósticas del protocolo (muchas conexiones, romper mensajes para que obtenga lecturas fragmentadas, etc.) para usted. El diseño es un diseño bastante desagradable de subproceso por conexión y para un mayor número de conexiones sería mejor reimplementar algo usando un diseño asíncrono, pero tengo mis herramientas C ++ para eso, así que nunca pude cambiar este programa de prueba. .

Otros consejos

En su misma situación antes, he usado FunkLoad. Si puede escribir un cliente pequeño como un fragmento de código Python, entonces FunkLoad ejecutará tantos de ellos como desee en el servidor y graficará los resultados:

https://funkload.nuxeo.org/

Un ejemplo completamente resuelto contra una serie de servidores de prueba es la pieza central de la segunda edición de mi libro Foundations of Python Network Programming, en caso de que su repositorio de código fuente público sea de alguna ayuda:

https://github.com/brandon-rhodes/fopnp/ árbol / m / py2 / chapter07

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