Entries Tagged as 'apache'

apache打开了proxy而导致访问慢

昨天产品报某台机器的80口慢
而且比较诡异的是同一个apache开的8080口却不慢
这种情况以前从来没有碰到过
于是我拷贝了8080端口的一个虚机配置为80口
再试
发现这个80口的速度还行,比较快
跟原来8080的一样
于是我就得出结论
访问速度快慢应该跟端口没有关系
而应该跟DocumentRoot有关系

后来的事实证明
我求证问题的方法是正确的
但是结论确是下错了

正确结论应该是:“慢的那个80口的virtualhost的配置导致了其访问慢”
而这里的配置
除了DocumentRoot跟8080的不一样外
还有
80的虚机里开了个反向代理
问题是反向代理开得有问题
不仅用了ProxyPass和ProxyPassReverse作反向代理
还打开了ProxyRequests
真正的问题就出在这里
打开了ProxyRequests,就等于是让apache支持了proxy功能
成了一个open proxy server
除非在 里进行限制
而恰恰这里配的限制也赔错了,没有起作用
故而有很多人把80口的这个虚机当成proxy server来用
当然正常的80口访问速度就慢了呀

最后解决:
把ProxyRequests关掉,再重起apache
即解决问题

url里的中文字符

当浏览器的地址栏里输入的url里如果含有中文字符的话
会被客户端(浏览器)先编码在送往服务器端
缺省状况下
浏览器(ie何firefox)都是设成用utf8编码url
但是服务器端(apache)却无从可知url采用的编码格式
因此也无法对其用正确的编码格式来解码
所以他就会直接去文件系统里按照你请求的url(编过码的)去取资源
如果文件系统里带有中文字符的资源的编码格式正好是客户端对url的编码格式的话
那么访问自然是没有问题
否则
就会出404的错误

How do you pre-compress content(in apache)?

公司手头有几台apache(httpd2.x)的机器
主要是往外吐一堆的xml
其中最主要是一个300多k的大xml
原来为了节省流量
在服务器上打开了mod_deflate
但后来发现机器负载巨重(load>100甚至于更多)
于是就把mod_deflate关掉(mod_deflate的缺点导致的)
但是显然一把mod_deflate关掉,流量又得猛涨
难道就没有一种折衷的方案吗?
记得在n年前,sina的同学们说发布的内容页都是提供2个版本对外服务(一个压缩过的,一个未压缩的)
于是我就想能不能把这些巨大的xml文件预先压缩一下
来请求了局让apache直接取这个压过的版本呢?
于是就开始想办法
最后发现有n种方式可以实现

  1. Enable pre-compression with mod_gzip;http://schroepl.net/projekte/mod_gzip/config.htm#precompressed
  2. Use Apache rewrite rules to redirect requests (index.html) to the pre-compressed version (index.html.gz):http://www.webmasterworld.com/apache/3387947.htm
  3. Use PHP to redirect to the pre-compressed version;http://www.phpbuilder.com/tips/item.php?id=1128
  4. Use Apache feature MultiViews and apache module mod_negotiation

源代码编译的httpd2.0.59,其xml文件的媒体类型竟然是application/xml

这个直接导致了我在apache里设置的对xml文件的压缩(deflate)未能成功
因为我的配置文件里是这么写的:

AddOutputFilterByType DEFLATE text/html text/plain text/xml

而且这种配置在系统自带的apache里是没有问题的
后来仔细查了查
发现系统自带的apache
用的是/etc/mime.types文件
而源代码编译的
用的则是conf/mime.types文件
这两个文件对xml文件的internet media type解释就是不一样:
一个认为是text/xml
另外一个则认为是application/xml
知道原因了
解决问题起来就顺利多了
把配置文件里AddOutputFilterByType那句后面加上application/xml
再重启就ok了

cacti中监测apache性能的模板apachestats0.4的问题

自打用上这里的用于cacti监控apache的模块儿apachestats后
总觉得还行,能用(也有些小问题,主要是图上显示的细节问题)
但最近发现有个问题比较大
就是有的服务器的监控图明显不对
我们有好些web server的机器(跑的apache),访问量很大,httpd进程经常被打到2000个,被打满(2048)
但是在这些服务器的监控图上一般最多能显示1000个httpd进程
为了查这个问题
我仔细的看了下这个模块儿的实现过程
import进来的每一个Data Templates和Graph Templates都看过了
最后发现是新生成的那个叫”WebServer - Apache Statistics”的Data Templates有问题
这里面的几乎每一个Data Source Item的“Maximum Value”都设的偏小
这样出来的监控图自然当数据小的时候都没什么
但数据一大,马上出问题!
知道原因了
再改正就快了
重新把数据设大
再删掉所有的用这些Templates建的图
再进rra目录删掉所有相关的rra文件(这步貌似非必须的:)
再重建新图
最后看图:终于搞定了
最后把改过的xml文件贴上来,以免大家重复劳动
改过的apachestats0.4的模板文件

apache(httpd2.x)的mod_rewrite的诡异现象

根据工作需要
要将uri /abcdefg.php rewrite成/files/abcdefg.xml
于是在相应的虚机里设置:
RewriteEngine on
RewriteCond %{REQUEST_URI} php
RewriteRule /abcdefg.php /files/abcdefg.xml [L]

但是始终不行
因为/abcdefg.php中其实就是丢出一个Location的头来强迫客户端获取另外一个xml文件,这里是/files/a.xml
假设这里的虚机是www.abc.com
当我telnet www.abc.com 80
再输入

HEAD /abcdefg.php HTTP/1.1
Host: www.abc.com

的时候
返回显示一个“Location:”头,重定向到/files/a.xml
这里显然mod_rewrite没生效
在DocumentRoot目录下
cp abcdefg.php abcdefgh.php
再在配置文件里添加一句:
RewriteRule /abcdefgh.php /files/abcdefg.xml [L]
使之成为这样:

RewriteEngine on
RewriteCond %{REQUEST_URI} php
RewriteRule /abcdefg.php /files/abcdefg.xml [L]
RewriteRule /abcdefgh.php /files/abcdefg.xml [L]

重启apache
再次测试,发现/abcdefgh.php能够正确重定向到/files/abcdefg.xml
但是/abcdefg.php不行
用HTTP命令
HEAD /abcdefgh.php HTTP/1.1
Host: www.abc.com

来看的时候
能正确返回就像是直接请求/files/abcdefg.xml的情况
这样显然mod_rewrite是生效了的
但是/abcdefg.php就是不行

apache中mod_rewrite仅当配在虚机里时有效的问题

今天在apache(httpd2.0.x)上配mod_rewrite
发现一个问题:
我本来是在/etc/httpd/conf.d/目录下单建的个文件来保存mod_rewrite的配置的
但奇怪的是在这里面的rewrite的设置并没有生效
琢磨了半天
把rewrite的设置写进相应的VirtualHost
再重启apache
居然生效了!!!
于是就有个困惑:为什么mod_rewrite的设置要写进<VirtualHost>里才会生效呢
终于,在apache的官方文档里看到关于RewriteEngine的一句话:

Note that, by default, rewrite configurations are not inherited. This means that you need to have a RewriteEngine on directive for each virtual host in which you wish to use it.

这样好像模模糊糊的解释了我的困惑
因为RewriteEngine在每个VirtualHost里缺省都是关掉的
那么当访问来的时候,写在VirtualHost外面的mod_rewrite的设置自然是看不到效果的

mod_proxy+mod_ssl来转发https的请求

前面讲到用apache做反向代理
于是马上又有了新的课题:如果要把https的请求也做代理转发该怎么办?
大概查了查文档
好像也有办法
mod_ssl里支持SSLProxyEngine指令
直接将其打开即可,这样再加上mod_proxy
于是很容易就有了以下的配置文件内容:

SSLProxyEngine on
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / https://www.abc.com/
ProxyPassReverse / https://www.abc.com/

这个建议写到某个<VirtualHost>里
如<VirtualHost _default_:443>
如果是Fc(Fedora Core)的机器
强烈建议先装mod_ssl
yum install mod_ssl
然后再在配置文件/etc/httpd/conf.d/ssl.conf中的<VirtualHost _default_:443>的session中添加以上的配置内容

用apache的mod_proxy做反向代理

工作需求:
在某台机器上(跑着apache)为某个域名(如www.abc.com)做反向代理
正好知道apache有mod_proxy这个东东
于是看了看文档
写下了如下的配置文件:

<VirtualHost *:80>
ServerName www.abc.com
ProxyPass / http://www.abc.com/
ProxyPassReverse / http://www.abc.com/
CustomLog logs/access_abc_log combined
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
</VirtualHost>

然后还要修改系统的httpd.conf
将其中的mod_proxy、mod_proxy_httpd启用
再然后
因为www.abc.com这个域名的真实服务器于我要配的服务器有内网相连(内网ip:10.10.10.10)
于是vim /etc/hosts
写入
10.10.10.10 www.abc.com
再重启apache
这就成了

build一个最小化的apache

工作需要
做一个最小化的apache
只需要能记录log就行
于是找了个apache1.3.37(apache1.3的最新版)
cd /tmp
wget http://archive.apache.org/dist/httpd/apache_1.3.37.tar.gz
tar xzvf apache_1.3.37.tar.gz
cd apache_1.3.37
vim src/include/httpd.h

“#define HARD_SERVER_LIMIT 256″

这行改成:

“#define HARD_SERVER_LIMIT 2560″

然后
./configure –disable-module=all –enable-module=log_config
make
make install
strip /usr/local/apache/bin/httpd
vim /usr/local/apache/conf/httpd.conf

把Order、Deny、Allow开头的几句都注释掉
然后
/usr/local/apache/bin/apachectl start
ok了