Jacques Le Roux wrote:
From: "Adrian Crum" <[email protected]>
Adam Heath wrote:
Adrian Crum wrote:
Adam Heath wrote:
Adrian Crum wrote:
The java.util.concurrent package rocks! I used it a few weeks ago to
multi-thread the demo data loading code. I got it down from 3
minutes to
1.5 minutes.
What? You made the ofbiz demo data loading code multi-threaded?
Seriously? If so, that rocks!
I used a thread pool to create tables and non-fk indexes. By fine
tuning
the thread count, I was able to take the single-threaded CPU usage from
12-20% up to 50-90%. I used a FIFO queue for loading data - the main
thread parses the XML files and places DOM Elements in the queue, and
another thread takes the elements from the queue and stores them in the
database.
Some day I'll clean up the code and provide a patch. It only benefits
multi-CPU computers.
import java.lang.management.ManagementFactory;
int workerCount =
ManagementFactory.getOperatingSystemMXBean().getAvailableProcessors();
The patch would be for educational purposes. If the community ever
decided to introduce multi-threading to the framework, it would have
to be controlled by configuration settings - because not all
installations would benefit from it.
But would it impair them ?
Sun warns that multi-threading in some situations actually slows things
down. I discovered that by using the patch on a single CPU system. The
settings that doubled throughput on my multi-CPU machine halved the
throughput on the singe CPU machine. Even after tweaking the settings, I
wasn't able to gain much on that platform.
-Adrian
