博客文章

　　用Drupal很多年一直都是用的自带搜索，但存在数据量大时速度很慢、搜索结果不准确等问题，中途尝试过Apache Solr，但感觉太复杂、麻烦了。也知道Views可以用作内部搜索，但一直没有实施。

　　最近在设法降低MySQL服务器负载时，查看RDS后台的慢查询日志，发现有相当多的慢查询都是Drupal自带的搜索造成的，特别是数据量大的中文站、搜索汉字词特别长的时候。还有些数据量大的站，生成搜索索引都需要非常长的时间（生成的搜索表可能比内容类型的字段表大得多），自己去试着搜索也是非常慢（有些需要几十秒以上，几乎无法正常使用）。于是就尝试用Views来替代，现在记录

　　宜昌全程跑完后，累得不行，当时就和同去的向东同学说要放弃再下一个周末的越野比赛，休息一周后再跑后官湖半马。但回来两天后腿酸也好了，马上又改变主意还是要参加。于是上周末又去参加了哥伦比亚武汉群山挑战赛。

　　这是一场小规模的越野跑比赛，报名限定100人，不过开放报名后当天名额就满了，武汉的越野跑这几年还是被Salomon月赛带起来了。一路碰到好些认识的朋友，从东湖绿道上张家山、南望山、喻家山、森林公园、猴山再返回，我也没有用太大的力量，和平时跑月赛差不多，还得留些体力到后官湖。最后3小时零几分钟完赛，比我预想的很要快一些，还来得及下午去汉街参加Laya非洲鼓俱乐部的

　　多语言支持是Drupal的重要特点，也是我们选择Drupal的重要原因，我们开发的Drupal网站很多都是带有多语言的，这其中就需要放置多个语言之间的互相链接，我们开始是使用的Language Icons第三方模块，后来又在手机版和响应式设计中使用了Language Switcher Dropdown，一直到现在。

　　最近在转UTF8MB4支持的过程中，把一些老旧的MyISAM引擎表转为了InnoDB引擎，应该更强大，但我们应用的场景是读取远远大于写入，不能很好发挥InnoDB的优势，反而在数据统计方面表现比MyISAM更慢，引起阿里云RDS负载（特别是IOPS

　　十多年前开始做Google AdSense后的不久，百度也推出了广告联盟，当时还接到电话让我们去注册使用，但试用后发现效果不佳就没有继续使用。一直到2010年Google因故退出中国大陆市场，国内AdWords用户减少，广告数量、价格都下降，AdSense也受到冲击。这时百度抓紧抢占国内广告联盟市场，价格也有明显提高，我们就开始在部分中文站点上投放百度广告，有一阵子收益还不错，劲捷公司又专门申请了一个公司账号，还成为黄金认证会员。

　　但去年初的魏则西事件、出卖贴吧吧主后，百度广告差了很多，不仅收益下降明显，广告质量也让发布商有些难堪。我们又重新转到Google

　　最近还在设法降低Drupal网站的MySQL负载，前些天尝试了安装entity cache，一般情况下可以把一个页面的70-120个mysql查询减少10个左右，然后把memcache使用的内存从1G增加到2G，应该会有一些帮助。

　　今天再次打开devel查询，发现多语言网站的页面中drupal_lookup_path特别多，50种语言就需要有50个这种查询，而且每个查询的语言代码不同，不能很好利用MySQL的查询缓存机制。

　　其实这个查询语句：

SELECT alias FROM url_alias WHERE
  

　　去年宜昌的首届马拉松，我报名的是半程，带了一大家子人去旅游两天，赛前一天与在宜昌的大学同学一起吃饭喝酒到很晚。比赛的时候前面一大半是陪着架子鼓李老师一起跑的，12公里上了一次厕所后面一小半自己跑的，2小时3分钟完赛，赛后约着一起吃饭，还比较轻松愉快。

　　今年还去宜昌，就报了一个全程比赛，挑战一下。另外，还有一位大学同学向东，以前都是电信系足球队的队员，这么多年来一直坚持提前，这次也报名了宜昌马拉松一起来。此前我还和他一起练过一次15公里东湖绿道、一次21公里武汉内环，像他这样有锻炼基础的，用几个月来适应跑步、跑10-20公里都不是问题。

　　在神农架的全程马拉松和宜昌的全程马拉松之间的荆州马拉松，就不敢再报全马了而是报的一个半马作为锻炼也作为陪家人旅游。200x年的时候因为工作去过荆州几次，也和家人一起去玩过一次，但都应该是10年前的事情了，这次算是故地重游。

　　现在坐动车很快，只要1个半小时就到了荆州高铁站，再坐出租车到市内也只要10来分钟，网上已经提前预订了荆州万达广场的某酒店。因为是周六早上的比赛，只要周五休一天假提前来到荆州，中午达到后先去酒店、吃饭，然后下午自己去荆州体育中心领取参赛物品，晚上和家人一起去东门古城墙附近逛了逛。

　　周六早上封路，骑了一个小黄车去到关公义

　　2015年下半年到2016年初我们集中把以前的Drupal 6网站都升级到Drupal 7了，记得当时还是花费了相当大的时间精力来做这些事情。这已经过去近2年时间了，升级后的Drupal 7网站也都运行正常，有些升级后遗留的模块和数据库中的表我们也没有多管，数据库空间不够就加空间。

　　最近设置Drupal 7网站支持UTF8MB4的时候，发现转换过程中也会造成数据库空间的增大，不想再继续购买扩大空间了，就想到把以前的Drupal 6遗留数据表进行清理，在网上也查了一下资料（例如：Table cleanup after Content Migration is d

　　今年上半年仅仅参加了一项武汉马拉松的半程比赛，算是这几年里面最少的，也把更多时间精力放在工作方面，工作方面有些起色后，业余时间夏天抽空去学了一段时间的非洲鼓，然后准备今年下班的跑步赛事。没有外出比赛的日子里也保持了每周至少3次左右的跑步练习，并且持续参加了多个月的武汉越野组织的萨拉蒙月赛活动，其中江夏八分山去跑了两趟，第一次夜跑居然没有最后完赛，后来一趟终于完成！还有珞珈山接力比赛、喻家山接力比赛，以及常规的东湖群山绿道拉练等。

　　Drupal的Views是个非常强大、灵活的工具，但用得不合适也可能导致数据库负载的飙升。最近把Drupal站启用UTF8MB4支持，转换程序自动把以前的MyISAM引擎转为InnoDB了，也因此引起阿里云RDS的IOPS升高。

　　又试了一些调整RDS参数等，无效。再看了一些资料、观察了RDS的进程，还是一些Views的消耗大，特别是数据量大的站。以前在Drupal 6时就在个别网站中启用过views_litepager这个插件，来替换Views本身的翻页，牺牲了查看一共有多少页的功能，不再运行select count(*) ... 这个在InnoDB引擎消耗很