I'm unsure whether SSL does any compression of its own, I would guess it would in order to minimize the amount of time needed to encrypt. You might wish to check if there's any real performance difference between SSL and SSL + gzip.

Glen

On 03/12/2013 09:56 PM, Ted wrote:
thanks all, it appears in http using wireshark (finally got it to show
me what I wanted) it is doing what is expected. Https... well too hard
for me to check so I'll just take it on faith that it works since it's
just a tomcat connector outside of what cxf/my application returns.




On 3/13/13, Ted <[email protected]> wrote:
thanks, I'd looked at the blog before, I don't believe it has anything
I haven't already implemented.

In terms of wireshark, I had also tried that before but none of the
contents were comprehensible to me so I was not really able to tell
what was or wasn't gzipped. I even moved it from https to http to try
to get the contents in a relatively "plain text" format so I can see
when it was not compressed and when it was, but I could never get the
plain text version so I was not able to determine a change... it's the
first time I'd used wireshark though, that's why I tried to look at
the header instead.

The header shows up on larger packets so I suspect at least for the
threshold problem on out bound messages, it should be an indication of
when it is and is not gzipped.

I'll spend some more time with wireshark and see if I can't figure out
how to use it a little better though. thanks.

On 3/13/13, Daniel Kulp <[email protected]> wrote:
Can you use wireshark or similar to get the raw transfer bytes?   I
believe
the GZIPInInterceptor would run before the LoggingInInterceptor.  Thus,
but
the time it gets to the logging interceptor, the payload has been
completely
un-gzipped and the Content-Encoding header stripped off.

Dan




On Mar 11, 2013, at 8:56 PM, Ted <[email protected]> wrote:

Thanks, I'm not trying to force the first one to be GZ, but the
problem is the second one doesn't appear to be GZ either.

Just to test it, I hard coded 2 identical calls in succession :

        
System.err.println(messageWs.getUnreadActiveMessageCount(loggedInInfo.getLoggedInPersonId()));
        
System.err.println(messageWs.getUnreadActiveMessageCount(loggedInInfo.getLoggedInPersonId()));

The out put from the logs appear to be non gz-ed :
        2013-03-12 11:31:14,818 INFO  [MessageWs:234] Inbound Message
        ----------------------------
        ID: 38
        Address: https://127.0.0.1:8091/myoscar_server/ws/MessageService
        Encoding: UTF-8
        Http-Method: POST
        Content-Type: text/xml; charset=UTF-8
        Headers: {Accept=[*/*], accept-encoding=[gzip;q=1.0, identity; q=0.5,
*;q=0], cache-control=[no-cache], connection=[keep-alive],
Content-Length=[785], content-type=[text/xml; charset=UTF-8],
host=[127.0.0.1:8091], pragma=[no-cache], SOAPAction=[""],
user-agent=[Apache CXF 2.7.3]}
        Payload: <soap:Envelope ... </soap:Envelope>
        --------------------------------------
        2013-03-12 11:31:14,834 INFO  [MessageWs:234] Outbound Message
        ---------------------------
        ID: 38
        Encoding: UTF-8
        Content-Type: text/xml
        Headers:
        Payload: <soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";><soap:Body><ns2:getUnreadActiveMessageCountResponse
xmlns:ns2="http://ws.myoscar_server.oscarehr.org/";><return>31</return></ns2:getUnreadActiveMessageCountResponse></soap:Body></soap:Envelope>
        --------------------------------------
        2013-03-12 11:31:14,841 INFO  [MessageWs:234] Inbound Message
        ----------------------------
        ID: 39
        Address: https://127.0.0.1:8091/myoscar_server/ws/MessageService
        Encoding: UTF-8
        Http-Method: POST
        Content-Type: text/xml; charset=UTF-8
        Headers: {Accept=[*/*], accept-encoding=[gzip;q=1.0, identity; q=0.5,
*;q=0], cache-control=[no-cache], connection=[keep-alive],
Content-Length=[785], content-type=[text/xml; charset=UTF-8],
host=[127.0.0.1:8091], pragma=[no-cache], SOAPAction=[""],
user-agent=[Apache CXF 2.7.3]}
        Payload: <soap:Envelope ... </soap:Envelope>
        --------------------------------------
        2013-03-12 11:31:14,855 INFO  [MessageWs:234] Outbound Message
        ---------------------------
        ID: 39
        Encoding: UTF-8
        Content-Type: text/xml
        Headers:
        Payload: <soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";><soap:Body><ns2:getUnreadActiveMessageCountResponse
xmlns:ns2="http://ws.myoscar_server.oscarehr.org/";><return>31</return></ns2:getUnreadActiveMessageCountResponse></soap:Body></soap:Envelope>
        --------------------------------------


I'm assuming I should have seen a "Content-Encoding=[gzip]" in the
header somewhere if it were gz-ed?

Just to see if it's related to the 1k theshold problem, I did a 4k
message test too, still same header results, no gz.

I also tried your suggestion just to test :

        GZIPOutInterceptor x = new GZIPOutInterceptor(100);
        x.setForce(true);
        System.err.println("----- JUST SET FORCE TRUE");
        cxfClient.getOutInterceptors().add(x);

still the same results. Is it suppose to show
"Content-Encoding=[gzip]" on the inbound requests? or is there another
way to check for gz?

Also the outbound requests are not taking the threshold into account,
it seems to be 1k no matter what I set it to. Notice the responses
from above are also missing the gzip entry in the header, I do get
those on larger outbound objects though so I know the setting is at
least taking effect sometimes.

On 3/12/13, Daniel Kulp <[email protected]> wrote:
By default, the GZIP out stuff on the client uses a "negotiated" method
where the first request is not-gzipped, but with the Accept-Encoding
header
since it does not know if the server knows how to handle a GZIP post.
If
the server responds with a GZIP response, subsequent requests from that
client will be gzipped.     Try making multiple calls with the same
client
object and see if the headers and such change.

You can force the first request to be gzipped by doing:

GZIPOutInterceptor gz = new GZIPOutInterceptor(128)
gz.setForce(true);
client.getOutInterceptors().add(gz);

Hope that helps!

Dan



On Mar 11, 2013, at 12:22 AM, Ted <[email protected]> wrote:

Hi I just tried gzip compression and it appears to be working in some
cases but not in others.
I'm on openjdk 1.7.0.3 and cxf 2.7.3 and tomcat 7.0.27.

On the server side I've set
        @GZIP(threshold=128)
on the web services

On the client I've set
        cxfClient.getInInterceptors().add(new GZIPInInterceptor());
        cxfClient.getOutInterceptors().add(new GZIPOutInterceptor(128));

I'm logging what's going on with the server with :
        <bean id="compressGZIPFeature"
class="org.apache.cxf.transport.common.gzip.GZIPFeature"/>
        <bean id="loggingFeature"
class="org.apache.cxf.feature.LoggingFeature"/>

        <cxf:bus>
                <cxf:features>
                        <ref bean="compressGZIPFeature"/>
                        <ref bean="loggingFeature"/>
                </cxf:features>
        </cxf:bus>

What I can see is the client is sending
        Headers: {Accept-Encoding=[gzip;q=1.0, identity; q=0.5, *;q=0]}

I can see if I have a large response (over 1k) I'm getting
        Headers: {Content-Encoding=[gzip], Vary=[Accept-Encoding]}

The 2 problems I'm having is

1) the 128 seems to have no effect, I even tried '0' as per the
documentation for always on, and it does seem to work. Small data is
just normal / no mention of gzip encoding like the large data

2) The requests being sent by the client do not appear to be gziped,
but honestly I'm not sure how to check or what header to look for.
Have I missed something in the configuration?

thanks
--
Ted.
--
Daniel Kulp
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com



--
Ted.
--
Daniel Kulp
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com



--
Ted.



Reply via email to