ThreadLocalPool - Is it working the way we think?

[andy.miller]

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?

[alrubinger]

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

[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.

[wolfc]

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.

[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.