对自动生成的URL，火车头考虑不足
比如直接生成5000个采集深度为0的地址，按ASP?=1..2..3这样排下来，火车头3.2会在很长一段时间内假死，系统出现“没有响应”的提示，其实后台在做事情，但是生成地址的速度非常慢，要10多分钟甚至更长才能生成5000个地址。我想应该不需要这么长时间的，因为采集地址测试的时候生成这些地址只要5-10秒。也许是火车头对这种情况考虑不足吧。另外占内存的问题解决了，但是3.2的采集速度确实下降了不少，即使在本地WEB上采也很慢，节奏上总跟小鸡啄米一样，是不是设置了两个任务之间的延时？ 分页采集地址的时候，如果页面数量达到20条x200页的规模，基本就会出于假死状态。如果正式采集地址的时候有象试采集那样的效率就好了。
[ 本帖最后由 heidian 于 2007-11-25 09:25 编辑 ] 这也要看机子的性能，分页的内容大小，分页多少~
像一篇100W字的小说，分页100页，那是相当吃力！ 我说的是分页列表采集。不是内容分页。
机器1G内存，双核3G的英特P4处理器，应该不差了。昨天试做了10000个链接地址的采集，到最后基本上是一分钟一条地址地采，CPU占用3-12之间。所以我觉得是设计上的考虑。 :( 我也发现了这个问题，很郁闷。
设置采集地址为0时，加入多页批量地址就慢得变成没有响应。。。。
电脑速度不受影响。 其中一个是access数据库插入效率的问题..建议官方更换access数据库为Sqlite数据库,在批量插入大数据的时候,适当的Thread.Sleep()一下..
回复 6楼 的帖子
新版为Sqlite数据库 现在好像还是类似的问题啊。自动生成地址的效率低得惊人，差不多一秒也就插入几十条的速度，自动生成10000条以上的地址时要假死相当长的时间（界面无响应）可以考虑界面线程与工作线程分离，也可以对自动生成URL的机制加以修改，其实完全可以几秒钟内生成上万条地址的。
ps: 另提一些问题：
1.采集界面经常会有刷新不出来的问题，此时除非最小化一下再上来，否则采集信息显示的页面都是灰的
2.删除任务时的提示信息有错别字：数据移出完毕->数据移除完毕
[ 本帖最后由 xenapior 于 2008-6-29 13:13 编辑 ]
页:
[1]