In producing a web-based data entry system, is the fact that you are adding an extra server request per page a significant concern when deciding whether or not to use a post/redirect/get design?
A:
Most of the time, posts only happen when data is changed. The most traffic and CPU time on sites is generated by queries (GETS) rather than changes, so I think these extra requests aren't very significant.
Jeroen Landheer
2009-12-16 19:37:06
+4
A:
Yes, but not simply for performance reason.
If you have load-balancing and database replication, you have to ensure that GET after POST will actually see the data that has been posted, so you have to configure load balancer to redirect users to your "master" webiste or the exact same machine that received POST (depending how you've implemented storage).
The request alone isn't a problem, especially that alternative gives pretty bad user experience and may result in even more superflous requests than simple redirect.
porneL
2009-12-16 19:37:24
Another option is to use database mirroring instead of replication, and memcached for caching. Then it doesn't matter which front end the user gets redirected to.
Jesse Weigert
2009-12-16 19:40:14
Thanks for the additional things to think about!
Wes
2009-12-16 19:43:29
A:
If I understand your question (and I'm not entirely sure I do), it is definitely good design to do a redirect after a post, even if you are showing them the same page with the updated info.
By doing the redirect you are breaking the connection between the page being viewed and the POST which caused the change. The user can bookmark and/or refresh the page without any popup asking "Do you want to resend the data?"
Peter Rowell
2009-12-16 19:37:35
A:
I think the usability that this offers outweighs the small performance hit.
Jesse Weigert
2009-12-16 19:37:46
A:
Test it out by performing some performance benchmarks and you will be able to see if it is going to be a concern in your particular case. See this article for more information.
David Glass
2009-12-16 19:38:12