How to learn physical limits for a server ?
Hi All, First of all I want to congratulate your new year, Happ New Years.. I wonder where can I learn limits for a server ? I wonder whether there is a limit for concurrent tcp conne...
Forum Discussion
Hi Johny,
The problem is not in the fact that people don't want to share their results (though this is understandable as load testing is not a trivial activity), but in the fact their results are unique for them and their environment. Again, the situation is like with cars - it is possible to say that BMW can drive, for example, 210 km/h. But every BMW car should be tested if it can drive that fast and if it cannot, then it should be investigated for the reasons.
Likewise here: I think that nobody was interested in the question like 'how many packets can be transmissed by server's TCP stack per second?'. Instead, most probably, that people were looking for the answer on the question like 'can my system serve up to 3000 cuncurrent requests per second and provide responce within not more than 5 seconds?'. And if they found that the system cannot serve that many requests, then they investigated the reason and were thinking about how to solve the problem. And it is quite possible that they have more than one option for the solution. For example, if your software is not optimized, it is possible to spend resources for its optimization (which will increase the performance). Or it is possible to upgrade the hardware so it will compensate uneffective software.
I hope that you got the idea: define what you are going to measure; decide how you will measure; do a measurement; analyze results; figure out 'bottlenecks'; consider how these 'bottlenecks' can be eliminated.
The problem is not in the fact that people don't want to share their results (though this is understandable as load testing is not a trivial activity), but in the fact their results are unique for them and their environment. Again, the situation is like with cars - it is possible to say that BMW can drive, for example, 210 km/h. But every BMW car should be tested if it can drive that fast and if it cannot, then it should be investigated for the reasons.
Likewise here: I think that nobody was interested in the question like 'how many packets can be transmissed by server's TCP stack per second?'. Instead, most probably, that people were looking for the answer on the question like 'can my system serve up to 3000 cuncurrent requests per second and provide responce within not more than 5 seconds?'. And if they found that the system cannot serve that many requests, then they investigated the reason and were thinking about how to solve the problem. And it is quite possible that they have more than one option for the solution. For example, if your software is not optimized, it is possible to spend resources for its optimization (which will increase the performance). Or it is possible to upgrade the hardware so it will compensate uneffective software.
I hope that you got the idea: define what you are going to measure; decide how you will measure; do a measurement; analyze results; figure out 'bottlenecks'; consider how these 'bottlenecks' can be eliminated.