Hi Frank,
First of all thanks for these tips.., we did the custom dojo build and
parseWidget tag setting also. but we havent done the 2nd and 3rd tips
you have given here., i have a small doubt when it comes to moving
static resource to the web server. will there be any problem when it
comes to having http and https content together? i don't have much
experience when it comes to web servers like apache
Thanks,
Nuwan
Frank W. Zammetti wrote:
I have a very complex app using Dojo that just went live a few weeks
ago (although *not* using S2), and this past week we got a 70+%
performance improvement out of it. We did three things Dojo-related.
First, we used a custom build (previously we just let Dojo import
whatever it needed on the fly). I know this is a primary suggestion
the Dojo team makes, so I assume you've done that already. Second,
all the Dojo resources, all the .js, .css and image files, were moved
onto the web server. Third, we set expires headers for all these
resources to one hour on Apache.
None of that is rocket science, but it made an absolutely amazing
difference. We're under SSL as well, and our performance right now is
on par with what a developer sees running it locally without SSL.
It's absolutely stunning.
We actually moved *all* our static resources out to the web server (we
use other libraries like ActiveWidgets, WiseBlocks and have a ton of
.js that makes up the app itself). We also made some other
architectural changes, so the improvement we saw isn't strictly what
we did with Dojo. But, myself and another senior guy spent all week
measuring and benchmarking and testing and I can say for sure that the
biggest improvement was in fact the Dojo changes.
hth,
Frank
Nuwan Chandrasoma wrote:
Hi,
we also had the similar problem, we had a s1.x application with dojo
and we did all the performance enhancements that was recommended by
dojo, but we could not achive what we want and our application was
running in https mode. it add more performance problem to the
application.
Thanks,
Nuwan
Adam Hardy wrote:
Jason Wyatt on 27/07/07 08:55, wrote:
I've been trying to speed up the Ajax performance of our
application, based
on the notes at http://cwiki.apache.org/WW/performance-tuning.html
I'm a bit unsure where I should extract the static content to, such
as the
css and javascript files included by the Ajax theme (shown below):
<link rel="stylesheet" href="/iacd/struts/xhtml/styles.css"
type="text/css"/>
<script type="text/javascript"
src="/iacd/struts/dojo/dojo.js"></script>
<script type="text/javascript"
src="/iacd/struts/simple/dojoRequire.js"></script>
<script type="text/javascript"
src="/iacd/struts/ajax/dojoRequire.js"></script>
<script type="text/javascript"
src="/iacd/struts/CommonFunctions.js"></script>
For example, the styles.css file above is stored in the
struts2-core-2.0.8.jar under the path /template/xhtml.
But if I extract this file to the webroot/template/xhtml, it seems
that the
link in the code above won't work, so I should instead extract it to
webroot/struts/xhtml.
Is this understanding correct? Basically I'm wondering how the
mapping works
between the template folder in the jar file and the struts folders
mentioned
in the Ajax theme's code.
Looks like a servlet filter declared in the web.xml would pick up
anything with /struts/* and handle it from there but I don't see it
mentioned in a casual check of the wiki so it could be some other
mechanism.
I spent about a week trying to get dojo to perform better the way we
were using it, and for the performance we required then, we worked
out we couldn't afford any more than a dozen dojo widgets on a page,
even with all the dojo performance enhancements recommended by dojo.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
