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
