La denegación de servicio y la sobrecarga de tráfico son dos cosas diferentes, por lo que usar un generador de tráfico no es realmente el camino a seguir. Los generadores de tráfico son geniales para modelar el uso de un recurso en el mundo real (por ejemplo, usuarios que llegan en forma aleatoria (distribución de Poisson), plantillas de navegación aleatorias o grabadas, búsquedas comunes y errores ...). La mayoría de los DDoS son poco más que GET / HTTP/1.0 , pero en lotes de trabajo. Grandes lotes de trabajo. Eso no es real "tráfico".
Si quieres ver qué sucede cuando el sistema obtiene DoSed y agota sus recursos, puedes, por ejemplo. deshabilite la protección semiabierta de SYN (cookies SYN) si está presente, y use alguna utilidad DoS para falsificar las conexiones de apertura. O mantén la conexión abierta a través de, por ejemplo, un script Perl.
O puede enviar solicitudes a esos puntos finales con una mayor carga del sistema (por ejemplo, que necesitan consultas en la base de datos).
Es probable que los datos mal formados sean interceptados en las capas externas del enrutador Django (si no es por el propio WSGI) y generen la menor carga. Depende de la malformación , por supuesto.
Disminuir la velocidad de envío debe estresar a Apache más que el resto de la pila (Django envía su salida en modo de fuego y olvido), mientras que las solicitudes de pulsos deben golpear a Django más fuerte, especialmente si están diseñadas contra más puntos finales caros.