What is Slow

• initial page load
• loading/switching collections is slow
• switching between cal/list view is slow
• ...

Highest Priority: Initial Page Load

Initial Page Load

Hunches (i.e. what might be the problem)

• Drawing the UI
  • lots of document.element.byId lookups
  • ...
• Translation
  • XML Parsing
  • ...
• Model Layer
  • Expensive Date calls (toUTC, converting duration to endDate)
  • Just lots of method calls in general
• Network
  • lots of calls?
  • dojo.js is largish
• Interperting lots of Code

Gather Data

Environment

• all tests done on svn+ssh://svn.osafoundation.org/svn/server/cosmo/branches/uiperf/cosmo
• branch of trunk 5229
• using "built-out" dojo.js - meaning it is minified and all of our js code is in there, so resembles production system

Baseline Localhost:

Loading Dashboard, G5 Tower, localhost, default data, tomcat (no apache)

---

• <2 seconds
• 19 requests
• 291k
• dojo.js: 169k
• dashboard queries: 4 + 3 + 3 = 10k (3.33k/item)
• northamerica tz file: 32kb
• global.css: 15k
• i18n.js: 18kb

Loading Dashboard, G5 Tower, localhost, office calendar, tomcat (no apache)

---

• ~5 Seconds
• dashboard queries: 94k + 53k + 32k = 179k; 179k/59 items = 3k/item

Switching to Calendar G5 Tower, localhost, office calendar, tomcat (no apache)

---

• ~2 Seconds
• calendar queries: 72k/22 items = 3.27k/item

Saving Recurring event, update all, G5 Tower, localhost, office calendar, tomcat(no apache)

---

• ~2 Seconds
• 9k + 2k = 11k

The longest case took 5 seconds which is not (IMHO) unacceptable. Of course, this is all localhost so network issues (bandwidth, latency) is not being taken into account here. I will use Charles to see what performance in the wild might look like.

Charles in Charge

Cable Modem Simulation

• 1500Kbps
• 100% utilization
• 100ms Round Trip Latency
• 1500 MTU
• not a charles preset, from Jared
• caching headers stripped via Charles (no 304's)

Login Page

---

• 3.0s
• Notice that after dojo loads there is a largish time gap before the next request is made - about 300ms. I interpret that to be the javascript being evaluated and executed.
• Nothing is being loaded while dojo is being loaded. This is because all our requests for images are made in Javascript, so until there is JS which makes the request, those resources don't get loaded.
• Everything else gets loaded fairly serially, since there can only be two requests to the same host at a time. (note - the dark blue in the graph lines represent the time waiting before getting any response from the server)

---

Dashboard Page (seen right after logging in)

---

• 9.3s
• Same thing here with nothing happening while dojo is being loaded, and loading of static resources happening serially.
• The dashboard queries ( starts with "eim-json") are happening serially.
• There is a gap between requests of about 400ms after "northamerica" loads. I interpret this as meaning that the "northamerica" timezone file takes about that long to load.
• There is a gap of about 1s after "backward" loads. This is harder to interpret - it's almost certainly JS execution, but is it all the parsing of "backwards" or is it stuff that happens afterwards? Doubtful that it's all from tz parsing, since backward is a smallish file

---

Switch to Calendar view

• 3.0s
• Note that there is about a .5s wait time before getting any data back on the calendar query. Not sure if this is something to be concerned about, as my machine is not server-class and I am running Derby

---

---

Save a recurring event

• 635ms
• not much to note here.

---

---

Switch Back to List View

• 4.2s
• Again, the dashboard queries are serialized.

---

56k Model Simulation

• 57.6Kbps
• 70% utilization
• 250ms Round Trip Latency
• 576 MTU
• Charles preset
• caching headers stripped via Charles (no 304's)

Login Page

---

• 54s * yikes!
• for the dial-up user, resource size is everything!
• dojo.js takes 34s! but at least it gets cached

Conclusions

• Parallelizing where we can could help a lot. In the "Cable, Dashboard" scenario there was 5.35s of latency out of a total of 9s of page loading
• If Timezone parsing could be sped up, that would be a boon.
• The tz files are biggish. They could be gzipped by Apache, if they aren't already.
• For dialup users, this data suggests that the app is pretty unusable. Even if dojo.js get cached as it should, the Atom responses are still huge and would take too long to download. There are some things we can do to fix this: gzip the atom stuff, don't pretty print the xml, make the json format terser.
• I didn't do a full DSL report, but with the Charles preset DSL throttler on it takes 21 seconds to load the dashboard page
• The times reported in the Charles tests are just how long it takes till the last requested resource is downloaded - after that there still is JS work to do on the client side.

Next Steps

The lowest hanging/biggest pieces of low hanging fruit seem to be:

• parallelize dashboard requests
• gzip atom requests
• gzip timezone stuff
• minify Atom protocol (strip some unused envelope information)
• minify JSON format.

Somewhat harder, and of less obvious impact

• See how slow some of the more complicated client side code really is, in other words get some benchmarks for:
  • Client <--> Server translation
  • Timezone parsing
  • Rendering
• See what happens if you pre-load static resources before dojo loads
• Same as above but with multiple hosts

Harder still

• Experiment with dojo layered builds
  • minimize the amount of code that gets downloaded to login/admin/pim page
  • Figure out a way to layer the build so that enough code gets loaded into the page so that it makes the dashboard requests, then while that's happening loads more code so that code can be being downloaded at the same time that data is (another parallelization optimization)