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"
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.
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?
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