Further Suggestions - Speed Week, Day 4
Note to self - If you're going to start a week of speed tips, make sure you have at least five things to talk about.
Over the last three days I've talked about some fairly solid techniques for improving speed. What else can we do though?
Today I'll offer some suggestions and then open it to the floor for others. Tomorrow I'll summarize any suggestions I think worthy of more attention and further investigaion.
- Browser Cache
- Obviously the user's browser is out of our control binvestigationut there are things we can do at server level to help the browser know what to cache. For example, see Chris Linfoot's blog about agressive caching of images on a Domino server using Web Site Rule documents.
- Storing File Resources
- If you are using the YUI library or something similar that's comprised of dozens - if not hundreds - of files then it's worth considering using the Domino\HTML directory on the server. Why keep all these files inside the NSF!? If the database requires authentication then there's the obvious overhead involved in each request for a resource contained within a secured database. Alternatively place them in a separate library database so other applications can share them and save downloading more than once for each app.
- Persistent Connections
- Browsers can make a lot of requests all at once for files from a server. You can tweak this but have to keep in mind that the server can only respond to so many at once. This (I think) is governed by the Persistent Connections settings on the server document. Anybody? Increasing the allowed number should theoretically increase speed.
- SSL Redirections
- The client website I was reviewing has SSL enabled by default. In fact the "homepage" setting for their domain redirected all requests to https://cliient.com/site.nsf. Not only does the redirect slow things down but the use of SSL also has a performance overhead to consider. Unless you really need to use SSL, don't.
Can anybody think of anything else that should be mentioned?
Skip to the 
You can subscribe to an individual
Good week Jake.
Speeding applications involves a lot of considerations, from server tunning to coding for speed.
I didn't hear you mention GZIP as an option to speed up traffic between servers and browsers. Compressed content travels faster of course and almost all the new browsers can deal with GZIP. I don't have more facts about it but I've heard that is useful. even Brendon has a product (Web Booster) to help out with speeding applications, but I don't know if it apply for the new versions of Domino that includes GZIP support.
Anyways, there's a lot of best practices that can be implemented to seed up applications. Thanks for resuming them here!
Cheers!
.::AleX::.
In this iNotes tunning article {Link} we can see that enabling GZIP is not always a good choice and can be sometimes negative.
I'm not sure it's a really good option.
Alex, I think you might have ruined tomorrow's post. ;-)
Julien, you can still encode individual files yourself and create some web site rules to served those.
{Check Tim's take on this {Link}
You could just claim that you sped up the postings and finished the week early. :-)
Re: hosting YUI libraries outside the NSF, for public internet applications you could just use the Yahoo! hosted versions. This was a relatively recent announcement over at the YUI blog: {Link}
and {Link}
They include version numbers in filepaths (a good idea for everyone's own libraries when doing the aggresive caching thing) so you can use the version you've developed/tested against on an ongoing basis.
I've seen very few people leverage domino server side caching. It's an heritage of 4.61 evolution, has a lot of caveats (only for anonymous request, for certain domino urls etc...) but can be a real performance boost (by caching the generated HTML by domino, server side, for a defined period of time)
I've begged IBM to enhance it (so it may behave like Websphere dynacache in terms of flexibility but it never happened).
I agree, server side caching can do wonders (especially usefull for public sites), but you have to carefully design your application with server-side caching in mind before you build it :)
Another great trick regarding client side caching and response-headers (that really makes a difference) is the one from Tomas Nielsen:
{Link}