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内存。。一直处理满状态，建了内存表只会更慢，因为内存不够用

导致了虚拟内存的使用。