How to learn physical limits for a server ?

Hi,



This question is similar to the questions you asked here.



See our answer in that thread. Also, in the future, do not send us duplicated requests (note that we reply to messages sent via the Contact Support form, AutomatedQA forums and the TestComplete section of the SQAforums site). This makes processing your requests much more difficult for us and does not increase the requests priority anyway.

Hi Jared,

Actually I do not think this is a dublicate, if so I wouldn't ask.On that page I asked about  web application, capacity and usage of a web application and servers. But in this post, I am only asking just for solely servers physical limits. I wonder the maximum limits for oncurrent TCP connection for spesific kinds of service like windows server 2008 R2. I wonder where can I learn it from. I also wonder how much CPU workload can a server handle like that one.

Hi Johny,



> I am only asking just for solely servers physical limits.

Sorry if I missed something, but for me your question sounds like "how speedy an engine can make a car?". Obviously, this depends on how well the engine itself is tuned, what gear-box is used, what is the aerodynamic quality of the body, etc.

Likewise, the server limits obviously depend on its hardware.

TCP is just a transmission protocol that is useless without a consumer and the obtained packet will be thrown away by OS if not processed by this consumer. This makes it obvious that the limits depend on the software. The limits will be higher if you have only server's core with a ping service, but will be lower if the server also handles other services and GUI.

That is why I would agree with Jared that, like in the mentioned thread, you must elaborate the *unambiguous and measurable* requirements first and than consider how and what to measure.

Hi Alex,



I know the server limits obviously depend on its hardware, I can also give hardware configuration. As in the case for TestComplete vuser that a computer can use max 300 vuser,  I thought that at last there are some max connection numbers for different types of servers.



In a page from sqa forum, a guy has written problem with 200 vuser testing. And somebody has written him that, maybe it a bandwith problem or something other. If he try 100 and 100 vuser at two different computer at the same, maybe the problem will fade out.



I mean, these cases show that how much is your hardware powerfull, there is a limit for outgoing request from a physical machine.



The same thing here, there must be some physical limits for connections or request, regardless of the hardware power or whatever application running.



And the other issue, I will elaborate the unnecessary requirements than I ask again, but ı see people are unwilliingly share their spesific experiences.

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.