HTTP POST or GET
January 27th, 2009
Some time ago I made a little test comparing web services performance using HTTP GET and POST methods. I used the same script, in the same environment with the same web service. HTTP method was the only difference.
I discovered that POST method is twice much faster than request sent using GET method.
You should also know that request size with GET method can be limited, although RFC2616 says:
The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs.
So if you are planning some web services performance testing or you want to speed up your tests a little bit before customer demo
you should consider POST HTTP method.

Hmmm. Interesting experiment. What was the software stack the web service was running on?
I would argue that a GET request that contains a body is malformed. Section 9.3 of RFC 2616 says that GET data should be in the Request-URI.
I am surprised that your web service even accepts a GET request with a body, even if it is much slower. I just tried it with a web service running on ASP.NET 2.0.50727, and the request is not accepted as a web servie call.
Cheers,
Stuart.
Stuart
You are right. My server (Java, Jax-WS) doesn’t accept GET requests as well. I realized that I made a mistake :/ It’s throwing 404 and thats why performance is better, agrrrr…
I need to delete this stupid post.
Thanks for catching it.
Waldemar
But it is also interesting that an HTTP 404 response is much slower than a web service response.
I find that a lot of websites have missing resources on pages that developers refuse to fix because it is not visible to an end-user. Maybe there are performance implications under heavy load.
Also, there is probably a lesson in there somewhere about always putting in web_reg_finds for every request.
I am enjoying reading your blog. Keep up the interesting posts.
Cheers,
Stuart.