https and javascript caching

ZCSForumTH · Post by **ZCSForumTH** » Tue Oct 04, 2005 1:20 pm

After a bit a struggle, I have Zimbra integrated into my SuSE 9.3 installation. It looks like a great product, thank you to the Zimbra team for providing this software.
I have been testing internally and everything looks fine. So, now I want to allow external access to my Zimbra server over the internet over SSL (https). This was fairly straight forward to setup. The issue I have now is that accessing the site is unbearably slow, the login process takes a good 1.5 - 2 minutes. After login is complete, everything runs smoothly. With SSL turned off, the very first time I access the site I get the very long login time but all subsequent logins are very fast.
What I think is happening is that with SSL turned on, the browser is not caching the javascript for the Zimbra client and it gets delivered to the browser everytime you access the site for the first time after staring the browser. Running in mixed mode seems to solve this but all your data is sent over the internet without encryption (except for your login/password).
Has anyone else experienced this behaviour or is there something that I'm missing in my configuration.
Thanks,

Tom
BTW, I have been testing with Firefox v1.0.7

14319KevinH · Post by **14319KevinH** » Tue Oct 04, 2005 1:27 pm

Looks like you've completed the first port to a non Red Hat/Fedora distro. Congrats! Did you install from source or did you use one of the binary builds?
On the caching issue you right. I've also noticed that in SSL mode the browser doesn't cache across browser restarts. Assuming your on a fast connection it shouldn't bee too big of a problem. What's the network speed between your browser and the server?

ZCSForumTH · Post by **ZCSForumTH** » Tue Oct 04, 2005 5:35 pm

Thanks for the quick response KevinH.
I have a Cable connection on the server end and an ADSL on the client end. So, my upload rates are not that great at both ends. It takes 20 secs for the login page to be displayed plus another then 1 minute 50 sec before your inbox is displayed. From the access log, it looks like it is transfering 265 javascript files weighing in at a total of 3.5megs plus some css and images.
I guess mixed mode is probably my best bet right now.
Is there a way to have the javascript/images/css delivered over http but have all to Ajax SOAP calls go encrypted over https?
>

As for my installation, yes, I did do the dev-install (from source). However, I am only using postfix and the Zimbra webapps that it installs. For the other components, I just integrated with my current SuSE packages: mysql 4.1.10a, openldap2 2.2.23, apache2 2.0.53, mod_jk 4.1.30. I have the Zimbra WebClient fronted with Apache to serve up all the static content (javascript, css, gif, png, etc.) and use mod_jk to proxy all servlet request to tomcat 5.5.7 running the zimbra, zimbraAdmin, and service webapps.
- Tom

14319KevinH · Post by **14319KevinH** » Tue Oct 04, 2005 5:52 pm

Tom,
The issue is your running a "dev" build; in this mode each Javascript source file is sent to the browser uncompressed. In a "prod" build we compress all the Javascript into two files and gzip it. In that case the entire app is less than 500k.
Assuming you've still got the source you can just run "ant prod-deploy" in ZimbraWebClient and this will create and deploy a production build with full compression. This is the 'zimbra' webapp.

ZCSForumTH · Post by **ZCSForumTH** » Tue Oct 04, 2005 6:46 pm

Hey KevinH, YOU'RE THE MAN

I knew it must of been me doing something wrong. I did the "prod-deploy", added "/zimbra/js/*.jgz" to my mod_jk proxies in Apache and it is working slick!!
It now takes ~10sec for the login page to load and ~20secs to load and display your Inbox -- SWEEEEEEEET

Thanks for your help...

Tom

rdargahi · Post by **rdargahi** » Tue Oct 04, 2005 10:53 pm

The next Zimbra milestone drop will aggregate the image files into a *much* smaller set of files. We had this running previously, but changed our image set and the way we were doing the image transformations and so didn't finish the work in time for release. We have now finished this work and have it running in-house for testing. The end result is that you still get all the visual richness of the client but downloaded in a much smaller set of files. This should help quite a bit with initial app download/startup.