Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Scenario

After an integration of our product with a site that have a "decent" number of request, development team of that site ask me to prove that our server can handle traffic generated from that site to our site, by doing a "stress test" before let us to be certificated.

We tried two different solutions, developing our code; call "server 1" the server (could be more than one, but we don't care) of our future partner and "server X - server Y" our two server. DB is onto "server Y"

First solution

All calls are managed by "server X" that, with xmlrpc protocol, forwards calls to "server Y" that have a python daemon process running that will be executed and use multithreading. This test failed.

Second solution

All calls are directly managed by "server Y" (httpd accept them) and a python process will be created for every apache process created. This test failed.

In both test, CPU(s) reach 70-80 % of use and load avarage is something between 7-10

Our server are CentOS and have 3 core(*)

Taking into account several things:

  • With "no stress", our code will be executed in less than a second (logged it)
  • We can't do some load balancing as we can't buy more server

What improvement can we do for unload server? Any ideas?

edit

idempotence Imdempotence means that an operation can be applied multiple times without changing the result. GET and PUT HTTP request are expected to be idempotent whereas POST requests are not. In other words, you can not cache POST HTTP responses.

from varnish book. So it seems that I can't use cache methods as someone suggested me :(


(*) Before those tests, we used to have only 2 core so we have already enanched that number. Obviously we can mount even 4 cores, but I suppose that this will not make any difference

share

migration rejected from superuser.com Sep 18 '13 at 20:06

This question came from our site for computer enthusiasts and power users. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as off-topic by mdpc, Ward, MadHatter, TheCleaner, Falcon Momot Sep 18 '13 at 20:06

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions must be relevant to professional system administration. Server Fault is a site dedicated to professionals; novice questions are off-topic. Please see the Help Center for more information on topicality. The best advice we can give you is to hire a professional to help you out." – mdpc, Ward, MadHatter, TheCleaner
If this question can be reworded to fit the rules in the help center, please edit the question.

    
I hate to be that guy, but could it be that the underlying software itself is crap? Its obviously falling over under load, and no amount of magic would fix that. –  Journeyman Geek Sep 17 '13 at 14:28
    
in the end, since you can't buy or build more capacity, all you can do is optimize the server config and code, so not much you can do on your end. a load that high is going to spell trouble in the long term. –  Frank Thomas Sep 17 '13 at 14:33
    
@JourneymanGeek: Maybe but I don't think this is the case. I mean, with no stress code running efficently (read it as: we analyzed that, cleaned it up and tested it: it runs in less than a second [remember that is a webapp]) –  DonCallisto Sep 17 '13 at 14:36
1  
In short, your server is doing fine when things are unrealistically perfect - that dosen't mean the issue isn't with your python app.. My first thought was trying another lightweight web server but something just doesn't smell right here. –  Journeyman Geek Sep 17 '13 at 14:38
1  
Can you use some heavy caching for your app? Are you using any kind of caching? With cache, I mean something like varnish. –  Janne Pikkarainen Sep 17 '13 at 14:51
show 13 more comments