对于我们这种很多年建过很多网站的团队来说,301重定向是一项重要的功能需求。很多时候我们的域名变更、路径改变、语言版本的调整等等都是网址的永久性改变,需要用到301重定向。
以前我们多是用Apache Rewrite功能来设置,也就是在.htaccess文件中设置跳转规则,例如:
RewriteCond %{HTTP_HOST
这是 负载 分类的页面,点击下面标题查看详细文章内容:
对于我们这种很多年建过很多网站的团队来说,301重定向是一项重要的功能需求。很多时候我们的域名变更、路径改变、语言版本的调整等等都是网址的永久性改变,需要用到301重定向。
以前我们多是用Apache Rewrite功能来设置,也就是在.htaccess文件中设置跳转规则,例如:
RewriteCond %{HTTP_HOST
我们选用Drupal的一个重要原因是其对多语言的支持,在实际使用中也发现多语言支持的一些问题,特别是对数据库负载的影响很大,我们已经想过不少办法了。例如:Drupal设置Memcache缓存、修改缓存翻译词的长度、减少翻译相关数据表的尺寸等。
这两天对一台阿里云RDS负载问题进行排查的时候,再次开启Devel来查看IP Location系列典型页面的SQL查询语句,从几个方面进行了优化:
最近一直在为降低MySQL服务器负载努力,Drupal网站中主要是排查Views引起的性能问题,而MediaWiki中也有一个与Drupal的Views对应的工具:Dynamic Page List (DPL动态页面列表),既可以灵活运用得到希望的信息展示效果,但同时也容易引起数据库负载过高、性能下降。
当网站打开很慢的时候,还是需要查看阿里云RDS数据管理控制台DMS(Data Management Service),查看诊断报告或者当前实例会话,查看慢查询语句,例如发现大量这样的语句:
SELECT DISTINCT `jing
最近还在设法降低Drupal网站的MySQL负载,前些天尝试了安装entity cache,一般情况下可以把一个页面的70-120个mysql查询减少10个左右,然后把memcache使用的内存从1G增加到2G,应该会有一些帮助。
今天再次打开devel查询,发现多语言网站的页面中drupal_lookup_path特别多,50种语言就需要有50个这种查询,而且每个查询的语言代码不同,不能很好利用MySQL的查询缓存机制。
其实这个查询语句:
SELECT alias FROM url_alias WHERE
Drupal网站对数据库服务器的压力由来已久,特别是Views做成的页面是最可能导致负载升高的原因,无论是以前自己服务器上的MySQL还是换用阿里云的RDS。
以前也采取一些缓存的措施来降低负载,但偶尔会出现一些问题,我翻看以前的博客中记录有《Drupal网站Views生成页面Title改为变量的问题》、《一个Drupal网站Views消失的排查》。
后来Drupal 6升级Drupal 7后似乎有些变化,但我一直也没有深究,基本上都是把Views的查询缓存设置为6天,把显示缓存设置为0,在系列网站的xxx.views_default.
春节前忙着把一些网站从自己独立托管的服务器搬迁到阿里云的平台中去,以前自己的服务器都是购买的顶配硬件(几年前就是16核、64G内存、8块硬盘),安装Linux+Apache+MySQL+PHP在同一台机器上,现在用了云服务器ECS做Web服务器,用云数据库RDS做MySQL服务,应该来说更合理,不过实际运行中也遇到问题。
先搬迁了几个小的网站,数据量不大、访问量不大,所以搬迁过去没有什么大的负载,ECS/RDS以及带宽什么都很富裕。但在搬迁一个数据量偏大、访问量也较大的网站时遇到问题,RDS的CPU总是100%,不运行自动检测超时MySQL进程并自动杀死该进程的脚本就
在我们一些用Drupal搭建的大数据量网站中,Boost模块产生的缓存文件数量非常多,以至于运行cron期间无法更新完毕,我们后来就采用了不自动更新缓存文件,而是人工根据需要在服务器上直接删除缓存文件的办法。
但当缓存文件数量达到数十、上百万的时候,需要很长时间删除,在这个过程中如果还有用户访问、产生新的缓存文件,将导致硬盘占用达到100%,长期这样的话,可能让服务器硬盘不堪重负、服务器出现负载上升、网站无法访问的情况。
这个问题一直困扰了我们好长时间,以前都是采取人工每次删除少量文件,逐步试着来进行,这导致要花费好些时间精力。昨天在网上查找了
从7月初到10月底的4个月时间中,我们已经在服务器上导入了大量数据,建成了一批新的子网站,在接下来的一段时间内我们不准备继续大增数据量了,而是对已经导入数据的网站进行精细优化调整,这个月已经开始了这方面的工作。
MediaWiki平台的网站都是去年以及以前建成的,这次基本没有大的调整,只是一部分网站对模板进行了更新,以便嵌入microdata微数据标记,虽然也需要运行后台更新、重新生成缓存文件,不过这个对服务器的负载影响不算很大,是可以承受的。
而在对今年新做的Drupal平台的改进中,如果只是修改内页模板、block以及me
在以前的MediaWiki所建站点中,我们启用了外部的Squid缓存和MediaWiki本身的File Cache两种页面缓存方式。
File Cache设置成时间无限长,只有页面或者包含的模板变化时才会更新,这项设置对缓解服务器压力起到了关键作用,如果不启用的话,网站很快就会变得无法访问。缓存的更新问题也基本上还好,在正常控制下工作。
2002-2023 v11.7 a-j-e-0