Performance Improvement - Java

DURING DESIGN APPLICATION:
1) Excessive logging
              Use log into buffer and write at the end.
              Use async logging for better performance.
              Use framework like log4j, SLF4J. 
              Don't use System.err, System.out - There is no way to turn it off. 

2) Incorrect application server configuration.
               Use appropiate heap size based on JVM.
               Use proper thread pool, connection pool, connection time, child connection settings, logger levels, etc.

3) Incorrect usage of Java EE
             
4) Improper usage of caching.
               What is the cache hit ratio?
               How much memory the cache take?
               How performance testing with respect to cache? Is it disabled?
               Can cache monitored / managed at run time? (No of objects in cache, hit ratio, amount of memory used, enable/disable cache, flushing the content, etc).
               Use cache if and only if caching is needed.
               Verify the functional and performance behaviour of your cache with performance tests.
               Make sure your cache can be managed and monitored at runtime.

5) Excessive memory usage

6) Badly performing libraries               

• without checking whether that library is really needed (and does not overlap with functionality already offered by other libraries used),
• without checking whether that library can offer good performance or whether a better performing alternative is available,
• without defining how the library is going to be used within the application.

DEPLOYMENT:
Environment tunning, Like tomcat tunning on Memory, thread, Time to live, etc.
    Few other options you should be aware of during Environment tunning:

1. Add the -server option to the JVM options for Tomcat, which should result in better performance for server applications. Note that this option, in some cases, causes the JVM to crash for no apparent reason. If you face this problem, remove the option.
2. Minimize logging in Tomcat by setting debug="0" everywhere in <Tomcat>/conf/server.xml.
3. Remove any unnecessary resources from the Tomcat configuration file. Some examples include the Tomcat examples Web application and extra <Connector>, <Listener> elements.
4. Set the autodeploy attribute of the <Host> tag to false (unless you need any of the default Tomcat applications like Tomcat Manager).
5. Make sure you have set reloadable="false" for all your Web application contexts in <Tomcat>/conf/server.xml.

Database tunning. Size, ram, no of connection, etc.

Application tunning, Like code optimization, SQL query optimization, Sql profiler, etc

1. Avoid using synchronized block in the code.
2. Classes, Methods, Variables - where every possible use final variable.
3. provide proper logging to help dubugging. 

Builder Vs Factory

Builder - Create another object of specific type over several steps.
Builder - Holds the needed state for the target iteam at each step.
Example: When you ask for Car it will give Hond with 4 Cylnder or Honda with 6 cylnder engine or Maruthi.
Example: Make a loan object, There are several loans(education, personal, car, house) and intrest rates are different, So the final object is created with Step by step process.

Factory - Create another object of specify type in one step.
Example: When you ask for Cat it will give Honda or Maruthi.
Example: When there is a super class and 'N' number of subclass, Depends on the parameter the object will create and return.

List of Available Design Patterns - GOF.

Creational Design Pattern
1) Abstract Factory pattern
2) Builder pattern
3) Factory pattern
4) Prototype pattern
5) Singletone pattern

Structural Design Pattern
1) Adapter
2) Bridge
3) Composite
4) Facade
5) Flyweight
6) Proxy

Behaviroral Design Pattern
1) Chain of responsiblity
2) Composite
3) Interpretor
4) Iterator
5) Memento 
6) Observer 
7) State 
8) Strategy 
9) Template Method 
10) Visitor 

SOA and ESB

SOA is an architectural model for implementing loosely coupled service based applications. ESB is a piece of infrastructure software that helps developers to develop services, and communicate between services through suitable APIs.

SOA Service should be stateless. It may have a context within its stateless execution, but it will not have an intermediary state waiting for an event or a call-back. The retention of state-related data must not extend beyond a request/response on a service. Because state management consumes a lot of resources, and this can affect the scalability and availability that are required for a reusable service.

Pitfalls of SOA; One of the most common pitfalls is to view SOA as an end, rather than a means to an end. Developers who focus on building an SOA solution rather than solving a specific business problem are more likely to create complex, unmanageable, and unnecessary interconnections between IT resources.
Another common pitfall is to try to solve multiple problems at once, rather than solving small pieces of the problem. Taking a top-down approach—starting with major organization-wide infrastructure investments—often fails either to show results in a relevant timeframe or to offer a compelling return on investment.


ESB can be used as a platform on which SOA is realized. ESB is only the medium through which the services flow. ESB provides facilities for the composition and deployment of services, which in turn implement the SOA. Also ESB provide "Any to Any" connectivity between the services with in application.

Decorator Design Pattern

Type of Structural Pattern:

Purpose: Add additional responsibilities dynamically to an object.

Adapter Vs Decorator: Adapter changes the object interface it self, But the decorator does not change the object it will add aditional responsiblity to it.

Key:
1) Decoration adds functionality to objects at runtime which would make debugging system functionality harder.
2) Decoration it is also possible to remove the added functionalities dynamically.

Software Design Principles

3 important characteristics of a bad design that should be avoided:

1. Rigidity - It is hard to change because every change affects too many other parts of the system.
2. Fragility - When you make a change, unexpected parts of the system break.
3. Immobility - It is hard to reuse in another application because it cannot be disentangled from the current applications.

Open Close Principle:
Open for extension and close for modification.

Interface Segregation Principle:
Clients should not be forced to depend upon interfaces that they don't use.

Single Responsibility Principle:
A class should have only one reason to change.

Liskov's Substitution Principle:
Derived types must be completely substitutable for their base types.

Factory Design Pattern

Type of Creational DP.

Singleton Vs Factory.
            Singleton always returns you a same object, But factory returns to a new and requested/difference objects.

key-point:
              creates objects without exposing the instantiation logic to the client.
              refers to the newly created object through a common interface

How it works:
              1) Client need a object, Instand of creating using new operator it will ask factory object to give a new Object,
              2) The factory instantiates a new concrete product and then returns to the client the newly created product.
              3) Client uses the products as abstract products without being aware about their concrete implementation

Observer Design Pattern.

Observer Design Pattern used whenever a subject changes has to be observed by one or more observers.

Example domain usages: Stocks, Weather reports, News providers and Score providers, etc.

loosely coupling: Change of a state in one object must be reflected in another object without keeping the objects tight coupled.

Key problems: 

1. Many Observers to Many Observables.
2. We can have either push or pull method data transfers.
3. When many Onververs and Observables comes we may need to introuduce new logic object responsible(ChangeManager) 
1. Encapsulate the logic of notify the observers
2. Maintain the many to many relations
3. Receive the notifications from subjects and delegate them to the observers

Factory, Mediator and Template pattern can be used with in this design patterns.

Singleton Design Pattern.

When to use Singleton: Singleton is used there must be one instance of the class. And it must be accessable to clients from global point.

Example usage of Singleton: Logger object, Configuration object, Cache object, Properties Object, Factory methods are used Single ton, etc..

Problems of singleton:      
          1) Multi-thread safe. ( method level it self)
          2) Lazy installation using double  locking machanism, (Synchronized inside the getInstalnce() method)
          3) Early installtion method.
          4) Serialization. (serializable(), readResolve())

Why Tomcat 7?

Apache Tomcat version 7.0 implements the Servlet 3.0 and JavaServer Pages 2.2 Specification.
Tomcat 7:
                1) Application memory leave and prevention.
                2) Support for external content directly into web application.
                3) lot of code cleanup for connectors and lifecycle.
                4) Full support of Java Servlet Specification 3.0.|
                5) Simplified embedding.

Tips for using tomcat:
                1) Use Shared library concepts.
                2) Custom error pages.
                3) Tweak memory settings.
                4) Use IP/Hostname filters to allow subset machines to connect.
                5) Secure directory listing.
                6) Use GZip compression.
Tomcat supports:
                      1) SSL.
                      2) Proxy support.
                      3) Load Balancer.
                      4) Virtual Hosting.
                      5) Logging.
                      6) SSI, CGI.
                      7) Embedded Tomcat.

REST Vs Soap

REST: Representational state transfer, It’s an architecture.

              REST architectures consist of clients and servers. Clients initiate requests to servers; servers process requests and return appropriate responses. Requests and responses are built around the transfer of representations of resources

               REST architecture work with Http protocol, so it’s purely stateless,

               Client request can catch the responses to improve the performances,

               It’s a layered architecture; we can improve the system by enabling load-balancer, cache server, etc.

               It provides / designed for uniform interface.

                REST: bandwidth usage is lighter.

SOAP:

               It’s a an protocol,

               It can run on Http, Jms, Ftp, SMTP protocols.

               This supports Transaction, security, etc But REST users to build this custom plumbing,