Why is JBoss AS 7 so fast?
Transfer. Original article http://in.relation.to/Bloggers/WhyIsJBossAS7SoFast . The article will soon be a year, but the question is still relevant.
In short, the answer is the following: because the entire design of JBoss AS 7 is based on the Emdale law (effective parallelization of tasks) as opposed to Moore's law (wait for the iron with a higher processor frequency). Almost every processor in service with desktops, laptops and servers today has at least two cores, and the trend is growing rapidly. The days of races for the processor frequency are already in the past. So, programs have to adapt to squeeze out all the hardware that is now and will be tomorrow.
To achieve this crucial evolution, JBoss AS has undergone an aggressive transformation. In AS 7, we started from scratch and from scratch built a completely new, high-performance and well-managed kernel architecture. With the help of truly amazing engineering work, we were able to come from a tiny prototype on Github to a full-scale implementation of the Java EE Container Web Profile for more than a year (not to mention that during this time we also released AS 6, which provided JBoss users with early access to EE6 technologies).
')
Before explaining, let me make a small indent. The main task of the application server is service management. Almost all components of modern applications have a certain life cycle, that is, at some point, the component must be started and later stopped. All that has a life cycle, we mark as a service. Another important property of services is that they usually have interrelations that affect their life cycles accordingly. For example, we can say that the servlet is dependent on the web server. In addition, it can be assumed that if a servlet uses some other resource, say a connection to a database or an EJB, then it also depends on their availability. When an application server starts or deploys an application, it must ensure that the various services start up in the correct sequence. Further, if any of these services is somehow stopped, it must first stop everything that depends on the given service (essentially in the reverse order). This is a fairly simple task, if done in a single thread.
On the other hand, JBoss AS 7 starts and deploys all services in parallel. This challenge is solved by our new modular service container - the JBoss Modular Service Container. MSC is essentially an advanced parallel automaton. It analyzes dependencies between all services on the fly and tries to start as many services as possible at the same time, observing interconnection requirements. This gives us not only a quick start, but also the possibility of parallel deployment of several applications.
In addition to parallel services, JBoss AS 7 also has modularity and parallel class loading. By decomposing the classes into the appropriate modules, the application server can naturally optimize access to the classes and search only where this class really is. Since the visibility between the modules is intentionally limited, the search operation is cheap. In the case of JBoss Modules, the resolution of the modules and the class lookup occurs in O (1). All this works at a very high level of parallelism, including a significant part of the analysis of the structure of classes.
Deployment processing is also very effective. The most important optimization is that we index annotation information by quickly scanning part of the class data. For even greater efficiency, we allow modules to pre-generate a compact index designed for fast loading. And another sweep optimization is that we carefully cache and reuse data about the structure of classes.
In conclusion, the last optimization that I would like to emphasize is that we were and will be very strict with the load on the CPU and memory at startup and scan. It all comes from choosing the right solutions in the design phase . An interesting example of such solutions is our moratorium on using JAXB (and any other compiler based on introspection [1]) to parse a configuration that is read only once. Before starting to analyze the configuration itself, JAXB spends as much, if not more, time to figure out how to do this very analysis. And so everywhere. In fact, only XML parsing in AS 5 and 6 took more time than raising the entire AS 7.
I hope this will give a clearer picture of how we achieved such a performance gain, and why some things in AS 7 are so different from previous versions. This, however, is only the beginning. Wait for my next blogpost, in which we will talk about the future development plan of AS 7.
Thank!
[1] I didn’t find an acceptable translation in the original: introspection driven binder - I think it means XML deserializer, which first parses an XMLSchema document to understand data types, and then begins deserialization itself.
In short, the answer is the following: because the entire design of JBoss AS 7 is based on the Emdale law (effective parallelization of tasks) as opposed to Moore's law (wait for the iron with a higher processor frequency). Almost every processor in service with desktops, laptops and servers today has at least two cores, and the trend is growing rapidly. The days of races for the processor frequency are already in the past. So, programs have to adapt to squeeze out all the hardware that is now and will be tomorrow.
To achieve this crucial evolution, JBoss AS has undergone an aggressive transformation. In AS 7, we started from scratch and from scratch built a completely new, high-performance and well-managed kernel architecture. With the help of truly amazing engineering work, we were able to come from a tiny prototype on Github to a full-scale implementation of the Java EE Container Web Profile for more than a year (not to mention that during this time we also released AS 6, which provided JBoss users with early access to EE6 technologies).
')
Before explaining, let me make a small indent. The main task of the application server is service management. Almost all components of modern applications have a certain life cycle, that is, at some point, the component must be started and later stopped. All that has a life cycle, we mark as a service. Another important property of services is that they usually have interrelations that affect their life cycles accordingly. For example, we can say that the servlet is dependent on the web server. In addition, it can be assumed that if a servlet uses some other resource, say a connection to a database or an EJB, then it also depends on their availability. When an application server starts or deploys an application, it must ensure that the various services start up in the correct sequence. Further, if any of these services is somehow stopped, it must first stop everything that depends on the given service (essentially in the reverse order). This is a fairly simple task, if done in a single thread.
On the other hand, JBoss AS 7 starts and deploys all services in parallel. This challenge is solved by our new modular service container - the JBoss Modular Service Container. MSC is essentially an advanced parallel automaton. It analyzes dependencies between all services on the fly and tries to start as many services as possible at the same time, observing interconnection requirements. This gives us not only a quick start, but also the possibility of parallel deployment of several applications.
In addition to parallel services, JBoss AS 7 also has modularity and parallel class loading. By decomposing the classes into the appropriate modules, the application server can naturally optimize access to the classes and search only where this class really is. Since the visibility between the modules is intentionally limited, the search operation is cheap. In the case of JBoss Modules, the resolution of the modules and the class lookup occurs in O (1). All this works at a very high level of parallelism, including a significant part of the analysis of the structure of classes.
Deployment processing is also very effective. The most important optimization is that we index annotation information by quickly scanning part of the class data. For even greater efficiency, we allow modules to pre-generate a compact index designed for fast loading. And another sweep optimization is that we carefully cache and reuse data about the structure of classes.
In conclusion, the last optimization that I would like to emphasize is that we were and will be very strict with the load on the CPU and memory at startup and scan. It all comes from choosing the right solutions in the design phase . An interesting example of such solutions is our moratorium on using JAXB (and any other compiler based on introspection [1]) to parse a configuration that is read only once. Before starting to analyze the configuration itself, JAXB spends as much, if not more, time to figure out how to do this very analysis. And so everywhere. In fact, only XML parsing in AS 5 and 6 took more time than raising the entire AS 7.
I hope this will give a clearer picture of how we achieved such a performance gain, and why some things in AS 7 are so different from previous versions. This, however, is only the beginning. Wait for my next blogpost, in which we will talk about the future development plan of AS 7.
Thank!
[1] I didn’t find an acceptable translation in the original: introspection driven binder - I think it means XML deserializer, which first parses an XMLSchema document to understand data types, and then begins deserialization itself.
Source: https://habr.com/ru/post/142028/
All Articles