In our case, it's not the initial load that was killing us... well, it
*was* a little too long (and we have a very nice Please Wait with
spinning gears and such during that period)... the problem is the
underlying requirements for the application. Let me try and give a
brief background (although you've been around here long enough and seen
my posts to know I can't say *anything* briefly!)
The app is a back-office replacement for a number of different apps...
things like CRM, account creation, workflow, imaging system, etc. Each
of these is sort of a separate module in the app. Each module further
has a left and right-hand sides, the left-hand side has a variable
number of tabs on it, each loaded individually, and the right-hand side
typically has an image viewing applet in it, although sometimes has
other things like search results, more data entry forms, etc.
The one requirement that's really been tough is that each of these
modules the user needs to be able to flip between at any time with no
real delay (at least no delay after the first time they load the
module). So, a typical use case might be creating a new account in the
new account module, and then being able to flip to the image view module
to see the image of the scanned documentation for the new account
application.
The way we did this, the only way we could to really meet the
requirements I think, is that we have a bunch of common JS that loads
up-front, which basically represents the overarching client-side
framework. Then, each module is in an iFrame, but within each there's a
ton of stuff that has to get loaded, some of it duplicate portions of
the framework (although that's been minimized of course), and including
Dojo in each one. For the most part, once a module is loaded it doesn't
fully get loaded again, we just flip one iFrame visible while the others
are hidden, that sort of thing. But there *are* a few instances where a
module has to get reloaded.
Now, here's the part that really spurned the need to improve
performance... we have an existing VB-based imaging application that
we're not ready to move off of completely... this imaging app has the
full suite of hooks into the workflow, the long and short of it is that
from the VB app, a user clicks a button when they select a work item
from a queue, which launches our web app. So, the initial load of the
web app is maybe 5-7 seconds, not a big deal. Then to load the module
that automatically gets started in that case takes about 8-10 seconds.
Then it has to load an image in an applet, which is another few seconds.
All in all it's roughly 20 seconds from fat-client to webapp loaded.
But, before the mods this past week, it was more like 45-50 seconds,
sometimes more (I think we actually managed to get it closer to 10-15
seconds overall on Friday, getting us to around that 70% improvement I
mentioned, give or take a bit).
You actually see that please wait display when the module is loading
too, and from fat-client to webapp it's actually showing the whole time.
Before the mods, you can see why Dojo was a problem: it wasn't just
loading once, it was loading multiple times! And because of the
fundamental architecture of the app, there wasn't much choice in the
matter (I've toyed with just loading it in the parent frame, but that
doesn't seem possible since the iFrames need a lot of it, and you start
getting into tons of scoping issues).
I should also point out that one of the other changes I made that had a
big impact was not using Dojo buttons any longer... I basically built a
new button widget and wrapped it in a taglib. The problem there was
that each of those tabs I mentioned gets loaded via AJAX, and then any
<script> blocks in it is executed. When we disabled the Dojo widget
parsing, we lost the ability to use markup to generate Dojo buttons, so
I created a very thin taglib wrapper that spit out a <script> block to
programmatically generate the Dojo button. This, it turns out, executes
a lot faster than the widget parsing (I should also mention we're using
Dojo 0.3.1 because it would be a major hassle to upgrade now)... the
problem, which I'd bet you can guess, is that if you have a tab with
numerous buttons, which we did in some cases, executing all that
Javascript and manipulating the DOM (creating the Dojo buttons) wound up
being as slow as using widget parsing, maybe even slower.
So now, the button widget and taglib I created doesn't spit out
Javascript, the buttons are a lot simpler, and don't need to be created
programmatically. This gained us 3-5 seconds alone.
Ok, see, I'm genetically incapable of giving a short answer to anything
:) To answer your question, the initial load *is* long enough to
warrant a please wait message, and we have one, and actually have from
the start :)
Frank
Adam Hardy wrote:
Frank W. Zammetti on 28/07/07 16:10, wrote:
Martin Gainty wrote:
-where you able to collect metrics for scenarios other than expire
headers of 1 hour..perhaps 2 hours?
No, we debated various times but settled on one hour because that
seemed a reasonable period of time to account for JS changes (our own
app JS really)... we figured images weren't terribly important if
something changed, we could deal with a bit of ugliness for an hour :)
but JS changes would obviously break stuff.
Interesting approach. Is the first-time load actually long enough to
consider putting in a message on the browser window saying 'Please wait
for a moment while application initialises...' or similar? Or is that
initial load time quick enough anyway?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
