Performance, Scalability and ITSM
People often ask us why Absolute Service is so much faster than any other ITSM solution. On the surface it sounds like a 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 the key factors; architecture, design and technology.
Let’s take a look at each one.
Architecture We need the architecture picture in this section redone accordingly
There are many different kinds of architecture 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 three layers. 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 Absolute Service 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 Absolute Service 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.
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 Absolute Service. Absolute Service uses many advanced design patterns for achieving optimal performance. Absolute Service 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, Absolute Service 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.
Absolute Service 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 Absolute Service 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 Absolute Service is also future proof. We can adapt very quickly to technology changes by simply replacing the ORM layer.
With any busy application such as Absolute Service, 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. Absolute Service 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.
Finally, we come down to the underlying technology. 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.
Absolute Service is based entirely on Enterprise Java and is 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 Absolute Service 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.
We hope this provides some insight into how Absolute Service has been designed, how we can readily adapt to changes in technology and why it is so much faster and flexible compared to other applications.