4 Replies Latest reply on Sep 22, 2009 10:41 AM by andy.miller Branched to a new discussion.

ThreadLocalPool - Is it working the way we think?

andy.miller Sep 21, 2009 4:22 PM

I'm starting this thread because I have been bothered for awhile about this instance pool.

In two situations (both of which I cannot reference publicly, but anyone wants to have a private conversation I can explain), where we switched from the ThreadLocalPool to StrictMaxPool throughput of a large scale test improved.

On the surface it appears that using a ThreadLocal is just adding overhead, and not providing any real benefit.

In looking at the code, it appears we don't get any of the benefits of using a ThreadLocal, where you shouldn't need any synchronization, and are just adding overhead with the get calls to access the pool.

This seems like the wrong use case for using ThreadLocal to me.

Thoughts?

1. Re: ThreadLocalPool - Is it working the way we think?

alrubinger Sep 21, 2009 5:49 PM (in response to andy.miller)

Do you feel this is more in part due to the ThreadLocal implementation of the pool, or the fact that it's unbounded (==we spread things too thin)?

S,
ALR
Actions
2. Re: ThreadLocalPool - Is it working the way we think?

andy.miller Sep 21, 2009 6:57 PM (in response to andy.miller)

"ALRubinger" wrote:
Do you feel this is more in part due to the ThreadLocal implementation of the pool, or the fact that it's unbounded (==we spread things too thin)?

S,
ALR

Actually, I think its because of the ThreadLocal implementation. For example, in one of the cases where we switched the configuration to use the StrictMaxPool, I had to set it to 6 million to get rid of the timeouts, and throughput still went up. In the other case, the configuration was only 100 (on both ThreadLocalPool and StrictMaxPool), and throughput increase by 300 transactions per second.
Actions
3. Re: ThreadLocalPool - Is it working the way we think?

wolfc Sep 22, 2009 5:53 AM (in response to andy.miller)

Two issues:
1. the original ThreadlocalPool was designed incur zero thread contention. This changed when statistics were implemented. Right now that uses sync blocks, but it could be changed to atomics. Still it would incur a penalty.
2. a ThreadlocalPool servicing a ThreadPool with a size > 100 will always have a lower throughput than a StrictMaxPool with maximum size 100. The maximum size of ThreadlocalPool is not applicable.

To really identify performance bottlenecks within enterprise beans you would need to know:
- average queue size
- average execution time
- average wait time

We also need to microbench all the pool implementations to see their effect on throughput & average response time.
Actions
4. Re: ThreadLocalPool - Is it working the way we think?

andy.miller Sep 22, 2009 10:41 AM (in response to andy.miller)

"wolfc" wrote:
Two issues:
1. the original ThreadlocalPool was designed incur zero thread contention. This changed when statistics were implemented. Right now that uses sync blocks, but it could be changed to atomics. Still it would incur a penalty.
2. a ThreadlocalPool servicing a ThreadPool with a size > 100 will always have a lower throughput than a StrictMaxPool with maximum size 100. The maximum size of ThreadlocalPool is not applicable.

To really identify performance bottlenecks within enterprise beans you would need to know:
- average queue size
- average execution time
- average wait time

We also need to microbench all the pool implementations to see their effect on throughput & average response time.

Yes, the statistics require synchronization, which is part of the point. If you need the statistics, then you lose the benefits of it being a ThreadLocal.

I also seem to remember that it also synchronizes on the ArrayList for the instance references too though.
Actions

Go to original post