ahsnl-py / br-server Goto Github PK

docker build -t br-serve-img .

docker run -d --name br-container -p 80:80 br-serve-img

pytest

The load test of the server application was done with ApacheBenchmark. The server was hosted locally using a docker container. So, connection time on average is almost 0. On the other hand, the Timeout test is the ab timeout default value which is 30 seconds. RPS is the Request per seconds which measures the throughput of the server. I have set no worker for the first benchmark testing. This is to get an idea how single threaded proxy handle heavy load request. As we could see that the as we increase the concurrency value the average time taken for request also increase significantly. This is also proven by the signigicant jump of time taken per request for two consecutive test of 1000 requests (1 worker) at 100 and 200 each concurrently, it takes 59 to 400 seconds to complete respectively. Still, request per second remain comparatively reasonable, averaging 2,3 s regardless of increasing load.

In summary, there is a definite correlation between increasing of thread worker and RPS. For each worker increase, the RPS increase by 1-2 seconds. The most intersting finding is how the average Time per request-2 which is account for the number of concurrent connections remain relatively stable during heavy load work. We could use this information to handle high traffic of request during a busy session of the application by increasing the number of workers and reduce back to normal when traffic is normal. In addition, looking at the resource of my OS during the test, it seems under heavy load, the CPU and memory only spike during the final termination of each concurrent request and remain stable if not request is terminated or reaches timeout. Ideally speaking, it would be better to test the server remotely and having a second remote connection in private network where I could measure the latency such as connection time (it was measured 0 across different config) and all the necessary load without the effect of local hardware resources allocation. For now, I could limit my core up to 4 worker. Each worker can only handle 100 concurrent request per thread before the server side application completely shutdown.