记忆也需回忆

Apache的日志又多又杂，如果靠分析日志或者查看服务器进程来监视Apache运行状态的话，比较繁冗。其实在Apache 1.3.2及以后的版本中就自带一个查看Apache状态的功能模块server-status

打开Apache Server Status
如果你的Apache配置文件httpd.conf或者extra/httpd-info.conf中有LoadModule status_module modules/mod_status.so话，说明你的Apache已经加载了此模块；或者编译的时候加上了–enable-module=so也表明 服务器支持server-status。

如果Apache没有加载这个模块，如果是linux服务器，就得重新编译Apache，加上–enable-module=so参数即可；如果你 是windows系统的话，无需任何编译，只要把刚才时候说的LoadModule status_module modules/mod_status.so这句加上，如果前面有带#号，开启的话，需要将#去除。

配置Apache Server Status

这是一个完整的server-status的配置。
第一行的ccvita-server-status表示以后可以用类似http://www.ccvita.com/ccvita-server-status来访问，同时

http://www.ccvita.com/ccvita-server-status?refresh=N将表示访问状态页面可以每N秒自动刷新一次；

Deny from表示禁止的访问地址；
Allow from表示允许的地址访问；
ExtendedStatus On表示的是待会访问的时候能看到详细的请求信息，另外该设置仅能用于全局设置，不能在特定的虚拟主机中打开或关闭。启用扩展状态信息将会导致服务器运行效率降低。

Smarty在线手册：

http://www.phpfans.net/manu/smarty/

利用isapi_rewrite可以实现类似于Apache的伪静态路径，利用其检查refer的功能我们还可以实现防盗链。该软件可以在 http://www.helicontech.com/download/下载，是一个共享软件，但是有一个LITE版本是免费的，基本上可以实现我们需要的功能。安装的步骤我就不详细说了，具体说说httpd.ini的设置。
首先，必须要保证httpd.ini有可写权限，设置isapi_rewrite安装文件夹everyone具有可修改权限后，去除该文件的只读属性。
httpd.ini默认设置如下:

RewriteCond Host: (.+)
RewriteCond Referer: (?!http://1.*).*

我们在它后面加上一句

RewriteRule .*.(?:gif|jpg|png|exe|rar|zip) /block.gif [I,O]

即可实现gif/jpg/png/exe/rar/zip文件的防盗链，盗链页面显示的是/block.gif。block.gif是一个体积较少的图片文件，我们可以在上面打上自己网站的版权标志和防盗链声明。
如果按照上面设置，则除本站以外的所有网站均不能使用这里的图片，如果要允许一些例外的网站比如google,baidu以及其它一些非营利性网站引用该怎么办呢？我们可以用如下正则表达式来实现

RewriteCond Referer: (?!http://(?:www.0e2.net|www.google.com|www.baidu.com)).+

如果想允许所有google子站和baidu子站形如images.baidu.com,images.google.com等站则做如下设置：

RewriteCond Referer: (?!http://(?:*.0e2.net|*.google.com|*.baidu.com)).+

至此，一个相当有效的防盗链系统已经出来了，但如上设置有一个问题，如果浏览者浏览了盗链页面后访问本站页面，则被盗链图片的缓存会影响图片的正常显示。把

RewriteRule .*.(?:gif|jpg|png|exe|rar|zip) /block.gif [I,O]

改为

RewriteRule .*.(?:gif|jpg|png|exe|rar|zip) /block.gif [I,O,N]

方可。参数N的意思是重新从站点请求文件而不是从本地缓存读取。

过IIS5的朋友都知道,如果ASP代码有缺陷,例如,死循环,或者代码中没能遵循数据库访问的开合原则,那么,就有可能引起IIS死锁.在IIS5下,
死锁是一件可怕的事,因为,服务器上任何一个IIS站点的死锁会导致IIS被阻塞,其结果是IIS进程CPU使用率很高,这样,所有对于WEB服务的访问
都无法得到回应
IIS6中,防止死锁做的相当不错,而且IIS6中增加了池的概念,就是将若干个站点放在一个进程中执行,而这个进程W3WP,跟IIS的进程分离开来,
这样,即便有一个站点死锁,那么,只影响其所在的W3WP进程,而不会影响其他应用程序池.这个概念应该是得益于ASP.NET的应用程序域而来的.另
外,IIS6聪明的一点还在于,如果发生死锁,持续一段时间后,IIS会自动终止这个W3WP进程,重新为其建立新的进程,用于处理请求,这样,就避免一
直死锁下去.看来,IIS6中这种将IIS进程,处理请求的工作进程分离开来的做法,确不错
但是,光解决问题还不行,通常,如果你不想这种情况反复发生的话,你就应该找出那个导致死锁的站点,然后将其隔离并检查ASP代码.对于一个管理员来说,
这不是一件容易的事.因为,通常一台服务器,可能有几十甚至上百个站点,这样,你也不知道哪个池对应于哪个W3WP进程,因此,就算你知道死锁进程的
PID,你也不知道应用程序池的名字.
幸好,IIS6提供了一套不错的IIS管理脚本,当死锁时,使用
iisapp -a
就可以列出每一个IIS应用程序池与W3WP进程ID对应的关系.这样,我们由死锁进程ID就可以逆查出其对应的池的名称.

然后,我们就可以将范围缩小到一个池中.然后,对池中的几个网站逐一排查了
这真是一套非常有用的工具