The problem with setting it in code is that the setting is dependent on
hardware configuration.
Please don't assume no one is using it. I use it, Adam (the code author)
uses it, and I encourage my development staff to use it.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 9/25/2014 10:34 AM, Jacopo Cappellato wrote:
Thank you Adrian, it is interesting!
Unfortunately I don't have time to look at the details at the moment but I will
follow up with some comments as I will find some time; in the meantime please
see below:
On Sep 25, 2014, at 11:15 AM, Adrian Crum <[email protected]>
wrote:
With your previous change, 12 CPUs = 12 threads = n * 2. The data load took
twice as long as when I was able to configure it for 4 threads.
The main goal of my changes was to shutdown the threads after they have
completed their job at bootstrap; this is now true; the side effect of my first
commit has been that of running more threads for the dbCheck task, instead of
just run it with 1 as it was before (with default configuration); after my
second commit, based on your feedback, at bootstrap the system behaves as
before my changes, still shutting down the threads when done.
I really didn't care too much about startup times but rather of resource
utilization after the bootstrap.
I still think that the max-worker-pool-size is a too low level setting that just controls
the number of threads for the dbCheck task and it doesn't make much sense to have it in
the datasource configuration... I doubt that many users are actually setting it and so
everyone is running with the default of 1 thread for the dbCheck task... which is
actually fine (and probably better than using a numOfProcessor threads) but in my opinion
we could get rid of this "configuration" option and set it in code. But at this
point it is not too much important to me and we can revisit this at a later point in time.
Jacopo
