Performance, Scalability and ITSM

People often ask us why LiveTime is so much faster than any other ITSM, Service Desk or Help Desk application. On the surface it sounds like a really simple question. However there are many factors that contribute to the overall performance of an application. If we remove hardware from the equation, which will make nearly any application faster, we can focus on 3 key factors; architecture, design and technology. Let’s take a look at each one of these in turn.

Architecture

There are many different architectures you can use when designing an application. Simple desktop applications are generally single tier designs. They only need to cope with a single user and need limited, if any scalability. Once we move into the realm of concurrent user access we have a whole new set of problems to deal with, namely managing application access and data co-mingling. With even modest access this can bring any single tiered application to its knees.

This is where a multi-tiered application design is so important, whereby the different parts of the application can be independently scaled. In a multi-tiered design, there is normally a minimum of 3 layers, although there can be more. This is why it is often referred to as an nTier application design. This normally consists of the Client (often a web browser, or thick client application in the case of legacy applications), Business Tier (application server) and Data Tier (database storage). In modern design patterns such as LiveTime we also have a Web Tier for a more distributed topology.

What does this all mean practically? Effectively it means that as the number of users increase LiveTime is able to scale out each of these layers based on the traffic volume. As the number of users increases we can tune each layer for optimum performance and separate each layer onto their own servers as necessary. This is simply not possible in a single tiered environment.

Design

Perhaps the most important part of the entire performance stack is the application design itself. There are many systems with a multi-tiered approach that don’t even come close to the performance characteristics of LiveTime. LiveTime uses many advanced design patterns for achieving optimal performance. For example, LiveTime uses a classic MVC (Model View Controller) paradigm, which although common in desktop application design, is much more difficult to achieve in a web based architecture. LiveTime is based on a component architecture, whereby a page is constructed using many reusable elements that get cached and reused as needed. So rather than designing pages over and over again, LiveTime is comprised of many discrete elements which build up the entire page. This not only assists in development speed, but also the application performance itself. Other applications co-mingle code with the presentation layer logic (examples include PHP, JSP, Perl etc) and are therefore not only difficult to maintain but do not benefit from the resuable nature of the components that LiveTime uses.

LiveTime also provides ORM (Object Relation Mapping) abstraction at many levels. This provides access to data through multiple levels of cache. Commonly used objects within the application are reused, so there is no need to do a round trip back to the database. Instead the objects are retrieved directly from memory and are also shared between concurrent user sessions. This means that the more people that use the application, the faster the perceived response, as it is likely that the data persists in memory already.

The ORM layer within LiveTime provides an added benefit in that it allows us to plug into different database or cloud storage systems as technologies change. This unique capability means that LiveTime is also future proof. We can adapt very quickly to technology changes by simply replacing the ORM layer.

With any busy application such as LiveTime, that serves tens of thousands of requests a minute, it is also important we not only cache objects as needed but conserve valuable system resources, such as database connections, memory and network bandwidth. LiveTime scales so well because of the way it handles database connections and uses a technique known as Conversational Transactions, where it can make optimal use of database resources without constantly opening new connections to the server. Naturally there are many other design characteristics that play a role in performance, but we have covered the most important ones to give you a general feeling of the level of effort we put into LiveTime.

Technology

Finally, we come down to the underlying technology. This is a very interesting part of the overall performance of any application and one which can be very religious for those using a particular technology stack. What you have to bear in mind is that most of these technologies will work fine up to a certain point and then require such unrealistic hardware or server farms that they are not cost effective.

LiveTime is based entirely on Enterprise Java and is very well proven in the enterprise space. Why do we use this? The level of scalability we are able to achieve with this language makes it well worth the extra discipline required to write such applications. While certainly not as rapid to develop as languages like PHP, Perl, Ruby, or .NET we have no restrictions with what we can do and we have access to the source code of every part of the application. We do not rely on anyone’s Black Box, and can therefore fix any problem across the entire application stack. This also gives us portability across platforms, the ability to use only open standards and not rely on other vendors to support certain platforms or tools.

The LiveTime framework gives us the unique ability to control the look and feel of the application so that it is different from other applications on the market. Most frameworks dictate the look and feel so much that they all begin to look the same and provide all the same tools, ie. the workflow engines, UI and reports based on .NET.

In terms of sheer performance, Java provides us with the ability to tune every aspect of the application and adapt to new technologies very quickly. There are some very good references below that provide some good reasons why J2EE was an important move for the growth of the business and the problems experienced when trying to scale existing technologies beyond their limits.

We hope this provides some insight into how LiveTime has been designed, how we can readily adapt to changes in technology and why it is so much faster than any other application.

References:

Best Practices from Zappos to deliver WOW Performance

For Nuxeo, Success in the ECM Market Meant Switching from Python to Java