Performance is an inherently subjective concept and also has multiple objective meanings. When we typically think of "performance" as a topic in regards to a web application we think of just how fast it takes for the information coming from the last click to make it to our eyes. But if you are in charge of creating and/or maintaing web sites then you are also very interested in capacity/throughput and achieving the best overall performance from your computing environment.

In this post I'll talk about end-user performance and leave capacity discussions for another time. The thing that is very important to uderstand when it comes to end-user performance is that the amount of time people will wait for a response in directly proportional to the importance of that response to them.

If the response is perceived to provide valuable information, or saves significant time from an otherwise tedious process, or in some other way is seen as important to the end user then they will find that almost any wait is not too long. On the other hand, if you are just randomly web surfing then you are unlikely willing to wait much more than  a second or two. Yet many times I'll see IT shops striving to provide "google-like" speeds to their intranet or content systems because they believe their users will not put up with slow transactions (which may be true) and that if it is fast then people will love to use their systems (which may not be true at all).

Objective Times

It is very difficult to measure perception and probably impossible to do so in an automated fashion; we need some objective numbers to strive for. Here it is important to know your audience, and how they are going to connect to your service. If your audience are fleeting visitors then you had better be serving up pages to them in 1 second or less; that is, they had best be able to read/view the response within 1 second. While not universally true, that is a very difficult number to hit with any dynamic site, typically it requires the serving of (pre-rendered) static files because unless you have the money to spend on Content Delivery Networks, you need virtually all of that second to travel along the network. Visitors, you see, don't care about distance/geography or science, if it isn't fast enough then they just won't use it.

Semi-valuable information, like the sort a social media site might provide with friends' statuses has a higher threshold. While this is a bit of a moving target, the truth is that a steady 3 second delay on clicks that are happening more than twice per minute is actually a noticeably long time. This pretty much leaves a maximum of 1.5 seconds total processing time and 1.5 seconds delivery time (if you deliver small volume of data then you have more processing time, if you deliver greater volume then you have less processing time .... the 3 second response can only be broken very occasionally or you will lose your users.

Very valuable information that is infrequently required (say downloading a document for manual processing can take a very long time indeed -- minutes even hours. It is so variable, in fact, that I'm not even going to name a number. If you feel you have such valuable information (experience or what have you) then you should be able to price it accordingly. You'll know you were right (or wrong) by the number of complaints or kudos you receive.

How do you achieve 1 second? IT IS HARD!

There is only one way, you do a very small amount of work, you send a small amount of data, and you use a non-congested network, short-hop network; you do all three of these things or you fail.

Doing a small amount of work in Livelink-speak usually means dealing with only a few hundred objects (at worst) for each container ... a folder with 100 files is already something difficult for many users to adequately sort through, a folder with 1000 files is really difficult to manage from a UI perspective and has a very serious performance draw on a Livelink server.

Static Page Caching

Of course the best way to serve fast pages is to have the informaiton ready for use before it is requried. Most web servers have special, fast code paths to deliver static pages of content, whether that is images, video, or indeed even raw HTML. Thus, to provide the ultimate in fast experience the best thing to do is to create the web page view you want your user to see before they ask for it and then when they do ask, provide the static page(s).

If not done correctly, caching can have a serious security concern as few caches are aware of the security of the content within the cache ... it is best to treat such data as public (or, depending on how things are setup, at least 'public' in terms of the total population capable of accessing your site). I won't say more than that here, but I will say more in another post (in another forum) and will try to remember to cross link them.

Such static caching is quite difficult for most Livelink Enterprise Server / Content Server implementations as the view of any particular folder, project or other container can (and often is) different for each user such that caching of such dynamic content isn't often practical. For this you should use WCM software like Red Dot's or Gauss' and a notion of "publishing" (there are some web publishing modules available for Livelink but if you can afford Livelink you probably have a need for a dedicated but integrated WCM platform rather than a smaller one-off solution.