Skip to main content

Compression of HttpServletRequest and HttpServletResponse by gzip encoding


Description 
This filter is on HTTP headers in a HttpServletRequest, compress data written to the HttpServletResponse, or decompress data read from the request. When supported by the client browser, this can potentially greatly reduce the number of bytes written across the network from and to the client. As a Filter, this class can also be easily added to any J2EE 1.3+ web application.





Installation

1).Add the pjl-comp-filter-XX.jar file containing CompressingFilter to your web application's WEB-INF/lib directory.

2).Add the following entries to your web.xml deployment descriptor:

 <filter>
  <filter-name>CompressingFilter</filter-name>
  <filter-class>com.planetj.servlet.filter.compression.CompressingFilter</filter-class>
 </filter>

 <filter-mapping>
  <filter-name>CompressingFilter</filter-name>
  <url-pattern>/*</url-pattern>
 </filter-mapping>

The below data is of my application where i tested this compression techniques

The count is based on data fetched from fiddler when running  app  with and without compression Filter.

Data compression ratio=5:1

Header space savings =80%

Encoding used= gzip

Below header data is actual and after installing CompressingFilter.



Before encoding
After using gzip encoding
    Request Count: 12
    Bytes Sent: 8,212
    Bytes Received: 92,623

    ACTUAL PERFORMANCE
    --------------
    Requests started at: 17:58:52:1558
    Responses completed at: 17:58:57:9514
    Aggregate Session time: 00:00:05:1525
    Sequence (clock) time: 00:00:05.7955795

    RESPONSE CODES
    --------------
    HTTP/404: 1
    HTTP/304: 10
    HTTP/200: 1

    RESPONSE BYTES (by Content-Type)
    --------------
    ~headers: 1,384
    text/html: 91,239
    Request Count: 12
    Bytes Sent: 8,206
    Bytes Received: 15,392

    ACTUAL PERFORMANCE
    --------------
    Requests started at: 18:30:13:7882
    Responses completed at: 18:30:14:9522
    Aggregate Session time: 00:00:00:7760
    Sequence (clock) time: 00:00:01.1640000

    RESPONSE CODES
    --------------
    HTTP/404: 1
    HTTP/304: 10
    HTTP/200: 1

    RESPONSE BYTES (by Content-Type)
    --------------
    ~headers: 1,661
    text/html: 13,731

Popular posts from this blog

What are Java heap Young, Old and Permanent Generations?

The Java heap is dived into two parts i.e. Young generation and old generation. Young generationYoung generation  memory is 40% of Maximum Java Heap. It consists of two parts, Eden space and Survivor Space. Eden SpaceInitially objects are created in this  Part of Java Heap , here most objects die and quickly are cleaned up by the minor Garbage Collectors (It only runs in young generation and its frequency is high in compared to major garbage collector). Usually any new objects created inside a Java Method go into Eden space and the objects space is reclaimed once the method execution completes. Whereas the Instance Variables of a Class usually lives longer until the Object based on that class gets destroyed. When Eden fills up it causes a minor collection, in which some surviving objects are moved to Survivor Space or an older generation. Survivor Space  The pool containing objects that have survived the garbage collection of the Eden space The parameter Survivor Ratio can be used to tune…

4 mains causes of Long Garbage Collection Pause?

So a long GC Pause can have a direct impact on response time and throughput. But there are some causes for long GC pause which you can check and avoid to increase performance. They are as follows:-


1)Insufficient heap size:- If heap size is small then the size required then the allocation requests for new objects  fail and the JVM needs to invoke garbage collections in an attempt to reclaim space for the allocations. So these frequent Full GCs cause long pauses in the application run. To avoid long GC pause by this identify the average footprint of the application and then specify the heap size accordingly.
2)Fragmentation in the heap:-GCs can occur more frequently due to fragmentation in the Java Heap  and also sometimes causing long pauses in the GCs. This is more probable in the case of Concurrent Mark Sweep collector, also known as CMS, where the tenured generation space is not compacted with the concurrent collections. For more please go through the previous post about heap  compact…