userchooser的性能优化
人名控件的性能优化的解决思路:
1.前端js
2.数据的网络传输
3.后台逻辑
4.数据库
/**********************前端JS***********************************/
前端js基本上没有过多的优化余地。如果要修改获取数据的方式为分段取,那么改动将比较大,暂时不做
/**********************网络***********************************/
这块是大头。整个公司的人名拼起来的字符串有378k,那么网络传输的耗时将非常可观。检查发现apache没有开压缩
简单地将deflate打开,将人名数据压缩到110k。使用默认的压缩等级为6。这样网络传输的时间降为100ms以内
但是当请求邮件组时,这个字符串达到了579k(天啊好大),压缩后为156k。但是测试发现居然还是要接近1s的时候来传输。
跟前面的110k的网络时间完成不成比例,怀疑156k超过了apache的网络缓冲区的临界值吧。这个问题后面再继续研究。
同时,经过实验,不断地调整压缩等级也可能带来一定的提升,经过几次试验后,我发现在开发机上压缩等级为2可以使用网络传输最快。
/**********************后台逻辑***********************************/
由于cake框架的制约可能这个简单的请求会多余很多的逻辑。所以想把它剥离出来,用祼php来写。
写了个hello world测试了一下发现单个请求大约只提升了70ms+吧,空间不大,可能是人名请求没有加载多过的model吧。
暂时放弃剥离。
检查逻辑发现使用cake的model来查询数据库可能也走了很多不必要的逻辑,因为将其改为直接连接数据库并使用sql直接查询,
这样带来了100ms-200ms+的提升。
/**********************数据库***********************************/
检查数据库发现人名数据的表没有对enabled字段建立索引,因此将其加上。发现并没有带来性能上的提升。因为enabled的值是0和1,
且我们都是查找1的数据,这样的数据几乎占了全部数据的80%,因此这个所以几乎无效。
真正导致人名数据查询性能低的原因是取出来的数据太多了。于是尝试用sql来把人名拼起来,查义时只返回一个字符串即可。
于是用group_concat和concat将结果进行拼装,发现更慢了。。分析发现,其实数据库做字符串操作要比php慢多了。。
为了解决从磁盘取过多数据的问题,于是使用了mysql的内存表,这样数据将存在于内存中,减少了io的查询,具体可以提升多少性能
还需放到正式数据库上进行测试,因为俺们的开发数据库只有可怜的2G内存。。一直处理满状态,建了内存表只会更慢,因为内存不够用
导致了虚拟内存的使用。