On a web application, I am currently working on for a client, we discussed implementing the redirect after post pattern. The web framework in action is Struts 1.2.
During the discussion performance was brought up as a problem for implementing redirect after post. I haven't thought of before that redirecting after a post could be a performance issue...?
Well you do double the number of requests per client since the server asks the client to redirect. With 400 concurrent users posting that would end up in 800 requests. A problem? Maybe, but you do need to have the scalability in your application.
This potentially performance issue needs to be evaluated against the benefits of using the pattern since you can avoid some nasty situations for example where users a refreshing a page or using the back button.
So anybody out there having any experience or other comments about this subject? Anybody done some analysis of the consequences of actually implementing the redirect after post pattern? Your comments would be much appreciated.
6 comments:
I'd say the impact is negligent. The additional usability gained by doing redirect after post far outweights any impact doing a server round trip causes. Remember that the redirect response requires virtually no cpu or network overhead, we're only talking about network latency that the user sees.
I do agree with you (Anonymous). The only overhead I can think of (besides the network latency) is that the server needs to start up a new thread to serve the redirect request instead of just forwarding.
(lost) performance should not be the factor that makes you not implement redirect after post. GETs should be safe, POSTs not. Do the redirect!
For each unsafe HTTP operation (like POST), yes, there will be an additional GET request. At worst, this will double the amount of requests.
Doubling the amount of requests are not even close to an order of magnitude loss of performance (or extra work to do). You should already have a scaling plan ready, that can scale you into at least an order of magnitude extra requests.
Redirect after post has never produced any performance issue in my experience. Performance issue come up more when your program is bad written (for example without using the redirect after post) and you have to trick in the code to make your app work properly.
The first comment meant to use the word "negligible". Just in case anyone was worried that the impact of redirect after post might be legally liable.
In the spirit of Yahoo's series of articles on latency and perceived performance, I'd say that, yes, a new request is a noticeable performance hit that will have an effect on both bandwith and perceived performance.
That said, I still agree with the rest of the commenters that it's better than the alternative.
Post a Comment