Milestone 2.2 With 3 containers and 5 containers
Summary:
| No of users | Duration | Success rate | Comment |
|---|---|---|---|
| 2500 | 10 | 23% | Application is unstable |
| 2708 | 100 | 96% | Application is stable |
| 5200 | 100 | 65% | Application was down for some time due to massive load |
Obs: With 1 pod/replica in the weather forecasting service for 500 users, the error was 7% but with 2 pods now our application can handle up to 2700 users with a 4% error rate. This is a massive improvement in terms of fault tolerance.
Summary:
| No of users | Duration | Success rate | Comment |
|---|---|---|---|
| 3000 | 10 | 33% | Application is unstable |
| 5746 | 100 | 98% | Application is stable |
| 7000 | 100 | 86% | Application was down for some time due to massive load but was relatively stable |
Obs: Now with 5 replicas the availability of the application is improved and now it can handle up to 5700 users with an error rate of just 2%. Again this is a significant improvement of Load by adding one replica.
The advantage of using Kubernetes as a was that it takes care of restarting a particular pod if there is a crash and re-routes the requests to other available pods in the service. No manual intervention is needed.
Summary:
| No of users | Duration | Success rate | Comment |
|---|---|---|---|
| 3000 | 100 | 100% | Application was stable for most of the time but became lagged a bit after a couple of minutes. |
| 6000 | 100 | 77% | Application was down for some time due to massive load |
Obs: For 3000 users the application was stable but for 6000 users in 100 seconds the application became fairly unstable.
Summary:
| No of users | Duration | Success rate | Comment |
|---|---|---|---|
| 6000 | 100 | 95% | Application was stable most of the time |
| 7000 | 100 | 60% | Applications was down for some time due to massive load |
Obs: For 6000 users the application was stable performed better than 3 pods.
Summary:
Stats:
When did Failed Transactions occur?
The application was able to handle load initially without any trouble. After a minute two pods were down and hence there was significant transactions that were lost during that time.
With an increased load to 3 pods, the failure rate of an HTTP request also increased.
Response rate:
Since there were many failures the response time for these transactions are increased.
What services got down?
It can be clearly for a significant amount of time there were failed transactions.
With 5 pods the performance was improved, the number of requests the service can handle is now close to 5700 in 100 seconds.
There were not many failed transactions here.
With further increasing the load out of 7048 samples 978 samples are failed.
In conclusion, From 1 pod to 3 pods to 5 pods the fault-tolerant capacity of the machine improved. Especially with 1 pod where there is a single point of failure the service could not handle much load.
6000 users in 100 seconds:
The error rate for 6000 users improved when the pods are 5.
- In all the cases increasing the number of pods improved the throughput of the application.
- Kubernetes eases out many things. It takes care of Routing, running pods, Service discovery, restarting failed pods, Load Balancer.