Skip to Content
author's profile photo Former Member
Former Member

Portal Compression

Hi All,

When looking at improving the performance of your Portal, compression is one of the factors that can be incorporated however, it is slightly confusing as there are a number of alternatives.

1. IIS Compression filter.

2. Client-Server compression in the System Preferences

3. EnableZippedResponse in the SAPJ2EE Engine

With no distinct explanation as to how these all work together the advantage is lost when trying to justify that everything that can be done to improve performance has been done.

Once all of these measures have been implemented a sniffer tool to capture http request and responses should highlight the benefits.   You would expect to see a majority of responses returned as zipped files or at least a reduced file size. When one response comes back zipped and there are no changes to the rest of the responses, questions are asked...

Can anyone summarise potential answers.



Add comment
10|10000 characters needed characters exceeded

1 Answer

  • author's profile photo Former Member
    Former Member
    Posted on Oct 21, 2003 at 03:15 PM

    Compression generates same overhead and more load at the server and client side. It'll improve performance only on slow lines (modem/isdn) and only if the file size is above some limit. Already compressed media types should not be compressed again.

    So compression should only happen, if

    - line speed is modem speed or slower

    - data isn't already compressed (html, js, css, but not jpeg, gif, png)

    - file size is above 2-4k

    - the client/browser does support compression/decompression

    There is no simple test for the first point but the last ones are

    handled by the portal compression.

    So I would not be surprised if compression on a fast line does decrease performance.

    And I would not be surprised if many files won't be compressed even if compression

    is on.

    Compression IMHO is not the first thing I try if I want to increase performance.

    I would set up a benchmark (JMeter, HTTPUnit) and test against compression

    turned OFF.

    Frerk Meyer

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      Regarding not compressing small files,

      For IisProxy.dll there is a parameter:

      <!ELEMENT compress-types (#PCDATA)>

      <!ATTLIST compress-types

        min-size CDATA "1024"


      So an entry in IisProxy.xml might look like

      <compress-types min-size="2048">text/html, text/plain, text/css</compress-types>

      I remember one SAP Note said there is a bug in MS IE with compressed text/css

      so you might need to exclude that.

      For SAPJ2EE.dll there is only one registry entry which might

      address the same feature: CompressionEdge which is set to 150.

      But this is a wild guess.

      text/css is excluded in the registry as well as jpg, gif and others.

      You may even exclude mime-types from compression for specific browsers.

      To benchmark the performance you need a slow line or a simulated slow

      line. There are expensive devices on the market which even can simulate

      line noise. But an alternative would be a small linux box with two

      network cards and iptables (Linux Kernel Firewall) configured between them.

      There are rules which throttle the number of pakets according to interfaces, ports

      and protocols. Detailed statistics about incoming and outgoing pakets,

      bandwidth and latency are for free unter /proc. Ask your local Linux Guru.

      No, I haven't set that up myself, but read about these rules. Usally they

      are used for a quality of service filtering where ssh connections go full

      speed and http is slowed down if the line is overused.