dhtcrawler最早的版本有很多问题,修复过的最大的一个问题是关于erlang定时器的,在DHT实现中,需要对每个节点每个peer做超时处理,在erlang中的做法直接是针对每个节点注册了一个定时器。这不是问题,问题在于定时器资源就像没有GC的内存资源一样,是会由于程序员的代码问题而出现资源泄漏。所以,dhtcrawler第一个版本在节点数配置在100以上的情况下,用不了多久就会www.usus.cc内存耗尽,最终导致erlang虚拟机core dump。
除了这个问题以外,dhtcrawler的资源收录速度也不是很快。这当然跟数据库和获取种子的速度有直接关系。尤其是获取种子,使用的是一些提供info-hash到种子映射的网站,通过HTTP请求来下载种子文件。我以为通过BTwww.usus.cc协议直接下载种子会快些,并且实时性也要高很多,因为这个种子可能未被这些缓存网站收录,但却可以直接向对方请求得到。为此,我还特地翻阅了相关协议,www.usus.cc并且用erlang实现了(以后的文章我会讲到具体实现这个协议)。
后来我怀疑get_peers的数量会不会比announce_peer多,但是理论上一www.usus.cc般的客户端在get_peers之后都是announce_peer,但是如果get_peers查询的peers恰好不在线呢?这意味着很多资源虽然已经存在,只不过你恰好暂时请求不到。实际测试时,发现get_peers基本是announce_peer数量的10倍。
将hash的获取方式做了调整后,dhtcrawler在几分钟以内以几乎每秒上百个新www.usus.cc增种子的速度工作。然后,程序挂掉。
从dhtcrawler到今天为止的dhtcrawler2,中间间隔了刚好1个月。我的所有业余时间全部扑在这个项目上,面临的问题一直都是程序的内存泄漏、资源收录的速度不够快,到后来又变为数据库压力过大。每一天我都以为我将会完成一个稳定版本,然后www.usus.cc终于可以去干点别的事情,但总是干不完,目前完没完都还在观察。我始终明白在做优化前需要进行详尽的数据收集和分析,从而真正地优化到正确的点上,但也总是凭直觉和少量数据分析就开始尝试。
利用DHT网络原理制作
最新推荐文章于 2024-06-24 09:30:07 发布