d8fc079eee
The holds queue builder can take a very long time to run on systems with many holds. For example, a partner with 124,784 unfilled ( not found ) holds, is taking about 64 minutes to run. If we run that same number of holds in 5 parallel chunks ( splitting the number of records as evenly as possible, but *not* taking into account the holds per bib ), it takes 21.5 minutes. If we use 10 loops, it takes less then 14 minutes. Test Plan: 0) Install the Perl library Parallel::ForkManager 1) Generate a huge number of holds ( a few thousand at the minimum ) 2) Run the holds queue builder, use the `time` utility to track how much time it took to run 3) Set HoldsQueueParallelLoopsCount to 10 4) Repeat step 2, note the improvement in speed 5) Experiment with other values for HoldsQueueParallelLoopsCount 6) prove t/db_dependent/HoldsQueue.t Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> |
||
|---|---|---|
| .. | ||
| README | ||
| bug_28833.perl | ||
| skeleton.pl | ||
README
Please put your database revision files in this folder. The Release Manager will remove them here when pushing your patches. To use the skeleton .perl for your update: % cp installer/data/mysql/atomicupdate/skeleton.perl installer/data/mysql/atomicupdate/bug_XXXXX.perl and put your modifications in where noted.