You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Mark DeLaFranier <de...@hotmail.com> on 2006/10/27 05:47:17 UTC
Client Connection (socket) Pooling & Server Reuse.
Hey guys,
I am sorta informally looking at the performance of OpenEJB. Now I am
certainly not trying to open a can of worms here. :-) An idea that I
am currently playing with is to modify the client so that it can re-use
an existing open socket connection to the server rather then doing
open-write-read-close and at the same time, the server will loop and
keep reading requests from the same socket.
My first thought was to enhance the OEJP to support "headers" like HTTP
does and then use the "keepalive" idea. I bumped up the OEJP version to
2.1 so that the client/server would know to check for the existance of
headers in the request/response. The marshalled headers would be in the
format of:
Existing structure: [OEJP/2.0][request-id][request-data]
New structure:
[OEJP/2.1][#-of-headers][headers][request-id][request-data] where
headers is [len][name-data][len][value-data]
This saved, combined with socket pooling, approx. 34%
My second thought was to avoid the NVP headers and use a byte array of
bit flags, the new format is:
[OEJP/2.1][byte-of-flags][request-id][request-data]
This is 27% faster then my first thought.
I like to carry this forward a little more, but I would like to peoples
thoughts on this first.
Thanks
Mark
Re: Client Connection (socket) Pooling & Server Reuse.
Posted by Dain Sundstrom <da...@iq80.com>.
One more thing. Can you share your benchmark? I would love to have
a way to compare the efficiency of one protocol to another, or to
quantify the improvement (or degradation) from a single change?
-dain
On Oct 27, 2006, at 7:50 PM, Mark DeLaFranier wrote:
> I should have mentioned -- time :-)
> I'll post a follow up next week. I have to look in an issue with a
> multithreaded test that is being run.
>
> What are you thoughts on how to go about client side setting of
> configuration properties?
>
> For example, a few ideas I have:
>
> 1. A client may wish to disable the keep alive feature
> 2. A client may wish to enable some protocol tracing that I have
> implemented
> 3. How would a client alter the number of pooled connections?
> 4. How would a client alter the instance timeout for pooled
> connection?
> 5. How many times would a client retry before giving up?
>
> Currently, I am configuring some of the above based on a system
> properties that beings with "org.apache.openejb":
>
> 1. org.apache.openejb.protocol.keepalive=[true] / false
> 2. org.apache.openejb.protocol.trace=true / [false]
> 3. org.apache.openejb.client.socket.pool.max.size= ?
> 4. org.apache.openejb.client.socket.pool.timeout=60 (seconds)
> 5. org.apache.openejb.client.socket.retrycount=5
>
> Setting a custom property in the InitialContext creation is an
> idea, but the catch here is that the connection pool is tied to the
> client process not the initial context object.
>
> Suggestions welcome.
>
> Mark
>
> Dain Sundstrom wrote:
>> This is very cool. When you are measuring a savings what are you
>> saving? time, cpu, bites on the wire...
>>
>> -dain
>>
>> On Oct 26, 2006, at 8:47 PM, Mark DeLaFranier wrote:
>>
>>> Hey guys,
>>>
>>> I am sorta informally looking at the performance of OpenEJB. Now
>>> I am certainly not trying to open a can of worms here. :-) An
>>> idea that I am currently playing with is to modify the client so
>>> that it can re-use an existing open socket connection to the
>>> server rather then doing open-write-read-close and at the same
>>> time, the server will loop and keep reading requests from the
>>> same socket.
>>>
>>> My first thought was to enhance the OEJP to support "headers"
>>> like HTTP does and then use the "keepalive" idea. I bumped up
>>> the OEJP version to 2.1 so that the client/server would know to
>>> check for the existance of headers in the request/response. The
>>> marshalled headers would be in the format of:
>>>
>>> Existing structure: [OEJP/2.0][request-id][request-data]
>>> New structure: [OEJP/2.1][#-of-headers][headers][request-id]
>>> [request-data] where headers is [len][name-data][len][value-data]
>>>
>>> This saved, combined with socket pooling, approx. 34%
>>>
>>> My second thought was to avoid the NVP headers and use a byte
>>> array of bit flags, the new format is:
>>>
>>> [OEJP/2.1][byte-of-flags][request-id][request-data]
>>>
>>> This is 27% faster then my first thought.
>>>
>>> I like to carry this forward a little more, but I would like to
>>> peoples thoughts on this first.
>>>
>>> Thanks
>>> Mark
>>>
>>>
>>
>>
>>
>
Re: Client Connection (socket) Pooling & Server Reuse.
Posted by Mark DeLaFranier <de...@hotmail.com>.
I should have mentioned -- time :-)
I'll post a follow up next week. I have to look in an issue with a
multithreaded test that is being run.
What are you thoughts on how to go about client side setting of
configuration properties?
For example, a few ideas I have:
1. A client may wish to disable the keep alive feature
2. A client may wish to enable some protocol tracing that I have implemented
3. How would a client alter the number of pooled connections?
4. How would a client alter the instance timeout for pooled connection?
5. How many times would a client retry before giving up?
Currently, I am configuring some of the above based on a system
properties that beings with "org.apache.openejb":
1. org.apache.openejb.protocol.keepalive=[true] / false
2. org.apache.openejb.protocol.trace=true / [false]
3. org.apache.openejb.client.socket.pool.max.size= ?
4. org.apache.openejb.client.socket.pool.timeout=60 (seconds)
5. org.apache.openejb.client.socket.retrycount=5
Setting a custom property in the InitialContext creation is an idea, but
the catch here is that the connection pool is tied to the client process
not the initial context object.
Suggestions welcome.
Mark
Dain Sundstrom wrote:
> This is very cool. When you are measuring a savings what are you
> saving? time, cpu, bites on the wire...
>
> -dain
>
> On Oct 26, 2006, at 8:47 PM, Mark DeLaFranier wrote:
>
>> Hey guys,
>>
>> I am sorta informally looking at the performance of OpenEJB. Now I
>> am certainly not trying to open a can of worms here. :-) An idea
>> that I am currently playing with is to modify the client so that it
>> can re-use an existing open socket connection to the server rather
>> then doing open-write-read-close and at the same time, the server
>> will loop and keep reading requests from the same socket.
>>
>> My first thought was to enhance the OEJP to support "headers" like
>> HTTP does and then use the "keepalive" idea. I bumped up the OEJP
>> version to 2.1 so that the client/server would know to check for the
>> existance of headers in the request/response. The marshalled headers
>> would be in the format of:
>>
>> Existing structure: [OEJP/2.0][request-id][request-data]
>> New structure:
>> [OEJP/2.1][#-of-headers][headers][request-id][request-data] where
>> headers is [len][name-data][len][value-data]
>>
>> This saved, combined with socket pooling, approx. 34%
>>
>> My second thought was to avoid the NVP headers and use a byte array
>> of bit flags, the new format is:
>>
>> [OEJP/2.1][byte-of-flags][request-id][request-data]
>>
>> This is 27% faster then my first thought.
>>
>> I like to carry this forward a little more, but I would like to
>> peoples thoughts on this first.
>>
>> Thanks
>> Mark
>>
>>
>
>
>
Re: Client Connection (socket) Pooling & Server Reuse.
Posted by David Blevins <da...@visi.com>.
On Fri, Oct 27, 2006 at 10:50:17PM -0400, Mark DeLaFranier wrote:
> I should have mentioned -- time :-)
>
> I'll post a follow up next week. I have to look in an issue with a
> multithreaded test that is being run.
>
> What are you thoughts on how to go about client side setting of
> configuration properties?
>
> For example, a few ideas I have:
>
> 1. A client may wish to disable the keep alive feature
> 2. A client may wish to enable some protocol tracing that I have implemented
> 3. How would a client alter the number of pooled connections?
> 4. How would a client alter the instance timeout for pooled connection?
> 5. How many times would a client retry before giving up?
>
> Currently, I am configuring some of the above based on a system
> properties that beings with "org.apache.openejb":
>
> 1. org.apache.openejb.protocol.keepalive=[true] / false
> 2. org.apache.openejb.protocol.trace=true / [false]
> 3. org.apache.openejb.client.socket.pool.max.size= ?
> 4. org.apache.openejb.client.socket.pool.timeout=60 (seconds)
> 5. org.apache.openejb.client.socket.retrycount=5
What you've outlined is pretty good. I'd go with 'openejb' over 'org.apache.openejb' just to keep consistent with our other properties.
> Setting a custom property in the InitialContext creation is an idea, but
> the catch here is that the connection pool is tied to the client process
> not the initial context object.
That's good for now. Things are a bit different in the 3 branch. There the ServerMetaData object contains a URI which would be a great place for us to put more connection configuration oriented stuff.
Take a quick peek at:
http://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/server/openejb-client/src/main/java/org/apache/openejb/client/ConnectionManager.java
http://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/server/openejb-client/src/main/java/org/apache/openejb/client/HttpConnectionFactory.java
If you wanted to back port the URI change from 3 to 2 that'd be cool with me. Then you could stuff the connection config in the URI as query params.
-David
>
> Suggestions welcome.
>
> Mark
>
> Dain Sundstrom wrote:
> >This is very cool. When you are measuring a savings what are you
> >saving? time, cpu, bites on the wire...
> >
> >-dain
> >
> >On Oct 26, 2006, at 8:47 PM, Mark DeLaFranier wrote:
> >
> >>Hey guys,
> >>
> >>I am sorta informally looking at the performance of OpenEJB. Now I
> >>am certainly not trying to open a can of worms here. :-) An idea
> >>that I am currently playing with is to modify the client so that it
> >>can re-use an existing open socket connection to the server rather
> >>then doing open-write-read-close and at the same time, the server
> >>will loop and keep reading requests from the same socket.
> >>
> >>My first thought was to enhance the OEJP to support "headers" like
> >>HTTP does and then use the "keepalive" idea. I bumped up the OEJP
> >>version to 2.1 so that the client/server would know to check for the
> >>existance of headers in the request/response. The marshalled headers
> >>would be in the format of:
> >>
> >>Existing structure: [OEJP/2.0][request-id][request-data]
> >>New structure:
> >>[OEJP/2.1][#-of-headers][headers][request-id][request-data] where
> >>headers is [len][name-data][len][value-data]
> >>
> >>This saved, combined with socket pooling, approx. 34%
> >>
> >>My second thought was to avoid the NVP headers and use a byte array
> >>of bit flags, the new format is:
> >>
> >>[OEJP/2.1][byte-of-flags][request-id][request-data]
> >>
> >>This is 27% faster then my first thought.
> >>
> >>I like to carry this forward a little more, but I would like to
> >>peoples thoughts on this first.
> >>
> >>Thanks
> >>Mark
> >>
> >>
> >
> >
> >
>
Re: Client Connection (socket) Pooling & Server Reuse.
Posted by Dain Sundstrom <da...@iq80.com>.
This is very cool. When you are measuring a savings what are you
saving? time, cpu, bites on the wire...
-dain
On Oct 26, 2006, at 8:47 PM, Mark DeLaFranier wrote:
> Hey guys,
>
> I am sorta informally looking at the performance of OpenEJB. Now I
> am certainly not trying to open a can of worms here. :-) An idea
> that I am currently playing with is to modify the client so that it
> can re-use an existing open socket connection to the server rather
> then doing open-write-read-close and at the same time, the server
> will loop and keep reading requests from the same socket.
>
> My first thought was to enhance the OEJP to support "headers" like
> HTTP does and then use the "keepalive" idea. I bumped up the OEJP
> version to 2.1 so that the client/server would know to check for
> the existance of headers in the request/response. The marshalled
> headers would be in the format of:
>
> Existing structure: [OEJP/2.0][request-id][request-data]
> New structure: [OEJP/2.1][#-of-headers][headers][request-id]
> [request-data] where headers is [len][name-data][len][value-data]
>
> This saved, combined with socket pooling, approx. 34%
>
> My second thought was to avoid the NVP headers and use a byte array
> of bit flags, the new format is:
>
> [OEJP/2.1][byte-of-flags][request-id][request-data]
>
> This is 27% faster then my first thought.
>
> I like to carry this forward a little more, but I would like to
> peoples thoughts on this first.
>
> Thanks
> Mark
>
>
Re: Client Connection (socket) Pooling & Server Reuse.
Posted by David Blevins <da...@visi.com>.
On Oct 26, 2006, at 10:24 PM, David Blevins wrote:
>> My first thought was to enhance the OEJP to support "headers" like
>> HTTP does and then use the "keepalive" idea. I bumped up the OEJP
>> version to 2.1 so that the client/server would know to check for
>> the existance of headers in the request/response. The marshalled
>> headers would be in the format of:
>>
>> Existing structure: [OEJP/2.0][request-id][request-data]
>> New structure: [OEJP/2.1][#-of-headers][headers][request-id]
>> [request-data] where headers is [len][name-data][len][value-data]
>>
>> This saved, combined with socket pooling, approx. 34%
>>
>> My second thought was to avoid the NVP headers and use a byte
>> array of bit flags, the new format is:
>>
>> [OEJP/2.1][byte-of-flags][request-id][request-data]
>>
>> This is 27% faster then my first thought.
>>
>
> Can you give more info on the byte approach? Not grokking why it's
> slower than bytes of "string" data
>
> What is the nature of your NVP? What would be the data type of the
> name and of the value?
Any thoughts?
-David
Re: Client Connection (socket) Pooling & Server Reuse.
Posted by David Blevins <da...@visi.com>.
On Oct 26, 2006, at 8:47 PM, Mark DeLaFranier wrote:
> Hey guys,
>
> I am sorta informally looking at the performance of OpenEJB. Now I
> am certainly not trying to open a can of worms here. :-) An idea
> that I am currently playing with is to modify the client so that it
> can re-use an existing open socket connection to the server rather
> then doing open-write-read-close and at the same time, the server
> will loop and keep reading requests from the same socket.
This is excellent. I've wanted to fix this for a very long time but
wasn't a can of worms I wanted to open till someone complained.
Well, a couple people have complained, but your the first with
time... so you win!
> My first thought was to enhance the OEJP to support "headers" like
> HTTP does and then use the "keepalive" idea. I bumped up the OEJP
> version to 2.1 so that the client/server would know to check for
> the existance of headers in the request/response. The marshalled
> headers would be in the format of:
>
> Existing structure: [OEJP/2.0][request-id][request-data]
> New structure: [OEJP/2.1][#-of-headers][headers][request-id]
> [request-data] where headers is [len][name-data][len][value-data]
>
> This saved, combined with socket pooling, approx. 34%
>
> My second thought was to avoid the NVP headers and use a byte array
> of bit flags, the new format is:
>
> [OEJP/2.1][byte-of-flags][request-id][request-data]
>
> This is 27% faster then my first thought.
>
Can you give more info on the byte approach? Not grokking why it's
slower than bytes of "string" data
What is the nature of your NVP? What would be the data type of the
name and of the value?
-David