前提:
Lamp架构(原理上虽然jsp,.net等都一样,但我现在只懂php了)
1.用户对准确度的要求是不一样的.银行会要求客户帐上的钱的数目永远是精确的,但是论坛的在线人数,贴子数没这个必要.每天有成千上成的贴子发表。谁会去对质?我们只半个小时算一个甚至每天算一次就行了.所以,应用中要是没加Cron,那就肯定不是一个好应用.想象一下awstats,每当你的老板让你给演示一下前一周的访问周数据时,它就嘎吱嘎吱地算上老半天,然后在你的老板快要睡着时IE终于弹出一个页:服务器超时…. 你就知道要把一些服务设为定时跑一次,而不是时时保持最新最准确了
2.瓶颈永远是先在CPU/内存/磁盘IO中的一个出现.他们很少是同时告急的.因此,针对这个设计一个.比如:某台服务器上CPU占用平均为60%左右,而内存占用是5%左右。那么我们可以预先猜测,CPU资源会首先占尽。由于日志显示占用CPU最多的是mysqld进程，说明mysql查询耗尽了 CPU.再查之,原来是贴子主题太多,一个表有上G大小,索引不当.
找到问题,于是马上做出改进.原来的URL已经优化成***.com/topic/10/10001.html, ***.com/topic/12/12001.html…这样的了,但其实后台是用rewrite的.而id从1到100,000的主题都因为已经太老,无人参与回复了，所以没必要每次都查库.马上写个脚本,将***.com/topic/1.html…. ***.com/topic/10/10001.html…这些页面都读下来,保存为web根下/topic/***/***.html文件。现在这些文件是实际存在的了,Apache会优先读这个静态文件,而不是适用rewriterule了.
(注:我的apache 的rewrite规则是这样写的,这样文件找不到的时候会交给index.php来处理.
Lamp架构(原理上虽然jsp,.net等都一样,但我现在只懂php了)
1.用户对准确度的要求是不一样的.银行会要求客户帐上的钱的数目永远是精确的,但是论坛的在线人数,贴子数没这个必要.每天有成千上成的贴子发表。谁会去对质?我们只半个小时算一个甚至每天算一次就行了.所以,应用中要是没加Cron,那就肯定不是一个好应用.想象一下awstats,每当你的老板让你给演示一下前一周的访问周数据时,它就嘎吱嘎吱地算上老半天,然后在你的老板快要睡着时IE终于弹出一个页:服务器超时…. 你就知道要把一些服务设为定时跑一次,而不是时时保持最新最准确了
2.瓶颈永远是先在CPU/内存/磁盘IO中的一个出现.他们很少是同时告急的.因此,针对这个设计一个.比如:某台服务器上CPU占用平均为60%左右,而内存占用是5%左右。那么我们可以预先猜测,CPU资源会首先占尽。由于日志显示占用CPU最多的是mysqld进程，说明mysql查询耗尽了 CPU.再查之,原来是贴子主题太多,一个表有上G大小,索引不当.
找到问题,于是马上做出改进.原来的URL已经优化成***.com/topic/10/10001.html, ***.com/topic/12/12001.html…这样的了,但其实后台是用rewrite的.而id从1到100,000的主题都因为已经太老,无人参与回复了，所以没必要每次都查库.马上写个脚本,将***.com/topic/1.html…. ***.com/topic/10/10001.html…这些页面都读下来,保存为web根下/topic/***/***.html文件。现在这些文件是实际存在的了,Apache会优先读这个静态文件,而不是适用rewriterule了.
(注:我的apache 的rewrite规则是这样写的,这样文件找不到的时候会交给index.php来处理.
