Skip Navigation

Troubleshooting Poor Performance of a Client's Ext-based Application

The other week I delivered an Ext-based application to a customer. Shortly after they were in touch to say that it was slow. Although an application that relies on >500KB of JavaScript is never going to be super-fast it shouldn't be taking 10 seconds to open each new tab within the application, which is what they were experiencing.

Delays in the region of 10s to open a page make an application almost useless as most users just won't wait that long for stuff to happen. Needless to say I set about trying to work out why it was happening.

From the off the problem appeared to be "their side". Performance on the server I'd been developing was as good as you'd expect from an Ext-based application. Resisting the temptation to simply say "Works fine here!"  (hey, I'm a pro, I'd never say that to a paying customer) I got the customer to log the browser-server transactions, so I could take a closer look. Not having access to their servers meant I couldn't debug it directly.

To record the HTTP transaction log I had them install the free Basic Edition of HttpWatch. All they had to do then was start recording, open the application, open a new form, open a new document, edit the document, save the document etc and then stop recording. The result is a .HWL file which I can then open in my version of HttpWatch's "Studio". I can then see all headers, response code and the amount of time taken for all transactions involved.

On opening the the HWL file it was almost immediately obvious there was a problem. Here's a view of the transactions involved:

ScreenShot001

Notice the Result column. This shows the HTTP status code returned. A code of 200 means everything was "ok". This is "ok" but not what we'd expect to see for all transactions. Especially on subsequent requests for the same resource. What we'd expect is a code of 304 which tells the browser it hasn't changed and it can use the local cached copy instead. Because this isn't happening the cache is never used and so it runs unacceptably slowly.

Why is it doing this though?

Drilling down in to each individual transaction I noticed something common to them all. For each GET request the server was returning a Cache-Control header of no-cache.

ScreenShot002

While we expect this for certain URLs, such as those ending in ?OpenAgent or ?OpenForm, we certainly wouldn't expect it of requests for files ending in CSS, JS or GIF. The image above shows a request for a JS file which is 500KB in size. You definitely want something like that cached browser-side!

What could be causing this?

As far as I know the only way for this to happen would be if a developer or administrator had previously added a Web Site Rule to the server's directory which looked something like this:

ScreenShot003

The effect of applying this rule, which I verified by testing on my own server (following a restart), is that the server tells the browser not to cache anything from it.

While I imagine this might have solved whatever problems the developer was having with caching at the time it has - in turn - created other problems, as they're finding now.

It should go without saying, but I'll say it anyway -- never ever use a system-wide configuration change like this as a quick fix to a problem you're having. If you do then you at least need to be mindful of any adverse effects on other applications.

My advise to the customer was that the only real solution was to remove the rule. Although, as I warned them, this could then "break" any systems that have been developed with it in place.

An alternative would be to add subsequent Rules which tell the browser to using caching if the URL ends in *.js etc and hope that it trumps the Rule already in place.

Comment Icon 4 Comments Read - Add | Mon 8 Sep 2008 | Open »

Roll Your Own Domino Search Engine

The subject of searching multiple Domino websites came up yesterday when Martin Scott's "Super Search" was mentioned. While it's a useful resource it's very outdated (and annoying if you don't realise it's going to spawn a whole load of new windows). Times have moved on and there are more elegant ways of searching multiple (related) websites at once.

One such way is to use a service like Rollyo.com, which lets you list the domains for which you want results returned. Here's a page which lets you search a small subset of the Domino sites out there:

http://rollyo.com/jakehowl/domino_sites/

There's a link on that page that will let you add the search engine to your browser's search field, which you can also do for codestore using the instruction on the search form.

Or you can do a search from this form, which you could embed on your own site:


Rollyo uses Yahoo search (I think). Like everybody else (or so it seems) I'd rather use Google to do the searching. Unsurprisingly they offer their own way of restriciting search results to certain domains, called Google Coop.

There's already a Google custom search for Lotus Domino:

http://www.google.com/coop/cse?cx=008231444553199791783:dql4bnwwnf8

You can test it using the form below. Oddly there's no way to add it to your browser's search feature. It could be hacked but I'll only do that if one of you ask me to.

So, there you have it. There are at least two ways you can easily search just Domino sites. That way can do a search safe in the knowledge you won't be following dead ends to results from sites like Expert Exchange and the like.

Comment Icon 5 Comments Read - Add | Thu 4 Sep 2008 | Open »

A Thank You To Codestore's Disciples

I have a bookmark, which I check once a week or so, that points to a search on LDD's release 6/7 forums for the word "codestore". It lets me keep an eye on who is saying what about this site over on the forums.

Back in the last millennium I used to visit the forums myself and post links to articles on this site which answered the user's problem. I did this both to help the user and to help spread the word. Before long this site's popularity took off -- all thanks to links on the forums, mainly.

Not having the spare time I used to (I was single and child-free back then) I no longer visit the forums. However, lots of people still do and I'm glad to see that links continue to be posted to content on this site. According to Google Analytics "www-10.lotus.com" is my third best referring site.

The Lotus forums brought in 830 visitors to this site in the last month. About 40% of them had never been here before and they spend an average of 4 minutes on the site. The "bounce rate" was about half, which hopefully means they're sticking round to find out what else is here.

At times like this when I'm struggling to find the time to keep the regular and useful content flowing it's always nice to know the site continues to be a resource in itself -- whether I post to it every day or not.

So, anyway, I just wanted to thank my disciples. You know who you are! (I'd list some names but don't want to upset anybody I might inadvertently leave off the list).

Comment Icon 8 Comments Read - Add | Wed 3 Sep 2008 | Open »

A Follow-Up on the Date-Based Views Tip

In March this year I talked about using a scheduled nightly agent to update the selection formulas of views which show documents based on dates.

It's a tip I've come to rely on in all databases I've created since. The one drawback is that I sometimes forget the view's selection formula is controlled by an agent and change them directly, only to find the change is lost the next day. Doh. To avoid confusion I modified the view-updating code to add an obvious warning about this.

Here's the new code:

Dim TodayDateTime As New NotesDateTime(Now)

warning = |REM "WARNING: THIS FORMULA IS UPDATED EACH NIGHT BY AN AGENT. 
ALL CHANGES WILL BE LOST!";
|

Set view = db.GetView("FutureEvents")
selection={SELECT Form="Event" & EventDate>[}+
        TodayDateTime.DateOnly+{]}
view.SelectionFormula = warning + selection
Call view.Refresh

Set view = db.GetView("FutureMeetings")
selection={SELECT Form="Meeting" & MeetingDate>[}+
        TodayDateTime.DateOnly+{]}
view.SelectionFormula = warning + selection
Call view.Refresh

The result is a view that looks something like this:

ScreenShot001

Hopefully this will prevent accidentally making the change that and forgetting it actually needs to be done in the agent itself. Well, I say agent, the change should ideally be made in the Script Library called from the agent -- see the second tip in the blog I linked to above.

Notice that the code in the first entry I wrote about this didn't include the SELECT keyword in the selection formula, but that this code does. It's inclusion appears to be optional and Notes will add it if you don't If, like here, you're adding code that's not part of the selection (the REM) then you need to add the SELECT otherwise the REM gets wrapped inside it.

Comment Icon 13 Comments Read - Add | Fri 29 Aug 2008 | Open »

A Rainy Week in Dorset - Random Photos

Normally I let you know if I'm going to take time out from writing anything here. Last Friday, before we left for a week in Dorset, I was half way through doing so when I came over all paranoid.

Hang on a moment, I thought. Why announce to the world that my house will be empty for a week when my address, as a domain owner, is all of two clicks away.

Anyway, I'm back now following a wet week on the south coast. Here's yours truly on day one wondering why the hell he chose not to go abroad:

I was so pre-occupied with making sure I'd packed all the holiday essentials, such as sunglasses and trunks, that I completely forgot to pack a waterproof coat. Have I not lived here long enough to know you can't rely on the weather!? The coat I am sporting cost me £2.99 and is made of 100% plastic. It's very waterproof though. Who needs Goretex!

We decided to stay in England as flying with two small children would have been too much. Although, as it turned out, getting too and from the south coast by road took just as long as a flight to Greece would have done.

As a child all my summer holidays were here in the UK and I have fond memories of them. I've always wanted my own children to see as much of this country before jetting off to others.

Another reason to stay here was to save money. How naive. A week in "rip off" Britain cost just as much as a week on a Greek island would have done! You live and learn. Next year we'll be going back to Greece where you almost guaranteed seven days of sun.

A holiday should be a break from the norm. Staying in the UK you just don't get that. You still have to pay to park wherever you go and sit in traffic jams.

Family holidays are about the kids though and Felix loved every minute, come rain or shine (Minnie was oblivious and it's increasingly tricky with Quinn to tell if she's enjoying it).

As Brits you learn to make the most of the weather though. Here are a couple of shots:

Comment Icon 8 Comments Read - Add | Mon 25 Aug 2008 | Open »

More blog entries are available in the archive »