从第1版起，核心的投标引擎基本没有动，运行几十天也都正常。正好其他事情差不多了，想着再优化优化。我对比了本地和服务器的数据，以抓取概略标的为例，本地平均时间是220ms左右，服务器是120ms左右，快一些很正常。
后面，我基本就以本地数据为主，服务器肯定会快一些。
对引擎而言，主要工作就这些：抓概略标的——抓详细标的——比较投标——其他辅助处理。
本地概略标的每次耗时220ms，优化余地不大。
详细标的每次耗时500-600ms，最重要的耗费还是以http方式抓数据，但接口就是如此，要提高很难。
比较：0.4-2.8ms，相比之下是比较少的
投标：不是固定的耗费，用户多的话可以再优化，目前必要性不大。
本以为详细数据是问题关键，分析半天也没有太好的办法。最后发现，其实还有一个真正的“硕鼠”，就是其他辅助信息的获取。定期获取用户资金，我还追踪了满标的时间，计算每次的耗费，居然达到秒级！
发现问题，解决就很简单了，把用户数据更新的频率和次数优化，把满标时间分离到另外一个程序中，结果就大大改进了。原来统计，用于抓概略标的的CPU时间是最多的（因为详细标的并不常有），稳定后，服务器上这个时间占比能够到47%，也就是说，一半时间都在抓标。
优化之后，这个比例达到85%以上，换言之，几乎所有的时间都在跟踪标的，把对标的的反应间隔尽可能缩到最小。感觉对于满标极快的标的，抓的成功率高多了。这是最近投标的满标时间：
