CXF How to improve WebService performance and access speed tuning

Performance:
 
1. Enable Fastinfoset (Quick Info Set)
The performance of WebService is really not flattering. Once because of the webservice throughput, the webservice carried out some performance optimization, the use of fastinfoset, the effect is obvious, extreme conditions of large data transfer, performance increased by 60%, he can reduce transmission costs, serialization costs and XML parsing costs.
CXF provides the fastinfoset negotiation mechanism, implements the class see Org.apache.cxf.feature.FastInfosetFeature, enables the following configuration in the bus:
<cxf:features><cxf:fastinfoset force= "false"/></cxf:features>
Force=false Indicates whether Fastinfoset support is enabled for the first communication between the server and the client (by checking the Accept field of the standard HTTP header and the value of the MIME type of Application/fastinfoset). If the client is not supported, fast information sets are not enabled.
You need to add dependencies in the POM:
<dependency>
<groupId>com.sun.xml.fastinfoset</groupId>
<artifactId>FastInfoset</artifactId>
<version>1.2.9</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
Fastinfoset Reference: http://java.sun.com/developer/technicalArticles/xml/fastinfoset/
Both client and service side must be configured
2. Enable GZIP compression support
Whether the client and server side use gzip compression is also based on HTTP protocol negotiation (check the request header for Accept-encoding:gzip). But it needs to be weighed carefully. For small data volumes, enabling gzip compression support is a thankless behavior, when the amount of data is small, gzip compression results are not obvious, but also a waste of CPU. We need to weigh the size of the data and set threshold to 10*1024byte based on experience.
Enable the following configuration in the bus:
<bean class= "Org.apache.cxf.transport.common.gzip.GZIPFeature" >
<property name= "Threshold" ><value>10240</value></property>
</bean>
Official documentation Specifies that the configuration is org.apache.cxf.transport.http.gzip.GZIPFeature, but this class will not be found and may be an official document that has been in disrepair for some time, causing some confusion. You are not prompted to specify threshold in the official documentation, please refer to Gzipfeature source code.
Reference http://cxf.apache.org/docs/featureslist.html
 
3. Use SLF4J instead of CXF default log component
CXF default use of java.util.logging as a log printing component, its performance I do not too much evaluation, nor is it easy for us to do unified log management. The current system uses SLF4J as the log print component, replaced by the following:
Add Meta-inf/cxf/org.apache.cxf.logger file to Classpath, file content is
Org.apache.cxf.common.logging.Slf4jLogger
4. Enable Logging in test
Add <cxf:logging/&gt in the bus, enable the debug in the test environment

Add:
1, how to customize the return code:
After the request has encountered an exception in the service, it invokes the Handlefault method of all interceptors in the request chain, references Phaseinterceptorchain#unwind, and then determines whether the request is a one-way request, and if not, constructs the exception request chain, and constructs an exception message object that invokes the Handlemessage method in the exception request chain (reference: Abstractfaultchaininitiatorobserver)
Jaxwsmethodinvoker the method that forwards the SOAP request to the specified object, if the request processing fails, calls the Updateheader method and puts the SOAP header in the return header when the request is made. However, the SOAP header also returns to the client by inheriting Jaxwsmethodinvoker to clear the exception, because Jaxwsmethodinvoker does not use an injection mechanism (jaxwsserverfactorybean# Createinvoker) also has no chain. When an exception occurs, the return request is processed by these interceptors:
Setup [Serverpolicyoutfaultinterceptor]
Prepare-send [Messagesenderinterceptor, Soap11faultoutinterceptor]
Pre-stream [Loggingoutinterceptor, Staxoutinterceptor]
Pre-protocol [Webfaultoutinterceptor]
Write [Soapoutinterceptor]
Interceptor Initialization Class Outfaultchaininitiatorobserver
We can add the Interceptor Soapheaderoutfilterinterceptor, which cleans up the SOAP header in the exception chain, to clean up the problem of having information in the SoapHeader when the system is out of the ordinary.
Returns an error status code that was written to die in the execution of the Soap11faultoutinterceptor interceptor.
Message.put (Org.apache.cxf.message.Message.RESPONSE_CODE, New Integer (500));
To have an error code in the return data, you need to add an interceptor after the Soap11faultoutinterceptor
 
2, in the project test encountered an error invalid LOC header (bad signature), this problem is due to the jar package damage, although the build path has this jar, but there will still be loadclass failure, cleanup maven The jar for the local repository directory, modifying the POM (such as adding a blank line) to let the m2e reload.
3, CXF has a very good feature, support JavaScript access to SOAP WebService, client access Http://localhost:8080/cxf/HelloWorld?js similar requests, will generate JavaScript Client, JS programming can use this client-provided object, enabling this feature requires the introduction of the

<import resource= "Classpath:meta-inf/cxf/cxf-extension-javascript-client.xml"/> and joins in the dependency:
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-javascript</artifactId>
<version>2.4.1</version>
<type>jar</type>
<scope>compile</scope>
</dependency>

CXF How to improve WebService performance and access speed tuning