Protected: Wiring together Spring Boot, Spring Cloud and Microservices

This content is password protected. To view it please enter your password below:

Protected: Basic Architectural Concepts – NFRs

This content is password protected. To view it please enter your password below:

Protected: DevOps, Continuous Integration and Continuous Delivery

This content is password protected. To view it please enter your password below:

Protected: Notes on Architecture

This content is password protected. To view it please enter your password below:

Protected: Application Scaling – Server Side, Database Side and on the Browser

This content is password protected. To view it please enter your password below:

Short Note On Application Performance Tuning

We discuss the following basic points in this post- Heap, Heap Dumps and Thread Dumps, Memory Leaks and Connection leaks and Connection pooling
What is java heap?
When new java objects are created they are allocated memory in the java heap. Once they are no longer referenced by other java objects they may be garbage collected and memory is returned to the heap. Xms and Xmx are java switches that allow you to manipulate memory allocated to the heap.
There are two different types of heap – the new generation heap where new objects are allocated memory and the old generation heap that accommodates objects that have been in memory over a longer period. Perm memory is memory allocated to objects that have been loaded into memory through the classloader and will be removed from the perm memory only when the classloader is garbage collected.
OuOfMemory errors can be due to too many large objects in the session object in a web application and when there is not enough memory to create new objects in the java heap. This may occur when java objects are not returned back to the heap by the garbage collector. OutOfMemory exception may occur due to memory leaks. Memory leaks can be debugged by using the command:

java -verbose:gc

which will provide information on the garbage collector, objects garbage collected, etc and is used to fix garbage collector problems. A memory leak may be fixed by analyzing the logs from the above command.
Calls to Runtime.gc or Sytem.gc() should not be explicitly made. Note that threads including the JVM are paused when the major GC runs. Minor GCs do not cause the JVM to pause, but to some extent it is okay, as long it doesn’t cause noticeable slowness.
Java heap dump and thread dumps can be used to produce a stacktrace of the heap/ running threads. The stacktraces look similar to an exception stacktrace. Connection leaks are more difficult to detect since we may not know exactly where in the code a certain connection was not closed. This may be analysed by generating heap/ thread dumps using use case by use case.
Sometimes a memory leak/ application slowdown / hangup, may be difficult to find after it has been fixed. In that case one should enable GC logging / heap/ thread dumps tracing so that the next time this happens the cause is correctly found.
If a thread dump shows too many threads running it may indicate a reason for application slowdown. Thread dumps are mostly to find what the JVM is busy doing. If we see an unusually high number of threads such as more than 300 or so that means the JVM is working too hard on something and then you should look at what these threads are doing. If you see a lot of threads stuck on reading from the db that indicates db slowness. If you see too many threads servicing Servlet requests that means the JVM is overloaded with too many users.
Sometimes it helps to take thread dumps a few minutes apart and compare the two thread dumps to see if threads are moving along or stuck. If thread A in dump1 is doing the same thing in dump2 taken later, then it’s taking too long; usually you should be able to see it moving along and do different things.
It’s ok to have long running threads as some threads are by design supposed to be long lived e.g. you can have a pool of threads to consume JMS messages. Those threads will be alive for a long time and will be reused over and over again. So that’s normal as long as they don’t hold big objects for a long time, it’s not a memory leak.

A quick glance at web development design patterns


1. Business Delegate

A server side layer that exposes the business layer API to the client components.

Promotes reusability of business API -the business service lookup/access is encapsulated.
Reduces dependency of client objects on the server side business layer API implementation.
Adds a layer between presentation and business layers.

2.Value Object/ Data Transfer Object

A serializable object for transferring data over a network

1. Reduces network traffic because the VO is transferred on the server side and frequent client-server calls are reduced. – fewer remote calls
2. Increases response time

3. Session facade

A layer that acts as an entry point into the business layer and manages the workflow of business objects such as session beans/ entity beans and data access objects. It is itself implemented as a session bean.


4. Data Access Object

An object that accesses the database separating the business layer from the data access layer. The business layer is shielded from any change in datasource.
The app can dynamically plug into an appropriate datasource on the fly by selecting an appropriate DAO.
Note that the objects of the business and integration tiers reside in the same JVM.
Reduces dependency of business logic on the data access layer.


5. Model View Controller

The Model-View-Controller design pattern is applicable in situations where the same data (Model) is to be presented in different formats (Views), but is to be managed centrally by a single controlling entity (Controller)
Separates the data representation (model) from the data presentation (view)
Separates the application behavior (Controller) from the data presentation (view) and data representation (model)
The presentation (WML/JSP/XML/HTML) may be presented in different format independent of data.
There is a single controller.


6. Front Controller

Provides a common point of entry into the application.
Unifies and streamlines authentication and authorization and dispatches work to appropriate handler components (manages workflow) use-case wise.