大家一直都说Drupal的性能不怎么样，跑起来慢，即使不是在用户量大的时候，最近公司的蜜蜂培训产品在一个客户的使用过程中，由于用户量及数据量的激增，就遇到了比较大的性能问题，这篇文章就记录了整个优化过程，最终将性能调整到了正常水平。
蜜蜂培训系统由于是包含报名、签到、投票、评估、考试等场景，而这些场景往往都是有时间点的限制，这就造成较大的用户并发量。刚开始遇到性能问题的时候，大家的第一感觉肯定都是硬件水平跟不上，随后我们对服务器进行了扩容，但发现收效甚微，随着用户不断增加系统也越来越慢，于是我们开始着手优化系统。
首先我们从数据库开始，开启了mysql 慢查询日志，来看看有没有哪些逻辑的数据库查询有问题，这一看真吓一跳，有一个关键逻辑的sql居然最长要执行68秒！
找到了问题所在，那么赶紧着手优化吧，来看看到底这个sql的执行时间到底耗费在了哪里，这里我们用 mysql 的 explain 命令来分析一下这个sql的执行计划， drush sql-cli 进入mysql命令行，敲入 explain + sql 就会打印出这个sql 的执行计划：
参考 explain 命令的说明，可以看到上图signup表是问题所在，这里没用到索引，使用了全表扫描和关联操作，经过对sql 和场景的分析，我们对sql中的这几个关键表对应的添加了新的索引：
function wl_signup_update_7005(){
if (!db_index_exists('eck_wl_signup', 'search_keys')) {
db_add_index('eck_wl_signup', 'search_keys', array('entity_type','entity_id','uid'));
}
}
添加完索引后我们再来分析一下这个sql，看关键指标rows 由原来的近2W降低到了1条，刚刚建的索引起了作用：
更新到生产环境测试效果明显，页面加载时间由30S缩减到了3S左右，性能提升近10倍，一天的观察后这个慢sql再也没出现在日志当中了。
关键页面加载问题解决了，接着我们继续来看考试并发时速度慢的问题，起初我们也在寻找是不是也是因为有这样的慢sql导致了考试加载速度慢，但始终没发现相关的日志记录，之后我们翻出quiz的代码，循着考试步骤一步步找原因，最后我们终于发现了问题所在：
每次答题页面加载的时候会在不同的地方多次去数据库查询整个试卷的layout，当试卷题目数较多时就会造成必要严重的性能问题，之后我们添加了layout 的cache在用户session中，减少了数据库查询次数，相应的页面加载速度也有较大的性能提升：
总结下来我们在遇到数据库性能问题的时候，可以从数据库索引优化与减少数据库查询次数两方面考虑一下。