Try installing Firebug and watching the console; OJS 2.4.6 has more external dependencies (e.g.Google’s CDN) and perhaps there’s an occasional delay fetching those.
Regards,
Alec Smecher
Public Knowledge Project Team
First time loading it with Chromium in Ubuntu took me 19 seconds to see anything.
Then if I open it again, the page opens in less than a second.
Reproduced with Firefox also. So I think the fast loading is related to browser cache. Follow Alec’s suggestion using the developer toolbar to find out what’s halting the loading so much.
Actually, Chrome’s developer tools are better than Firebug (IMO) for debugging performance problems in subrequests; they include a handy timeline showing the loading process. If you can duplicate the slow loading in Chrome, I’d suggest using that.
Regards,
Alec Smecher
Public Knowledge Project Team
CDN was disabled in the URLs that I sent to you in first time… and didn’t show any performance variations.
Please, take a look at this timeline (that as I said it happens randomly and only the first time I hit the page):
Browser takes 18 seconds to do… nothing!!?
What annoys me is that I’m not able to resolve where is the problem: client/server cache, network, iptables/firewalls, firefox bug with compressed files… whatever.
As far as Bruno reproduced the issue with Chromium, will try to hunt the lack… and analyze Chrome timeline, that as alec says is more detailed than firebug.
I will take a detailed look to my logs… just in case there is any clue there.
Thanks you both for your help!!
Please, let me know if you have any idea… never mind how crazy.
I’m more or less at same place here… the only difference is that after few hours of testing I was lucky to catch he issue once with Chrome and a little bit more info was revealed.
So that’s the issue: Still no pattern, but sometimes and some files are “stalled” during 10 to 20 seconds and overall performance is a crap.
What it’s wired is the issue appears much more in Firefox, than in Chrome.
And much more with 304 resources than 200 petitions.
And in the same server, it never happens to us with 2.3.6 branch.
And apache error log is clean.
Google define “stalls” as:
Stalled/Blocking: Time the request spent waiting before it could be sent.
This time is inclusive of any time spent in proxy negotiation. Additionally, this
time will include when the browser is waiting for an already established
connection to become available for re-use, obeying Chrome’s maximum six
TCP connection per origin rule.
I have few theories here:
a) KeepAlive issue? I disabled it and looks like the problem is still there.
b) Too much files & connections? Is there any recommended way to join CSS and JS in 2.x branch?
c) Network issue? Log is clean, but my be it’s related with iptables/bounding/networkcard issue?
Probably not, but check if your server is sending a Content-Length header (occasionally?) with your 304s. That will cause issues depending on the upstream hops or the ultimate UA.
Just in case could be useful for others… shrinking to a few possible causes:
a) DNS problems: The DNS server is not in my hands, but fails randomly. Trying with the secondary DNS as primary now does the trick.
b) Big htaccess: In my case, with 35 journals and clean urls, this file is around 700 lines (and is checked on every hit). Still thinking in a good alternative to htaccess.
c) ipv6: Looks like systems are introducing ipv6 in the housing segment. It could cause issues… so I disabled ipv6 till the migration is finished.
