不要什么词频,不要什么云图,只要一个结果

上一次说过: 利用类词频来做表单字段自动关联选择优化  ,很久以前还讲过:像API一样地通过Dell设备SN号自动获取准确的设备型号 。这些东西的。发现前面那个思路不对,以前的思路是从已有的库内分析得到结果。那么,问题来了,库内分析可能会带来的影响:

1、对自身服务器查询的压力;2、精准度实在不怎么样;3、实现难度相对大

现在反过来,通过互联网“库外”查询来获得你想要的东西。“趴一趴”是不是也很有趣。结果同之前的方式跟目前爬取互联网数据分析的结果对比:

1、不触发对自身服务器的查询;2、精准度大大提高了;3、实现更是简单了

继续阅读不要什么词频,不要什么云图,只要一个结果

得一8GB内存服务器便肆无忌惮使用redis缓存

开始把软件部署到新的设备中。主要是看上CPU和磁盘IOPS都比之前使用的辣鸡设备强很多。尤其是磁盘,有了Raid10的支持。稍微测试了一下比原来的性能高3~4倍甚至更多。而且整个软件好像并没有做线程的设计,再感觉Python对CPU的要求又比较高。不知道是不是程序哪里的问题,反正,并没有预期的运行快。早在年初便想聊聊django cache的了。无奈,直到现在才稍微能写得出手,都是因为你笨啊。 继续阅读得一8GB内存服务器便肆无忌惮使用redis缓存

JavaScript 排序导致的错误

标题有点low,因为他们通常会用xxx引发的血案来命名。哈哈~1千600个瞧不起。自己选择的路,不管有多长也要跪完。背景:单台设备信息上架录入系统的时候不允许保存不连续的U位信息。因此,需要一个严格验证表单是U位信息是否连续的功能(放在前端,保证后台收到的表单数据U位永远都是连续,另外,前端直接提示,方便用户直接更正)。 继续阅读JavaScript 排序导致的错误