[Seaside] Seaside redirects, really?

[Sebastian Sastre]

On Oct 3, 2011, at 4:46 PM, Norbert Hartl wrote:

> how did you measure those numbers? Did you have keep-alive active? 
> 
> With keep-alive there is only little more that is happening when doing this redirect scenario. One of the biggest latency factors is initiating a TCP connection. Most pages load quite a few images and such in parallel (today it is 4 concurrent connections or more). From that point the textual transfer of the form and the response shouldn't matter that much. With keep-alive especially that redirect scenario should be well supported. For everything else you need HTTP pipelining which is unfortunately still not used in todays browsers. 
> 
> Norbert 


yes, I confirm: this was with the keep-alive header. I'm not sure about the initiating socket thing, this should be confirmed but I guess that just making 2 DNS lookups instead of one is bad enough to eclipse that problem.

As said, it was just a quick look using the network tab in the dev tools

here is what you can do to reproduce what I did:
1. open chrome browser
2. open an image with a seaside app
3. open chrome developer tools (like inspecting an element a renderer page)
4. click on some actions and see the grey bar (method 302 Found type text/html)
5. for the experience, what matters most is the duration between the start of the 302 and the end of the 200. Take notes of those durations for various actions
6. close that image and open a copy you can hack with no risk
7. hack WAActionPhaseContinuation>>#shouldRedirect to shamelessly return false without further thinking
8. take notes of the numbers you get on the same duration (from start to end of the 200 response) for the same actions
9. compare
10. share results

sebastian

o/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20111003/87794bee/attachment-0001.htm