Closed GoogleCodeExporter closed 9 years ago
The following unit tests had to have their wait times bumped up from 20ms to
80ms to make test pass for TaskThreadManager. This tells me that the
ManualThreadManager is still much faster getting work done. Just need to test
what it costs in memory and cpu to create new threads all the time.
ThreadManagerTest.DoWork_WorkItemsEqualToThreads_WorkIsCompletedAsync()
ThreadManagerTest.DoWork_MoreWorkThenThreads_WorkIsCompletedAsync()
Original comment by sjdir...@gmail.com
on 4 May 2013 at 12:12
If this becomes the default pass in the _crawlContext.CancellationSourceToken
into the TaskThreadManager's constructor to be able to cancel everything in
unison.
Original comment by sjdir...@gmail.com
on 4 May 2013 at 12:16
While observing the running of the integration tests I noticed that the
ManualThreadManager would peek its cpu usage at 100% the last 5 seconds before
completing the integration tests. The TaskThreadManager peeks at about 68%.
Both implementations ran the integration tests in about 35-36 seconds
consistently.
Looks like the ManualThread manager still is a little more performant than
TaskThreadManager but does use more cpu. Haven't made a decision on which
should be default. I suspect the TaskThreadManager will not work as well as
ManaualThreadManager when many instances of PoliteWebCrawler have been created.
Seems like thread pool threads take a while to get scheduled.
Original comment by sjdir...@gmail.com
on 4 May 2013 at 4:47
Adding to my last comment...
I think the TaskThreadManager has proven to be stable and safe but will need to
do the multiple instance test to see if one or the other handles it better.
Original comment by sjdir...@gmail.com
on 4 May 2013 at 4:48
This issue was closed by revision r534.
Original comment by sjdir...@gmail.com
on 27 Jun 2013 at 6:12
Original issue reported on code.google.com by
sjdir...@gmail.com
on 2 May 2013 at 10:58