On 18 Mar 2008, at 14:08, Aschwin Wesselius wrote:
Per Jessen wrote:
header(location) mechanisms do come with a very huge disadvantage if
you don't use them with caution. Requests are reinitialised,
libraries
loaded (again), DB connections setup/checked again, session lookups
are being done, log write for another request etc. That's quite an
impact for just not knowing what to do with flow.
I'm having difficulties following you - a plain 303 redirect to a
"Thank
you" page shouldn't cause all of that. It's an HTTP reply with the
303
and the new URL, followed by a single URL request from the browser.
OK. I think I know how other people (like you) think about just
requesting URL's one after another. If that's not such a performance
issue for you, fine.
A plain 303 redirect mostly isn't just a HTML file, it's another
script (or the same script with another action falling through a
switch statement, whatever).
Point is: why hitting you webserver with multiple requests per user,
just after submitting a form or whatever caused the redirect? If you
have 2 users per day, that won't hurt. But if you have 30.000
concurrent users a minute, that could be 60.000 requests (besides
all the images, stylesheets, javascripts that are being re-
requested). Or am I talking nonsense?
What Per is saying is that you should be doing the minimum amount of
work possible to handle each request. If you have a shedload of code
that runs for every single page request regardless of what it's going
to do then your architecture sucks. If that is the case then avoiding
unnecessary bounces off the client is probably a good idea. If your
site is well-architected then redirects of this type will probably not
be a big performance drain.
One minor thing... a 303 redirect is permanent. In this situation you
want to use a 302 otherwise you could potentially cause problems with
proxies.
My opinion is that a redirect is the best way to prevent duplicate
posts. It prevents the user from getting the confusing popup and it
means you don't need to track whether a form has been posted yet. If
your application is well-architected you shouldn't need to worry about
performance.
-Stut
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
