Drupal十万级百万级节点网站优化

Drupal是一个优秀的万用平台，开发的模块也大都基于兴趣，模块开发者们并不需要在企业级的应用中去验证自己的模块执行效率，同样，mysql也是一个主要基于基础用户的模块，高级用户的使用也要经过多级别的优化。所以，大数据量的网站，不经过优化与忍痛割爱，应用是比较痛苦的事情。即使是系统级的模块，假设一个网站开发者一次性的加入50万篇文章，而也用的都是管理员的帐号，这就可以直接导致tracker模块僵硬化，全部的运转处于漫漫的等待中，在mysql数据库的数据量达到 3.6万+时，部分数据查询用时将数倍增加，本优化程序适合在Drupal节点数量在3.6万+,10万级至100万级的节点数量测试情况下网站运转良好。

首先，我仍旧建议您的最终解决之道是，如果您要用某一个模块，请使用Devel模块生成至少相应量的节点，开通mysql的slowquery日志。然后对该模块中的每一条查询测试或按照经验评估其性能，然后在需要的地方建议索引来提供效率。

1),在没有必要的情况下，建议您不要使用tracker模块与Statistics模块，在pathauto当前版本仍旧要生成大量的链接而不能用token的时候你也尽量不要使用，对于page title 与 meta tags模块，在seo如此重要的今天，似乎做不到不用，那就请使用最新的2.x的模块，用token来代替硬性的生成多条的数据库记录。

2),search模块同样是个令人头疼的模块，在大数据量的情况下使用search模块建立索引比较考验站点的压力，尤其是CPU占用率的问题，所以尽管有中文分词模块CSplitter，中文drupal网站中仍旧少有用到search模块的。也许您应该考虑用JOb_QUEUE模块来分解一下压力（该模块可以使CRON成为一项计划调试的工作，以解免并发时产生的巨大的能量，当然，如果您会编写程序，您还可以修改模块中的一些内容使工作变成UDP模式[意思是说，这工作我做了，但做没做好不用太关心],比如群发会员邮件,SimpleNews的工作，我就建议不要等服务器把邮件全发完了才开始新的工作，直接交给第三方去安排好了。),但这仍不是理想的解决方案，我建议您使用第3）点考虑的方案。

3）poormanscron 应该是个很好的管理cron的程序，但是问题是如果你设置的太频繁，Search模块会让你头疼，如果您设置得太稀疏，网站又总是处于历史状态。一天的高峰期，当大家都在使用您的网站的时候，网站一下又开始建立索引了，让大家干晾中，也不是很理想的事情，当然，您可以使用windows的任务计划来让cron在晚上运行（有一点不好就是你打开了IE，却没有关闭他，周而复始的开窗口占用资源，难道又运行一个任务来killed IE,这样一来按照有些优秀程序员的说法，这件事情做得真是充满了臭气），所以我建议您稍稍改造一下poormanscron的模块，让这个模块在每天晚上2点，3点运行，这样顶多是牺牲一个用户（就是那个三更半夜访问在那个时间您的网站的人，当然，如果你网站节点如此巨大，仍旧是访问者渺渺，请一定要先学习drupal的精华所在）的利益来获得网站的太平吧。很简单的逻辑吧，自己修改poormanscron,就叫timscron吧,可以自己设定在晚上几点运转，这要有多个网站的时候，可以一小时cron一个，思路是这样的。

  3.1 在form表单中将原来的time_interval的分钟改为天，[关于白天晚上的事情，当然天是最小工作单位：）]这是最小周期，你可以一天运行一次，也可以两天运行一交。也可以一周运行一次。在form表单中再加一个select让用户可以选择是1点运行还是23点运行。

  3.2 在_exit hook中加这样的一句。$current_hour = format_date(time(), 'custom', 'H'); 注意，请不要使用getdate()来获得hours，因为那样就不是格林威治时间，总是差8小时。。用系统的format_date就好 。然后在 比较中加一个条件。。if (variable_get('timescron_hour', '02')==$current_hour)这样就工作就全部完成。

  3.3 完整的代码请点击这儿下载 http://www.rainfu.net/sites/files/net_rainfu/timescron.rar

4) drupal自身带的一些性能模块，Cache虽然是Cache在数据库中，但仍旧是提升性能的超级武器，我也建议您设置的cache周期与上棕的times_interval对应，如果您是用的5.x,请再加一个Javascript Aggregator 来对js文件进行优化。对于一些特定页面，如首页，最新内容相关的页面，您可以在timescron中再加一个form，使他们能够在更短时间内进行更新，比如每小时，这样，假设有个朋友与您交换友情链接，你手动更新一下首页就OK了，总不至于要他等一天吧。当然，您也可以手动cron,这样做我一直有点不安，老实说，节点多了，我怕来个delete from cache_pages 等上个3，5分钟，不知道有没有达人试验过这种清空表的查询是不是可以替换成为truncate table,没有试过。

5) memcache模块在提升效率方面我试过，确实相当有效，但是对需要patch源代码的东西，我还是想保持一点适合敬畏的距离，所以最终没有使用，如果你的网站不需要经常升级，我建议您使用memcache ,file cache在大数据量的时候不是天命，是噩梦，我建议您不要使用这样不够成熟的模块,使用zend_optimal 优化工具效果都会好很多。

6) xml_sitemap同样是个令人喜爱的模块，只不过节点数到了6，7位数，生成的xml_sitemap.xml.gz达到10多个时，消耗也是相当可观的一件事情，我建议您在第一次生成后，将他放置到 /sitemaps/[sitename]/下面，然后提交给google,然后取消这个模块。每个月提交一次就OK了，当然，请在robort.txt文件中加上/sitemaps的可读取权限。

您可以参考本网站: http://www.136law.com 参考实践