Priest of the Order of the Butterfly
Posts: 874 from 2007/4/9
From: Kingston upon ...
Quote:
Fab wrote:
@boot_wb
1. It's not supposed to be fixed in 1.9 but in next version (assuming i got it right :)).
Ah, that explains it
Quote:
3. First, do you refer to a logged in state or not? If it's in a logged in state, it might greatly vary depending on your "Wall" content. :)
Yes, on further observation it is a logged in state. Apologies, I should have noticed that.
(Damn, wish I'd used a different example, I now feel like I've been outed as a Facebook whore
)
Quote:
I'll assume it was not the case, and i made the test when not connected (on 3 different MorphOS machines):
- It always takes 7-8s to load after starting browser. Stopping/Refreshing page doesn't change anything here. Of course, once it has been loaded once, refresh is much faster, since there's a page cache in OWB.
Anyway, during your 35s wait, check the connections: if they're in "connecting" mode (red led) for a very long time, it's clearly not OWB's responsability anymore. A red led means there hasn't been an answer to the HTTP request yet (because the site is still being resolved, or the TCP connection is not established yet, or that the server didn't send the HTTP response).
Thanks for the extra info. In the case I described, there are always the same two .css connections which take around 10-15 seconds to connect (ie lamp stays red).
It happens exactly the same each time under OWB, and can be circumvented by the stop/refresh method. This (to my mind) suggested that the delay is client-side, not server-side. But as you've explained, even if it is client-side, it could be due to many factors, not necessarily OWB.
(Musing: If the delay is server-side, could it be that the stop/refresh method causes cached .css files (from a previous session) to be used rather than downloading new copies (thus bypassing the delay)? Think I'll try flushing the cache, and see if this prevents stop/refresh from speeding up the process.)
Quote:
For fun, i tried with ibrowse, and it took 6s most of the time, except once, where it took 30s (the first connection stayed more than 20s in DNS resolution state). To be noted Ibrowse doesn't even load all the resources (like css, some pictures, ...), so it should be faster than that, compared to OWB.
So, as you can see, it's not easy to make an opinion on this, considering all the external factors (TCP stack, LAN, router, router->ISP, ...).
Well many thanks for taking the time to test, I do appreciate that. It seemed such a simple (and repeatable) issue, but I see there is more complexity (even just on the client-side) which could be the cause than I first realised.
Best Regards
Rich
www.hullchimneyservices.co.uk
UI: Powerbook 5,6 (1.67GHz, 128MB VRam): OS3.1, OSX 10.5.8
HTPC: Mac Mini G4 (1,5GHz, 64MB VRam): OS3.1 (ZVNC)
Audiophile: Efika 5200b (SB Audigy): OS3.1 (VNC + Virtual Monitor)
Windows free since 2011!
