Tune the Web services gateway
Overview
For information on tuning the appserver, see Tuning performance.
Overview
To tune the gateway, implement as appropriate the performance enhancements described in the following list:
- Using the file:///filename notation for locally-stored WSDL files
If you are passing an address for a WSDL file into the gateway, and the WSDL is stored locally, then use the file:///filename notation rather than drive letter:/filename because file:///filename is more performant.
- Reviewing the gateway storage requirements
The amount of storage (memory) that the gateway occupies depends upon the number of resources defined (channels, services, filters and so on). The complexity of the WSDL also affects the storage requirements for each Web service. If the resources you deploy to the gateway grow over time, review the heap size accordingly.
Although the Java heap storage requirement for each gateway-deployed service is small, if you deploy a large number of services or services with a large number of targets then you can significantly increase the heap space required to run the gateway efficiently. As well as the heap space required for the resource definitions, a large amount of additional heap space is occupied by resource objects instantiated when each service is invoked. The more deployed services or targets that are invoked, the more heap space is required by the gateway for the reusable elements of those services or targets.
The measurements in the following table estimate the Java heap storage space used by the gateway. These measurements were taken for a heap with these settings:
The Web service defined was a simple case with one operation and no complex types.
- -Xms=256
- -Xmx=256
Resource Storage space Java heap requirements for the gateway with the following resources defined:
200KB
Java heap requirements for each additional Web service target defined.
1KB
Java heap requirements for each Web service at runtime (that is, those components that are cached for future use and not eligible for garbage collection).
1.2MB for first invocation
100KB for each additional target invoked
These measurements are provided for illustrative purposes only. To review the gateway storage requirements for your environment, take your own measurements for that environment according to the formula described in the next paragraph.
For each Web service defined to the gateway, and for each service subsequently invoked, the Java heap working set is increased. The increase in heap occupancy is a function of base gateway requirements, plus the number of Web services defined, plus the number of unique Web services invoked during the lifetime of the gateway. This can be expressed as:
gateway_server_storage + n*def + rdef1 + n2*rdef2where:
- gateway_server_storage is the start-up footprint of the gateway server (not measured in the preceding table), plus any basic deployments of channels, filters and so on (200KB in the preceding table). This startup storage requirement varies depending upon factors such as the initial configuration of the server, and whether or not any other applications are running.
- n is the number of Web services (or targets) defined.
- def is the number of bytes used for each definition.
- rdef1 is the number of bytes used for the first invocation of the Web service.
- n2 is the number of unique Web services (or targets) executed during the lifetime of the gateway.
- rdef2 is the number of bytes used for each additional invocation of a unique Web service target (that is, those objects for each target that are cached for future use and not eligible for garbage collection).
- Setting application class-loader policy to enable local EJB calls
Every request that arrives at a channel is passed by the channel to the gateway. This communication is made through either a remote or a local EJB call. If you set the application class-loader policy for the appserver to MULTIPLE, then this forces a remote EJB call and the request has to be serialized then de-serialized. If you set the application class-loader policy to SINGLE, then the channel makes a local call and passes the request by reference.
If you set the application class-loader policy to SINGLE, then the gateway can also call a filter through a local EJB call, provided that the filter has been written to provide the local interfaces.
- Enabling selective SOAP parsing
When you enable selective SOAP parsing for a specific Web service, the gateway only parses the headers of an incoming message for that service. The message body is passed through unchecked. Enable this option, as described in Deploying Web services to the Web services gateway, if you need to optimize the speed at which messages pass through the gateway. For selective SOAP parsing to work, the application class-loader policy for the appserver must be set to SINGLE.
For more information, see Selective SOAP parsing.
Enabling Web services through the Web services gateway