Few people truly care about the arcane business of performance calculations, on the one hand it is utterly banal and the math involved is often fairly trivial once the model has been created, on the other hand it usually requires a lot of specialized knowledge and experience to do properly. One typically is of the belief that understanding how some application or another performs is knowledge the developers of that application should inherently know because they did, after all, build it. However it is never like that at all. In fact the developers often have very little idea (as they are developing) of what the performance parameters are let alone how to adjust them to scale.

There are very good reasons for this, both technical and philosophical in nature but frankly it comes down to simply that a developer's viewpoint of the application world is not abstract enough to readily come up with useful scaling parameters. With their gaze necessarily on the specific, single transaction / algorithm / user defining the problem space they are working on, it is difficult for them to look at the 50,000ft level and determine how to predict the resources required to scale to any particular volume. In other words, they can't see the forest for the trees.

To scale a computer-based application requires the ability to mathematically model that application, to create an abstraction of the services the application provides and use formulas and variables within that abstraction. The abstraction is absolutely required even for the simplest of applications for the number of real-world variables involved is unmanageably huge. Consider this non-exhaustive list of influential parameters to the performance of a computer-based application, (where "transaction" is meant in the most general sense possible meaning a single interaction between the computer-based application and a client/user of that application):

• Total number of users/accounts on the system
• Number of active users/accounts on average
• Number of active users/accounts at peak
• Number of bytes associated with storing content with each "transaction"
• Number of bytes delivered via network with each "transaction"
• Network latency between end-users and the application
• Third-party applications required for the solution (ie: web servers, database servers, DNS, NFS, routers, firewalls, email, etc)
• CPU architecture and bandwidth (speed)
• Memory (RAM) architecture, bandwidth, and amount
• Storage subsystem
• Shared vs. Dedicated resources
• A "transaction"'s function (the actual work that a "transaction" performs)

I'm sure I've missed some important ones with this quick list, but you get the idea. Normalizing for all of these variables is very difficult work that is often more art than science, coming from experience as much as from theory.

There are many good examples of such abstractions, I'll pick on the Transaction Processing Performance Council [TPPC] which is the most well-known and used benchmarking system for relational databases. Because databases can be used in different ways there are, in fact, three different benchmarks published -- these benchmarks are the abstractions I spoke of earlier. They are a particular mix of "transactions" that has been agreed by TPPC experts as representative of a certain way of using a database. In other words, they are the Usage Profile for a given database deployment and provided that the application you are intending to use on that database behaves similar to that Usage Profile, you can use the results of the TPPC to not only compare database vendors but also to scale out your own application as it pertains to required database resources. In fact, a good Livelink System Design and/or Sizing & Scaling engagement deliverable should include the appropriate DB resources using the TPC-C benchmark results to indicate the approximate DB server(s) to use.

So, an Usage Profile describes your application in an abstract way such that it is reasonable to apply formulae and fill-in variables to size/scale an application. Every application has at least one Usage Profile and many, like databases have a small number of distinct profiles. But some, like our beloved Livelink, have an uncountably large number of potential Usage Profiles as it is an application that builds applications. In fact, it makes no sense at all to talk about a single Usage Profile for Livelink because there is no single application that represents all of the ways that Livelink is being used.

That being said, it absolutely should be possible to talk about a single Usage Profile for each official Application or Solution Open Text sells that is built on Livelink. After all, the fact that Livelink can do Records Management (or searching or workflows or any number of other Livelink capabilities) is (mostly) moot from a performance perspective unless Livelink is actually doing those transactions. The sad truth is, however, it is NOT currently possible to do so in a generic sense as the data simply does not exist to do so. We have the tools to determine a specific Usage Profile for a specific deployment but there is no database of deployments that includes any performance data and so there is no current ability to create Solution-specific Usage Profiles.

Thus it is that the Online Livelink Performance Suite was born. Why not help out the Livelink community at large by simply creating an Usage Profile using the data from your production Livelink solution? It's easy, useful to you and others ... and it's free!