Layer7 API Management

 View Only
  • 1.  Optimize for mixed workload APIs (Large and Small payloads)

    Posted Sep 18, 2015 01:00 AM



    We typically have a high number of API requests ~100mil/day that have small Request payloads of JSON and under usually under 1Kb in length. Response payloads vary from a few bytes to 60Kb compressed.


    We are about to expose two APIs on our API Gateways that are very different. The first will have up to ~2Mb binary payloads on the Request. The other up to ~2.5Mb binary payloads on the Response.

    Can I optimize the Gateway for this mixed workload? And how?


    Thanks in advance.

  • 2.  Re: Optimize for mixed workload APIs (Large and Small payloads)

    Posted Sep 18, 2015 11:36 AM

    We have a knowledge base article in the CA Support system that may be of value to you: This requires access to the legacy API Management case management system. If you do not have access to this sytem then you can submit a request to and we'd be happy to enable access for you.    

  • 3.  Re: Optimize for mixed workload APIs (Large and Small payloads)

    Posted Sep 22, 2015 01:56 AM

    Thanks a lot. Any way to post it (or a link) here so others can get it immediately?



  • 4.  Re: Optimize for mixed workload APIs (Large and Small payloads)

    Posted Sep 22, 2015 08:19 AM

    We're working on getting articles moved from the original API Management case system into the unified CA Technologies knowledge base repository. I apologize for any inconvenience that occurs at this time as a result of that process.

  • 5.  Re: Optimize for mixed workload APIs (Large and Small payloads)

    Posted Sep 29, 2015 10:52 PM

    Recreating the information here so others can find it easily.



    The default configuration of the CA API Gateway is optimized for handling messages in the range of 1 to 50 kilobytes. There are a several specific changes that are required for tuning the Gateway appliance to handle larger messages.


    Several settings and configuration files must be changed in order to meet this use case:

    1. The amount of system memory allocated to Java application.
    2. Cluster-wide properties that negotiate various maximum data sizes.
    3. Certain policy changes to limit message sizes.

    Java memory allocation

    1. Log in to the API Gateway appliance as the ssgconfig user.
    2. Select Option #3: Use a privileged shell (root).
    3. Open /opt/SecureSpan/Gateway/runtime/etc/profile.d/ in a text editor.
    4. Modify the file to appear as below (starting at line #29 as of version 8.0.0 of the Gateway):

    #if [ `expr $java_ram \> 2074412` == 1 ] ; then

    #    if [ $usebigmemory -eq 1 ]; then


    # we have more ram than java can use


    # FIXME: when we start running 64 bit JVM

    #            java_ram=2074412;

    #            # CAP at 2 gigs

    #    else   

    #        java_ram=4194304;

    #    fi


    1. Save the file and exit the text editor
    2. Restart the Gateway application

    Cluster-Wide Properties

    Log in to the CA API Gateway Policy Manager as an administrative user.
    Open the Manage Cluster-Wide Properties task
    Add or edit the following properties:

    1. io.signedPartMaxBytes = 0
    2. io.xmlPartMaxBytes = 0
    3. request.compress.gzip.allow = true
    4. response.compress.gzip.allow = true

    There are also two additional cluster-wide properties that need to be set with customized values:

    1. template.partBodyMaxSize
    2. attachment.diskThreshold

    template.partBodyMaxSize specifies the maximum amount of memory to use for storing message parts. The value of this property should meet or exceed the maximum expected size of an individual message part. Setting this property to a value that exceeds the total size of the message should be sufficient.attachment.diskThreshold specifies the maximum size of a message attachment to store in memory before stashing it to disk. If a message attachment exceeds the size of this value then the attachment will be stashed to disk. This value should meet or exceed the maximum total size of any individual message attachments for MTOM or Soap With Attachments.

    Policy Changes

    In some circumstances, it may be necessary to change one or more service policies or global policy fragments to minimize the risk of globally increasing the maximum message and attachment thresholds. There are a few factors that are at play with respect to this behavior and what hsould be changed. The following items must be taken into consideration:

    1. The current value of io.xmlMaxPartBytes
    2. The current use of the Limit Message Size assertion
    3. Whether or not Perform WS-Security Processing is enabled for a particular service
    4. Whether or not the service policy acts upon the request or response message

    If the service policy acts upon a request or response message that exceeds io.xmlMaxPartBytes then the request will fail. Acts upon includes but is not limited to: Any threat protection assertion, XPath evaluation, regular expression evaluation, message transformation. This limitation is overridden by using Limit Message Size assertion. The Gateway will enforce the message size on a per-service basis as long as that assertion is used. The assertion is overridden by enabling "Perform WS-Security Processing..." within the Service Properties dialog. If this is enabled then io.xmlMaxPartBytes overrides the value of Limit Message Size assertion. This occurs because the WS-Security processing specified above occurs before the service policy itself (and before Limit Message Size would take over as the authority).

    Below are some examples to illustrate the interaction of these changes:

    1. If a service policy streams the request or response and does not act upon the message then the Gateway does not limit the size of a message. Assertions are only necessary to shield a protected service from attack relying upon message size.
    2. If a service policy performs message transformation or evaluation then the policy should use the Limit Message Size assertion to set the maximum size on a per-service basis.
    3. If a Gateway will always handle large messages and inspect, evaluate, or transform the request or response--regardless of the published service being consumed--then set io.xmlMaxPartBytes to an adequately large number.
    4. If a service on the Gateway requires WS-Security processing then set io.xmlMaxPartBytes to an adequately large number.
    5. If multiple services on the Gateway require WS-Security processing then publish a "pre-security" global policy fragment and add the Limit Message Size assertion.

  • 6.  Re: Optimize for mixed workload APIs (Large and Small payloads)

    Posted Oct 13, 2015 11:29 AM

    While we appreciate you making this available--I would like to request that it is removed for the time being. If we make changes to the document I referenced then the old editions will be published and archived here. This means that a version of this document would exist that we are not able to adjust as circumstances change.


    The CA Support organization is currently working on moving existing knowledge base artifacts between the legacy Layer 7 Technologies case management system and CA Support Online. Your assistance with this is greatly appreciated!



  • 7.  Re: Optimize for mixed workload APIs (Large and Small payloads)

    Broadcom Employee
    Posted Sep 29, 2015 11:40 PM

    You can "Sort of" configure gateway for both large (and seldom) message processing and small (and often). The main thing you need is lots of RAM, and you should likely segregate the slow traffic into a separate inbound connection pool so the slow pokes don't use up the entire inbound threadpool.


    Given that your payloads are Binary, it's less of an API and more a managed file transfer system. What's the content of the large message and what do you expect to do with it? Binary is kind of a 2nd class citizen in gateway.

  • 8.  Re: Optimize for mixed workload APIs (Large and Small payloads)

    Posted Sep 29, 2015 11:53 PM

    Nice idea. Interesting idea about separate connection pool. Are you talking about using a different "Port" in the Gateway or a lower-level (Linux config)? Also, if it is "Port" would you separate onto a different Thread Pool?


    We have 96Gb of RAM per machine so lots of space to work with.


    It is indeed a file upload: resumes in this case. We POST and GET through REST endpoints. Gateway will Authenticate both using oAuth2.

  • 9.  Re: Optimize for mixed workload APIs (Large and Small payloads)

    Broadcom Employee
    Posted Oct 06, 2015 01:38 PM

    Yes, different listen port with dedicated connection pool. Manage Listen Ports dialog.


    File Uploads require careful choices around max message size and some of the cluster properties, or the gateway will buffer to disk and that has performance implications if this happens a lot. Disk IO bandwidth is limited.