A very common performance anti-pattern is wrong deployment of components. This often comes when applications are deployed as they are designed at a conceptual level. Most web-based applications today are build based on the Model-View-Controller concept. This means that components are seperated into :

  • A view part responsible for presenting a user interface to the end user.
  • A controller part containing the interaction logical as well as business logic.
  • A model part consisting of the actual data and some logical relations in the data.

When it comes to deployment a very frequently chosen scenario is splitting the system into a frontend system and a backend system. Especially for J EE applications this is a typical deployment scenario.

In some situations this deployment approach may cause a serious performance problem. This is specially true for data-intensive applications. In a modern application we might run into a situation as shown below. We have a data-intensive task which retrieves data from the database processes it in business components and then forwards the information to the user.

Multi Tier Deployment
Multi Tier Deployment

By moving the all logic we need for this task on one server we can reduce the amout of data sent over the network as well as the CPU load required for serialization and deserialization. Additionally the number of objects that have to be created can massivley be reduced. Serialization also requires interim objects to be created e.g. when converting an object model into an XML structure or the other way round.

The dynaTrace Remoting and WebServices Views provide an excellent way for anaylzing remoting overhead on a transactional basis. This information is vital for identifying these kinds of deployment problems. Below there is a sample of a web service including the data amount transferred as well as networking and remoting times.

dynaTrace Remoting and Web Service Views
Dynatrace Remoting and Web Service Views