为IT服务 [龙飞的博客]

location

语法:location [=|~|~*|^~] /uri/ { … }
默认:否

上下文:server

这个指令随URL不同而接受不同的结构。你可以配置使用常规字符串和正则表达式。如果使用正则表达式，你必须使用 ~* 前缀选择不区分大小写的匹配或者 ~ 选择区分大小写的匹配。

确定 哪个location 指令匹配一个特定指令，常规字符串第一个测试。常规字符串匹配请求的开始部分并且区分大小写，最明确的匹配将会被使用（查看下文明白 nginx 怎么确定它）。然后正则表达式按照配置文件里的顺序测试。找到第一个比配的正则表达式将停止搜索。如果没有找到匹配的正则表达式，使用常规字符串的结果。

有两个方法修改这个行为。第一个方法是使用 “=”前缀，将只执行严格匹配。如果这个查询匹配，那么将停止搜索并立即处理这个请求。例子：如果经常发生”/”请求，那么使用 “location = /” 将加速处理这个请求。

第二个是使用 ^~ 前缀。如果把这个前缀用于一个常规字符串那么告诉nginx 如果路径匹配那么不测试正则表达式。

而且它重要在于 NGINX 做比较没有 URL 编码，所以如果你有一个 URL 链接’/images/%20/test’ , 那么使用 “images/ /test” 限定location。

总结，指令按下列顺序被接受:
1. = 前缀的指令严格匹配这个查询。如果找到，停止搜索。
2. 剩下的常规字符串，长的在前。如果这个匹配使用 ^~ 前缀，搜索停止。
3. 正则表达式，按配置文件里的顺序。
4. 如果第三步产生匹配，则使用这个结果。否则使用第二步的匹配结果。

例子：

location = / {
# 只匹配 / 查询。
[ configuration A ]
}

location / {
# 匹配任何查询，因为所有请求都已 / 开头。但是正则表达式规则和长的块规则将被优先和查询匹配。
[ configuration B ]
}

location ^~ /images/ {
# 匹配任何已 /images/ 开头的任何查询并且停止搜索。任何正则表达式将不会被测试。
[ configuration C ]
}

location ~* \.(gif|jpg|jpeg)$ {
# 匹配任何已 gif、jpg 或 jpeg 结尾的请求。然而所有 /images/ 目录的请求将使用 Configuration C。
[ configuration D ]
}

例子请求:

/ -> configuration A

/documents/document.html -> configuration B

/images/1.gif -> configuration C

/documents/1.jpg -> configuration D

注意：按任意顺序定义这4个配置结果将仍然一样。

这几天在把我们网站的主web server从apache迁移到nginx上面，没想到还是遇到了些问题。
1.原来在apache每个二级域名都是用建站点的方式，我打算在nginx里面使用rewrite规则的方式来进行跳转，比如：

1
2
3
4

location /
{
     rewrite ^(.*)life.my.com(.*)$ $1www.my.com/lan28/$2 last;
}

可事实上这样写是完全没有效果的，后来分析了下实际上在 location / 里面的rewrite是只能处理hostname之后的内容就是www.my.com/(rewrite)，对于hostname是没法进行rewrite的，那如果要对hostname进行rewrite怎么办呢。目前想到是把rewrite挪到location外面去，不过尝试了下貌似还是有问题，继续研究中。。。

2.原来www下面有几个alias，比如访问/wwwroot/www/php/ alias 到/wwwroot/php/ 这样，但是在nginx里面alias的话呢htm、图片等静态文件没问题，但是php问题就来了，由于php是通过正则转发到fastcgi的比如：

1
2
3
4
5
6
7
8
9
10
11

root  /wwwroot/www;
location /php/
{
     alias /wwwroot/php/;
}
 location ~ .*\.php?$
{
     fastcgi_pass  127.0.0.1:9000;
     fastcgi_index index.php;
     include fcgi.conf;
}

这种情况下如果http访问/php/*.php文件实际上是由 location ~ .*\.php?$ 处理的，也就是说php文件根本没没有进行alias还是按照/wwwroot/www/php/的路径访问的。
这个问题如何解决呢，我想到了几个方法：
1)使用symbolic link从系统上把/wwwroot/php/映射到/wwwroot/www/php/
2)修改location ~ .*\.php?$ 的正则，将/php/目录排除，然后在写一个location ~ /php/.*\.php?$ 来处理/php/下面的php文件
3)放弃alias使用rewrite的方式来处理。
三个方法第一个属于回避型，虽然能解决问题但是不符合我的要求。第二个么太复杂，能否实现还是未知。最后我选择了第三个方法就是用rewrite来处理。
略微修改了下代码

1
2
3
4
5
6
7
8
9
10
11
12

root  /wwwroot/www;
location ^~ /php/ #这里的关键就是使用“^~”，这样如果是/php/的话就不去匹配下面的php的正则，而全部重定向到php.my.com去，不然的话还是一样的htm正常，php无法访问。
{
     rewrite (.*)/php/(.*) http://php.my.com/$2 permanent;
}
location ~ .*\.php?$
{
     fastcgi_pass  127.0.0.1:9000;
     fastcgi_index index.php;
     include fcgi.conf;
}
·

这里的http://php.my.com 对应的就是/wwwroot/www/php/
这样基本就实现了需求了

今天在把博客的系统换成64位装mysql时提示：
error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
之前装32位习惯了yum -y install compat-libstdc++-33 后发现还是这样，才想起来是64位
重新yum -y install compat-libstdc++-33.x86_64 在安装就ok了
所以安装64位系统这些lib库可留心下把64位的也装了。

http://goosh.org/

真的很另类哈哈

以前也是一时起兴，顺手试了试结果php configure的时候出错，就放在那一直也没空弄。
最近打算把部分虚拟机扩到8G内存测试下压力所以又把64的系统装起来再次尝试。
吃好晚饭忽然觉得有点头晕恶心，什么事情都干不了，就在那里翻config的log，结果发现原来是krb5没装，yum install krb5 krb5-devel后重新configure搞定。忽然发现头也不疼了哈哈。

环境：ESX3.5U2+VC2.5U3
ESX主机配置：DELL2950 双路四核E5450@3.00GHz，32G内存，双网口千兆网卡*2，单口4Gb HBA卡*2
中心存储：Netapp2050A FC双冗余方式链接ESX主机
vm配置：
web、mysql、测试客户端均为4CPU，4GB内存，系统盘在vmfs，应用数据盘全部rdm到存储LUN。
其中web、mysql、测试客户端分别分布在3台ESX主机，ESX之间采用千兆交换机链接。
环境：
web：centos5.2-32位，nginx0.7.30，php5.2.8，php-fpm fastcgi
nginx进程8个，fastcgi开128个php进程

静态页面
webbench -c 10000 -t 30 http://192.168.88.12/images/Beijing2008/newtopic.gif
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://192.168.88.12/images/Beijing2008/newtopic.gif
10000 clients, running 30 sec.

Speed=1489408 pages/min, 61853432 bytes/sec.
Requests: 744674 susceed, 30 failed.
=========================================
phpinfo
webbench -c 10000 -t 30 http://192.168.88.12/phpinfox35.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://192.168.88.12/phpinfox35.php
10000 clients, running 30 sec.

Speed=63636 pages/min, 48736019 bytes/sec.
Requests: 31818 susceed, 0 failed.
============================================
php动态 dz论坛首页
webbench -c 10000 -t 30 http://192.168.88.12/index.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://192.168.88.12/index.php
10000 clients, running 30 sec.

Speed=15534 pages/min, 16145783 bytes/sec.
Requests: 7767 susceed, 0 failed.
==================================================
php动态 dz论坛列表第二页
webbench -c 10000 -t 30 http://192.168.88.12/forum-8-2.html
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://192.168.88.12/forum-8-2.html
10000 clients, running 30 sec.

Speed=6002 pages/min, 9228623 bytes/sec.
Requests: 3001 susceed, 0 failed.
==================================================
不得不佩服下nginx的静态文件处理能力，1489408 pages/min 这个成绩太出乎我的意料了，我想这基本也就是目前vi3平台虚拟机的最高性能了把。由于目前的平台vm最多使用4个cpu(据说VI4将会升级到支持8个CPU)，所以除非esx主机使用更高主频的CPU，否则基本上和这个成绩也差不了多少了。
php我使用的是一个现成的dz论坛数据，由于还涉及到mysql的中间层，但是这样的结构已经非常接近实际使用环境了，在如此高并发的情况下还能够有将近每秒260 pages。
可以说在web处理能力上来说，企业级虚拟机平台是一种完全可以替代传统架构的平台，并且在满足性能需求的情况下，更加灵活和方便的部署、扩展方式，更加可靠的全平台HA方式，这无疑又给系统带来更高的稳定运行的能力。相信今后在web应用环境中vmware的VI3虚拟机平台将会有更加广阔的应用空间。

vmware vi3 部署centos虚拟机模板启动、ifup eth0的时候提示
RTNETLINK answers: File exists

经过检查原来是ifcfg-eth0中已经写了网关，但是用自定义规则部署虚拟机模板的自动又生成了一个route-eth0来指定网关，删除route-eth0后问题解决

网站代码验证

没人可以细致到保证自己的网站代码都是正确的，你可以通过以下测试来验证网站代码是否正确。

1 . WDG HTML Validator 一个很好的工具，能找出网站语法错误的地方，并标注出来，也可选择对网站上单独的每一页进行单页分析。（ 强烈推荐 ）

2 . W3C Markup Validation Service 对 HTML 和 XHTML 都能进行代码测试，自称是互联网络上第一个（也是使用者最多的）的 HTML 验证工具。

3 . W3C CSS Validation Service 用于验证 css 源代码，能够标注出不好的 css 代码设计。例如：“Same colors for color and background-color in two contexts”。

4 . RUWF XML Syntax Checker 用于查找 XML 文件的错误。

5 . W3C Feed Validation Service 用于查找 Atom 和 RSS feed 中的错误语法。（ 这个我经常用到 ）

6 . W3C Link Checker 用于搜寻查明你网站内的所有链接里是否有断链。（ 强烈推荐 ）

7 . Juicy Studio Link Analyser 测试网站内的链接的 URL 是否存在死链，与 W3C Link Checker 很类似。

网站的使用性

我们常常看到网站设计者把重点放在怎网站的吸引力上，而完全不考虑会不会影响来访者的使用，一个浏览难度很大的网页是注定要失败，要让你的来访者方便的得到他要的信息（从而成为重复访客），你的网站应当遵循 WCAG section 508 易用性规则。

8 . Watchfire WebXACT 所有严谨的设计师和开发者都必须使用的工具，它会生成一个非常详尽的报告书，包括：网站质量，易用性和隐私等。（ 强烈推荐 ）

9 . ATRC Web Accessibility Checker 测试网站的 WCAG 2.0 Level2 兼容性，它会生成一份报告，提出一系列建议，如：如何提升页头，链接，数据，图表和文字的访问速度。

10 . WAVE 3.0 Web Accessibility Tool 高度可定制的工具，它采用了图形化模型展示网站兼容性问题（ WCAG 1.0 and section 508 ）。（ 强烈推荐 ）

11 . TAW Web Accessibility Test 测试网页是否存在冲突（ WCAG 1.0 兼容性 ），通过图形模式生成一份依据 wcag 优先模式为基础的网站修改建议。

12 . HiSoftware CynthiaSays portal 采用了非常严格的规则来测试网页（ 根据 section 508 和 WCAG 1.0 规则 ），生成的报告也极为详细（ 详细到很难看懂 ）。

13 . HERA Accessibility testing with Style 使用一种极为复杂但容易理解方式指出网页的 wcag1.0 兼容性问题。

14 . Juicy Studio CSS Analyser 进行了色彩对比测试，以确保你的网站的色调会符合 WCAG 1.0 的要求。

15 . Juiciy Studio Readability Test 分析你网站上的文字是否有语法错误或拼写错误等问题，容易让人理解不（ 根据 the Flesch Reading Ease 和 Flesch-Kincaid grade level algorithms 规则 ）。（ 适合英文网站使用 ）

网站的速度

打开你的网站的速度快慢，是来访者会不会再次访问网站的关键因素，在一般情况下，一个网络不是很快的来访者是不愿意访问一个充满着图片、flash 动画、多媒体文件的网站。为了使你的网站覆盖人群的范围最大化，你必须优化你的网站，使它的打开速度尽可能的快。

16 . Web Page Analyzer from Website Optimization 一个很好的工具，它在分析完一个网页后，会为减少加载时间提出优化建议，着重优化物体的数目，图片和网站的总体大小。（ 强烈推荐 ）

17 . WebSitePulse Test Tools 有一系列的工具来确定网站的加载速度和主机信息。

18 . Internet Supervision Url Check 从世界各地不同的服务器来测试你的网站的加载时间，用于确定是不是各地的来访者都能顺利快速的打开你得网站。

浏览器模拟工具

这是一个普遍的问题，因为现在有着很多的操作系统和浏览器，你得网站必须得兼容它们，但这绝不是一件容易的事。通过下列工具，你可以了解你得网站在各种浏览器上的显示效果。

19 . Browsershots 能给出你的网站在不同浏览器下显示效果的截图，包括：Firefox 和 Internet Explorer （ Windows ）、Firefox 和 Safari （ Mac OS X ）、Iceweasal 和 Konqueror （ Linux ），但是结果要在 1 – 3 小时后才能出来。

20 . IE NetRenderer 实时生成你的网站在 Internet Explorer 5.5 、6.0 和 7.0 下的截图。

21 . MobiReady Report 分析使用手机访问网页的兼容性问题，会生成一份详细的报告，并提供了在两种不同类型的手机浏览器上你得网站可能显示的样子。

搜索引擎优化 (SEO)

一个网站，如果对搜索引擎有着比较好的友好度，一定会比较有竞争力。

22 . UrlTrends 会显示网站的访客是如何通过搜索引擎来到你的网站，还有各个流量是多少。这些数据是包括 Google, Yahoo, MSN, Alexa, AlltheWeb, AltaVista 和其他一些网站。（ 强烈推荐 ）

23 . iWEBTOOL Backlink Checker 一个很好的工具，它能找出有什么站点链接到你的站点，那些站点是什么类型的站点。

24 . iWEBTOOL Multi-Rank Checker 显示你网站的 Alexa 和 Google PageRank 数值。

25 . Microsoft adCenter Labs: Advertising and Keyword Research Tools 一个极好的工具，用于分析和预测你网站的来访者和市场。（ 强烈推荐 ）

26 . Domain Tools Whois lookup 一个 WHOIS 网络工具。

27 . SEO-Browser 可以让你看到在搜索引擎眼里一样的网站（ 去掉所有的”美丽”配件 ）。

28 . SEO Workers SEO Analysis Tool 非常有用的工具，分析了网站上的各种分类特征，包括 meta 标签、关键字密度及加载时间。（ 强烈推荐 ）

29 . Seekport Seekbot 可以分析网站的数据和内容，以得出搜索引擎会如何有效的解释分析的网站。

30 . SEO Chat SEO Tools 用以分析网站 Google adsense 盈利潜力，关键字密度，Meta tag 等等……

31 . Marketleap Search Engine Marketing Tools 用来分析网页，让你知道你的网站检索、设定的关键字好不好。

原文：avivadirectory.com
译者：peterzsk
译文原地址：http://zsk.akaka.com.cn/2007/06/31-free-tests-online/

如果某项请求发送到您的服务器要求显示您网站上的某个网页（例如，用户通过浏览器访问您的网页或 Googlebot 抓取网页时），服务器将会返回 HTTP 状态代码以响应请求。

此状态代码提供关于请求状态的信息， 告诉 Googlebot 关于您的网站和请求的网页的信息。

一些常见的状态代码包括：

• 200 – 服务器成功返回网页
• 404 – 请求的网页不存在
• 503 – 服务器暂时不可用

下面提供 HTTP 状态代码的完整列表。 点击链接可了解详情。 您也可以访问有关 HTTP 状态代码的 W3C 网页以获得更多信息。

1xx（临时响应）
表示临时响应并需要请求者继续执行操作的状态代码。

2xx（成功）

表示服务器成功处理了请求的状态代码。

3xx（重定向）
要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。 Google 建议您在每次请求中使用重定向不要超过 5 次。 您可以使用网站管理员工具查看一下 Googlebot 在抓取重定向网页时是否遇到问题。 诊断下的网络抓取页面列出了由于重定向错误而导致 Googlebot 无法抓取的网址。

4xx（请求错误）
这些状态代码表示请求可能出错，妨碍了服务器的处理。

5xx（服务器错误）
这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。

最近在迁移写应用到nginx中，在rewrite上面遇到了些问题。
虽然大部分的rewrite规则转换到nginx中几乎改动很小，但是一些特殊的比如下面这段，在nginx里面可以说完全不一样。

1
2
3
4
5

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^.*(\.html|\.xml|\.css|\.js|\.gif|\.png|\.jpg|\.jpeg)$|.*(FCKeditor).*$|.*(fckeditor).*$|.*(userfiles).*|.*(testadow).|.*(api).*|.*(passportcode).*
RewriteRule !\.(js|ico|gif|jpg|png|css)$ /index.php
　　

转换到nginx的写法（只是参照的语法，并不是上面内容的转换）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

location /xxxx/ {
         set  $test "";
 
         if ($request_method = POST) {
             set $test  P;
         }
 
         if ($http_cookie ~* "CCCC=.+(?:;|$)" ) {
             set $test  ${test}C";
         }
 
         if ($test = PC) {
           #rewrite rule goes here.
         }
}