EML site is too slow from IE at hospital computers

[Tarek Loubani]

JD reports, and I can confirm, that the page loads ridiculously slowly from IE on hospital computers. to the point that it is essentially unusable. This is especially detrimental when members are trying to look through schedules.

I haven't done a page-load analysis on it, but I expect that the javascript and css goodness are partly to blame - e.g., the fading in main page.

I'll look at it and report back here.

[Andrew Jones (jonesmd)]

I had never noticed the fade thing until you mentioned it. Its gone. I had not turned on some of the optimizations yet either (as they were messing with my local apache install) - they are now on. I have cut my own load times by 1.2s (a huge amount in web-time as you know)

I suspect the problem largely has to do with

1) The hospitals ancient firewall system - I have probed/scanned it before to see exactly what it was tracking and its logging and it is checking EVERYTHING bouncing it off some sort of internal router before sending it out - try loading even a page like google.com (fast server/simple page) at work = waaaaay slower than it should be.

2) The most current version of IE at the hospital is sadly IE7 - almost as non-standards compliant as IE6 (no HTML5, no CSS3, poor/slow JS implementation). Not to mention the fact that a fair number of thin clients are still running IE6. (The LHSC IT guy in charge of software maintenance never got back to me).

I can work on building essentially a "text-only" version when it detects IE6/IE7 or I think I can even get it to detect the hosp IP range. I'll throw it onto the ever-growing list.

[Tarek Loubani (tareko)]

My latest load time is 6.63s.

I notice that it gets back two complex 404's for:

http://emlondon.ca/components/com_jdownloads/lightbox/loading.gif

and

http://emlondon.ca/components/com_jdownloads/lightbox/close.gif

I created links to both of those locations by doing:

ln -s components/com_jdownloads/assets/lightbox components/com_jdownloads/lightbox

The new page load time is still the same. It looks like the worst offender for delaying the page load at this point is a get of crossdomain.xml from youtube.com

I'm not sure what to do about this. I'll investigate later.

[Tarek Loubani (tareko)]

http://forum.joomla.org/viewtopic.php?f=433&t=326990

This might help the large number of calls. again, will investigate this eve

[Tarek Loubani (tareko)]

I just enabled the cache plugin from extension manager. Still no improvement in times

[Tarek Loubani (tareko)]

Aha!! Just enabled cache from global config > system, and now page loads are at 500ms!!

[Andrew Jones (jonesmd)]

Enabling the global cache breaks a couple of extensions, including the
calendar. Despite it's name, it actually doesn't speed up page loading at
all.

On Tuesday, December 13, 2011, Tarek Loubani <email address hidden>
wrote:
> I just enabled the cache plugin from extension manager. Still no
> improvement in times
>
> --
> You received this bug notification because you are a member of EM London
> team, which is a bug assignee.
> https://bugs.launchpad.net/bugs/903468
>
> Title:
> EML site is too slow from IE at hospital computers
>
> Status in Emergency Medicine London (Ontario):
> Confirmed
>
> Bug description:
> JD reports, and I can confirm, that the page loads ridiculously slowly
> from IE on hospital computers. to the point that it is essentially
> unusable. This is especially detrimental when members are trying to
> look through schedules.
>
> I haven't done a page-load analysis on it, but I expect that the
> javascript and css goodness are partly to blame - e.g., the fading in
> main page.
>
> I'll look at it and report back here.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/emlondon/+bug/903468/+subscriptions
>

[Tarek Loubani (tareko)]

Regarding the cache plugin, it not only broke the calendar, but actually made the front page non-functioning on IE 7! However, with the cache plugin disabled and the cache function enabled (global settings > cache), load time drops to about 1s, and it still loads where necessary. Probably this is the best compromise here.

[Andrew Jones (jonesmd)]

I'm not sure about the timing if when you did whatever and when I did what
I did, but my load times are now pretty good at home but are still abysmal
at the hospital.

I don't know if you noticed but I replaced the global cache with a 3rd
party (completely free/open) plugin. That may account for some of the
performance improvement.

I had to work out if town the last couple of days but I plan on getting
back to work on things today. I'll send you a note later.

AEJ
 On Dec 14, 2011 1:01 AM, "Tarek Loubani" <email address hidden> wrote:

> Regarding the cache plugin, it not only broke the calendar, but actually
> made the front page non-functioning on IE 7! However, with the cache
> plugin disabled and the cache function enabled (global settings >
> cache), load time drops to about 1s, and it still loads where necessary.
> Probably this is the best compromise here.
>
> --
> You received this bug notification because you are a member of EM London
> team, which is a bug assignee.
> https://bugs.launchpad.net/bugs/903468
>
> Title:
> EML site is too slow from IE at hospital computers
>
> Status in Emergency Medicine London (Ontario):
> Confirmed
>
> Bug description:
> JD reports, and I can confirm, that the page loads ridiculously slowly
> from IE on hospital computers. to the point that it is essentially
> unusable. This is especially detrimental when members are trying to
> look through schedules.
>
> I haven't done a page-load analysis on it, but I expect that the
> javascript and css goodness are partly to blame - e.g., the fading in
> main page.
>
> I'll look at it and report back here.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/emlondon/+bug/903468/+subscriptions
>

[Tarek Loubani (tareko)]

Currently, total load time with the main page is 9 seconds, and 3.65 seconds with the minimal theme.

To test this yourself, install firebug, open it on a particular page. enable "net", then reload while watching.

The last related manipulation I made was to disable cache when the menu problem cropped up related to cache. For now, I won't touch the site until I finish my testing suite for it, since that will give more confidence in making changes like this without breaking the whole thing.

[Andrew Jones (jonesmd)]

9 seconds sounds unreasonable... Don't you think?

BTW - is it OK for me to modify the CSS of KAS directly on the server? I
haven't had a chance to setup the github thing on my system yet. Also,
related to KAS - is the plan eventually to integrate your login with that
of the site? If I had any idea how to do this I would give it a go, but it
would involve writing code from scratch (I suspect) and right now my brain
is incapable of that. People have been asking why they have to login
twice...

On Sunday, December 18, 2011, Tarek Loubani <email address hidden>
wrote:
> Currently, total load time with the main page is 9 seconds, and 3.65
> seconds with the minimal theme.
>
> To test this yourself, install firebug, open it on a particular page.
> enable "net", then reload while watching.
>
> The last related manipulation I made was to disable cache when the menu
> problem cropped up related to cache. For now, I won't touch the site
> until I finish my testing suite for it, since that will give more
> confidence in making changes like this without breaking the whole thing.
>
> --
> You received this bug notification because you are a member of EM London
> team, which is a bug assignee.
> https://bugs.launchpad.net/bugs/903468
>
> Title:
> EML site is too slow from IE at hospital computers
>
> Status in Emergency Medicine London (Ontario):
> Confirmed
>
> Bug description:
> JD reports, and I can confirm, that the page loads ridiculously slowly
> from IE on hospital computers. to the point that it is essentially
> unusable. This is especially detrimental when members are trying to
> look through schedules.
>
> I haven't done a page-load analysis on it, but I expect that the
> javascript and css goodness are partly to blame - e.g., the fading in
> main page.
>
> I'll look at it and report back here.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/emlondon/+bug/903468/+subscriptions
>

[Tarek Loubani (tareko)]

Re 9 second load times: Yes, that is unreasonable. The times cut to 1s with caching enabled, but that breaks menus.

For now, I am not making any changes to the site until I finish setting up the complete testing suite. This is in progress, but slow-going right now. Once that is setup, then we can really feel comfortable making all kinds of changes. This is set as Bug #905749. Feel free to comment there on anything else you'd like to see or to suggest alternative test suites.

For Kitab modification, see Bug #906113. In short, I'm not particularly interested in trying to maintain an untracked codebase, and as it stands now, all modifications to the production code get overwritten when it's updated from the git branch. Truly, all modifications should be made and committed against git.

For sessions, see Bug #906114.