Loading...

cos-html-cache不会导致CPU超标

Filed under: Wordpress,网站技术 — 江东 @ 2008-11-24 17:00:43 才(11)条评论

我已经在网上不止一次的看到有人说cos-html-cache这个插件会导致bluehost的CPU超标,这些朋友得出结论的来源在这里。现特写此日志,给予澄清。

在比较老的版本里面,cache的触发条件是:当有人留言,有人修改和发表post,插件会删除旧的缓存,同时生成新的缓存,这样就能保证缓存的及时更新。因此在旧的机制下,如果用户需要更新缓存就得需要两个步骤:1.删除旧的缓存;2.批量更新所有的日志,若不操作这步,该文章的缓存就只有在有用户留言或者博主重新编辑之后才能有cache生成。所以问题就出在这个第二步,如果日志过多,更新的时候会产生大量的数据库查询,从而导致CPU超标。

当cosbeta意识到这个问题的时候,就对这个插件进行了升级,升级之后的缓存机制发生了变化,而这个变化也是更加合理的。虽然我在一篇文章中详细的描述了cos-html-cache的缓存机制,这里我还是大体的提一下:插件将会在用户第一次访问的时候建立缓存文件,这个操作并不是有些朋友说的那样,会特别消耗CPU,实际情况是:插件只增加了一个文件建立的过程,所以对CPU的消耗几乎没有任何变化,就如同访问没有cos-html-cache插件的wordpress一样。因为如此,更新缓存的步骤就和老版本不一样了,直接删除所有cache便是更新了缓存,因为一旦有人访问某个没有cache的一面,cache便会自动生成。所以不会有任何大量的查询,也不会导致CPU超标。

当然,选用什么插件完全在于个人,cos-html-cache的效率到底有多高,对于post页面来说,应该是极限了。

不过,对于个人blog,用了缓存之后其实都差不多,速度这个东西,完全在于你的心,你认为它快,它便快了。

关于web方式上传大文件的问题

Filed under: PHP,网站技术 — 江东 @ 2008-11-14 20:36:25 才(4)条评论

最近对web方式上传大文件比较感兴趣,一直在尝试如何通过php上传大文件。不过你放心,cosbeta这篇文章不是告诉你如何修改php.ini中的post_max_size和upload_max_filesize,一来很多虚拟主机不允许你修改php.ini,即使允许修改,也不太可能让你将size修改到100M,同时php的max执行时间也会让你头痛不已,一句话,用php来实现传统方式的大文件上传是不太可能的。

那么如果一定要上传上100M的大文件是不是就一定没有办法了呢,未必,至少cosbeta就认为可以从两个方面来着手解决这个问题,一是客户端辅助,另外一个方式就是利用perl CGI。

客户端辅助方式是采用java applet或者activex辅助,将用户上传的文件在客户端分解成小文件,一个一个上传,然后在服务器端进行组合。当然applet和activeX各有优缺点,applet需要下载JRE,操作本地文件会有安全提示,会对用户体验不好。而activeX仅仅支持IE,这点众所周知。可惜cosbeta不熟悉activeX的编写,也不太喜欢applet,所以放弃了这个想法。

另外一个方法就是perl CGI了,这个网络现成的程序一大堆,所以这里我就不废话了。

今天用perl + ajax解决了带有进度条大文件上传,非常高兴,便记录下来之!

which is better : readfile, fpassthru, or header

Filed under: PHP,电子技术,网站技术 — 江东 @ 2008-11-14 17:08:16 才(7)条评论

有这样一个需求摆在眼前:

  1. web服务器上有很多文件要提供给用户下载;
  2. 必须隐藏文件真实的url,防止盗链和未授权的下载;
  3. 不要太占用CPU资源

于是有朋友提出解决方法如下(假设代码在download.php文件中):

  1. 直接header(“location:src”);
  2. 通过php readfile
  3. 采用fpassthru读取文件然后输出

当然,我们知道,采用header是无法加密文件真实路径的,在某些客户端中,真实的路径会被完全重定向输出的,所以第一个方案无效。第二个和第三个方案是可行的,我们完全可以通过.htaccess控制访问文件所在的目录,所以对于保密和授权的需求来说是完全满足的,但是有一个问题,这两种方案会很占用CPU资源么?特别是读取上百兆的文件的时候?

Readfile_vs_include告诉我们,include文件和readfile对于内存和CPU时间的占用没有丝毫差别,所以采用readfile是可行的,下面引用的表格为证: (read on …)

MySql查询耗时的问题

Filed under: PHP,网站技术 — 江东 @ 2008-09-27 22:00:51 才(9)条评论

感谢bluehost的CPU限制,让我对SQL查询的效率进行无限的追求。这两天CPU老是超标,我仔细查看了日志,我的这个bloggermap也他的一份“功劳”,特别是RSS阅读那一块,一个查询就占据了6秒,再加上其他几个合租伙伴的“功劳”(已经给他们发送邮件),很容易就超过30s了,所以今天晚上回来继续优化。

首先我们来看看这段关于MySQL查询的分析

# Query_time: 4 Lock_time: 0 Rows_sent: 10 Rows_examined: 74584
use sevtiger_bloggermap;
SELECT sample_blogs.id blogid,
sample_blogs.url blogurl,
sample_blogs.feedurl feedurl,
sample_blogs.name blogname,
sample_article.id id,
sample_article.title title,
sample_article.content content,
sample_article.description description,
sample_article.link link,
sample_article.author author,
sample_article.timestamp timestamp
FROM sample_article LEFT JOIN sample_blogs ON sample_blogs.id = sample_article.blogid WHERE 1 ORDER BY sample_article.timestamp DESC LIMIT 17800,10

整个查询耗时4秒,查询涉及到的行数有74584,实际输出10行,我们可以看到,整个查询的效率并不高。 (read on …)

如何避免Bluehost的CPU超标

Filed under: PHP,网站技术,虚拟主机 — 江东 @ 2008-09-27 16:23:50 才(3)条评论

曾经一度想放弃bluehost,主要的原因是因为“长城”、越来越差的服务器和响应速度不断变慢的livechat(当然这都是oversell的结果),然而在盛会之后,我发现bluehost的响应速度和SSH的稳定性第一次破天荒的超过了dreamhost,于是又有回归bluehost的想法了。

但是bluehost的CPU超标又严重困扰着我,熟悉storyday的朋友可能都知道,我用的bluehost基本都是几个人分享的,所以CPU超标是难免的。当然CPU的控制对于任何一个虚拟主机商来说都是很有必要的,国外知名的虚拟主机如bluehosthostgatorMT都有严格的CPU限制,这也是虚拟主机能稳定运行的一个保证,如果你是真正的想做一个站点,就用这样的主机,如果是采集站点,还是用其他的主机,如所谓的全能主机吧,否则频繁的CPU超标会让你严重不爽。当然即使是正规的站点,也会出现CPU超标的问题,那么我们就应该考虑优化自己的程序了。

虚拟主机的CPU超标的判断一般都是根据mysql执行时间来计算的,如果一分钟之内,所有的mysql查询执行时间超过了30秒,那么CPU就出现超标,网站将会在接下来的一分钟之内被挂起,所以要解决超标的问题,就应该从Mysql查询开始,下面我从3个方面来谈谈如何优化,仅供大家参考:

  1. 静态化你的站点。这个不用多说,我们都知道,静态化的页面对服务器的影响是最小的(当然我这里说得不是urlrewrite伪静态,发现很多朋友把这种方式也称之为静态,好像有点不妥),如果你使用wordpress,可以使用 cos-html-cache来进行静态化;
  2. 优化MySQL查询。在mysql查询中,尽量使用索引,这样能大大的提高Mysql查询速度。如果数据过多,就算使用limit 100000,10这样的限制查询,即使获取的数据只有10条,执行的时间也会变得很慢,那么这个时候就得考虑查询的精准化了,可以采用其他条件限制mysql遍历整个数据表;
  3. 使用google或者百度的站内搜索。很多web程序,在搜索的时候使用的都是类似” SELECT * FROM table where content like ‘%西洋美女%’;”的SQL语句进行查询的,而这种查询往往是最消耗时间的。SQL会对整个数据表进行遍历,遍历的时候还得要处理content中的字符,它使用的时间一般会是” SELECT * FROM table WHERE 1″ 这样语句的数十倍到上百倍,所以站内搜索,建议采用google等搜索引擎提供的接口,如本站的站内搜索。一方面这样的方式节约了服务器的负载,另外一方面这样的搜索反而更加精准。

优化的方法多种多样,我这里暂时只列举上面3条,其他的欢迎大家补充,不过storyday还是强烈建议你静态化你的网站,如果缓存的命中率比较高的话,静态化带来的只有好处,想好了么,或许你的blog也需要缓存

MySQL和SQL字符串限制长度漏洞分析

Filed under: PHP,网站技术 — 江东 @ 2008-09-09 21:01:15 才(9)条评论

今天升级wordpress,发现wordpress推荐的这篇文章介绍得相当好,于是乎打算翻(主要是根据个人理解翻)译过来,虽然本人在不经意过程中几乎都将这样的漏洞给过滤掉了,但是还是不能掉以轻心。

SQL注入攻击一直都在被广泛的讨论,然而人们却忽略了今天我将要介绍的这两个安全隐患,那就是超长SQL查询和单列SQL字符长度限制可能会带来的问题。

首先我们来谈论一下超长SQL查询

max_packet_size

这个东西是用来限制mysql客户端和服务器通信数据包的长度的,比如一个查询为“select * from user where 1”,那么这个长度仅仅几十个字节,所以不会超标。在绝大多情况下,我们很难会超过mysql的默认限制1M(可以想象一下,1M的SQL语句还是很长的)。这里插一句,看到这篇文章之后,我终于清楚我当初用PEAR DB 的INSERT插入数据失败的原因了,很可能就是数据长度超标。对于MySQL来说,如果查询字符串的大小超过了这个限制,mysql将不会执行任何查询操作

如果访问者有可能控制你的sql长度,那么你的程序可能会受到攻击。哪些情况访问者可能控制sql的长度呢,比如不限制关键字长度的搜索。还有可能就是你的程序如果要将用户的登录作为日志启用,总之凡是涉及到超长sql查询的地方,一定得小心检查自己的sql,防止超长而查询失效。不过说实在的,本人认为这个问题倒不是多大,数据库光里管理员也可以自行设置MySQL的max_packet_size的长度,或者在处理可能超长的SQL查询的时候做一个长度判断。

MySQL列长度限制

这个是本文的重点。MySQL对于插入的字符串,如果长度超过了数据表限制的长度,MySQL将会截取前面部分字符串插入数据库中,而不会将错误报给web程序。对于粗心的程序员,这个问题可能会导致程序的漏洞,其实目前的wordpress有很多限制,通过这个漏洞攻击应该没有任何作用。下面是原作者的几个假设,如果同时满足这几个条件,获取一个站点的用户名是相当容易的事情,幸运的是目前的wordpress并不太可能会同时满足下面的条件:

  • 该web应用允许用户注册(开放注册的wordpress满足此条件);
  • 超级管理员的用户名已知的,比如admin,这样方便攻击者寻找目标(可怜wordpress也满足)
  • MySQL使用的是默认的配置(估计大多数都满足)
  • 注册新用户的时候,程序没有对用户名的长度给予限制(我测试过,wordpress也满足)
  • 用户名被限制在16个字符(这个和上面的没有关系,仅仅是方便举例)

下面我们来看看攻击者是怎么攻击的:

首先攻击者用已知的超级管理员id如admin注册,那么这个时候程序就会用

SELECT * FROM user WHERE username='admin '

来检查该ID是否已经存在,如果存在,这不允许注册,当然,攻击者尝试注册admin肯定会失败;

但是如果攻击者用 admin       X(admin和x之间有11个或以上的空格)来注册呢,按照上面的判断,由于admin     x不存在数据库中,所以当然就能注册成功了,事实上wordpress2.6.1之前的版本确实可以这样,由于列长度的限制在16个字符内,所以末尾的x就被截掉了,那么现在数据库中就存在两个一模一样的用户admin了。(旁白:糟糕,那我的程序不是都要去修改。其实没有必要,你只要把ID设置为UNIQUE就可以了,于是乎,下面的问题就和你没有关系了)

攻击者继续,这个时候攻击者就顺利的注册了admin这个用户名,然后攻击者用admin和自己的密码登录进入账户管理(wordpress即使注册了也无法登陆),由于真正的admin的帐号先于攻击者admin注册,所以在账户信息页面,显示的信息非常有可能就是真正admin的信息,包括密码提示和email等,这个时候攻击者就可以对admin的信息进行任意修改,包括密码和密码找回。

所以,写web程序的你,是不是该去检查一下自己的程序是否有此类的漏洞呢。

这篇文章的攻击思路非常有趣,所以我翻到自己的blog,是翻,而不是翻译,要看原文的,请去这里

99ba47c32ba78410cd49a934a055ad3d

棘手的UFT-8编码问题

Filed under: 网站技术 — 江东 @ 2008-07-13 22:35:19 才(4)条评论

解决了一个utf8编码的问题,自己高兴一下。

从某个时候开始(应该是给servlet折磨之后),本人的php程序编码就只有utf-8的编码格式了,所以从不去考虑gb2312以及GBK,但是最近写一个程序的时候却遇到了很大的麻烦。该程序是一个数据导入程序,导入到文件格式很多,需要php自动分析,这个似乎难不倒我,但是问题在于这些文件的编码方式不一样,有的是gb2312,有的是utf-8,麻烦可大了。当然,或许有朋友要吧iconv或者mb_convert_encoding函数介绍给我,这些函数都一一尝试过,它们有一个严重的问题就是转换之后丢失文字。

最初的时候我以为导入文件都是GB2312的编码,所以我做了两次处理。首先将上传文件的表单提交给一个GB2312编码的php(do-gb2312.php)程序,这样从文件中读取的内容可以正常显示,然后通过ajax将php读出的结果返回到utf-8编码的一个表单中,再次用javascript提交该表单,问题解决了。然而问题并没有解决,因为用户还有另外的导入格式,而这些格式中居然又出现了UTF8的编码模式,刚才的程序好不容易把GB2312编码的文件处理好,但是UTF-8编码又出问题了。

想了很久,最后终于出绝招了。将do-gb2312.php原封不动的以utf-8编码的格式保存成另外一个文件do-utf8.php,在do-gb2312.php中加上编码判断。主界面的表单默认还是提交给do-gb2312.php,当do-gb2312.php中发现文本编码是UTF8格式的时候,通过js自动将主界面的表单提交域改成do-utf8.php,再次提交,大功告成,终于圆满的解决了此问题,毕竟中文除了GB2312和UTF8编码模式之外基本不会有其他的编码模式了。

下面是相关的函数,和一篇墙外相关的文章(虽然他没有解决我的问题,但是还是很有用的,所以我将它搬回到墙内) (read on …)

BloggerMap.org今天访问突破1万

Filed under: PHP,网站技术 — 江东 @ 2008-04-23 22:51:21 才(7)条评论

幸亏当初设计的时候用了PEAR的 Cache_lite做了多级的缓存。结果今天进入google统计一看,没有想到今天居然飙升到13000多IP,实在不可思议,估计又是撞上了新的热门关键词语,看来改版的时候得更加注意考虑缓存了,缓存设计至关重要,否则很容易被拖垮的。目前新的版本已经完成了50%,希望能在6月之前发布出来!