<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>芳草苑 &#187; nginx</title>
	<atom:link href="http://blog.goods-pro.com/tag/nginx/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.goods-pro.com</link>
	<description>草的家园，花在哪里？</description>
	<lastBuildDate>Wed, 08 Sep 2010 23:24:07 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>SSL, Nginx and Magento</title>
		<link>http://blog.goods-pro.com/1809/ssl-nginx-and-magento/</link>
		<comments>http://blog.goods-pro.com/1809/ssl-nginx-and-magento/#comments</comments>
		<pubDate>Wed, 01 Sep 2010 23:05:13 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[小小草]]></category>
		<category><![CDATA[magento]]></category>
		<category><![CDATA[nginx]]></category>
		<category><![CDATA[security]]></category>

		<guid isPermaLink="false">http://blog.goods-pro.com/?p=1809</guid>
		<description><![CDATA[SSL, Nginx and Magento 这三件东西对我都不陌生。但三件全排在一起，着实挑战了我一下，发生错误是 secure page redirect loop。
原因是 $_SERVER[] 里缺少 HTTPS directive，需要在 fastcgi_params 里添加一行
fastcgi_param HTTPS on;
以 Magento 1.4.0.1 为例深究一下—— 在 $_SERVER['HTTPS'] 缺失时 app/code/core/Mage/Core/Model/Store.php 的 isCurrentlySecure() 返回值 false，所以 Magento 不停地重定向到 secure url 而不知道当前 url 已经是 secure 了。


public function isCurrentlySecure()
{
if (!empty($_SERVER['HTTPS']) &#38;&#38; $_SERVER['HTTPS'] != 'off') {
return true;
}

if (Mage::isInstalled()) {
$secureBaseUrl = Mage::getStoreConfig('web/secure/base_route_url');
if (!$secureBaseUrl) {
return false;
}
$uri = Zend_Uri::factory($secureBaseUrl);
$isSecure [...]]]></description>
		<wfw:commentRss>http://blog.goods-pro.com/1809/ssl-nginx-and-magento/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>1and1 cloud server datasheet</title>
		<link>http://blog.goods-pro.com/1672/1and1-cloud-server-datasheet/</link>
		<comments>http://blog.goods-pro.com/1672/1and1-cloud-server-datasheet/#comments</comments>
		<pubDate>Wed, 07 Jul 2010 00:07:29 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[小小草]]></category>
		<category><![CDATA[1and1]]></category>
		<category><![CDATA[apache]]></category>
		<category><![CDATA[magento]]></category>
		<category><![CDATA[nginx]]></category>

		<guid isPermaLink="false">http://blog.goods-pro.com/?p=1672</guid>
		<description><![CDATA[从 1&#38;1 新订了一个合同，cloud server，就是为了让 magento 跑快一些。那 1and1 的 cloud server 究竟能有多快呢？
先看看 cat /proc/cpuinfo 的情况
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 2
model name	: Quad-Core AMD Opteron(tm) Processor 2352
stepping	: 3
cpu MHz		: 2109.718
cache size	: 512 KB
fpu		: yes
fpu_exception	: yes
cpuid level	: 4
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush mmx fxsr [...]]]></description>
		<wfw:commentRss>http://blog.goods-pro.com/1672/1and1-cloud-server-datasheet/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Nginx try_files syntax</title>
		<link>http://blog.goods-pro.com/1345/nginx-try_files-syntax/</link>
		<comments>http://blog.goods-pro.com/1345/nginx-try_files-syntax/#comments</comments>
		<pubDate>Thu, 04 Feb 2010 20:01:54 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[小小草]]></category>
		<category><![CDATA[nginx]]></category>
		<category><![CDATA[url rewrite]]></category>

		<guid isPermaLink="false">http://blog.goods-pro.com/?p=1345</guid>
		<description><![CDATA[今天在一台很久不用的服务器上测试 Magento search result page，URL /catalogsearch/result/?q=searchword，发现它不工作，但其他页面正常。这个症状让我联想到以前碰到的类似问题，Magento 无法获得 query_string，所以含问号的 URL 都不能处理，页面重定向到 referring URL。应该是 server rewrite 规则没有写正确，我想。打开 nginx 的配置文件一看，果然，当中一条规则用的是很久以前的写法，后来在不同的服务器上几经改进，production server 都已经用上了新规则。
新规则的写法：

location @magento {
root $php_script_root;
index index.php;
if ($uri ~ ^/(media&#124;js&#124;skin)/) {
break;
}
if (!-e $request_filename) {
rewrite .* /index.php last;
}
}

而老规则的写法：

location @magento {
root $php_script_root;
index index.php;
if ($uri ~ ^/(media&#124;js&#124;skin)/) {
break;
}
try_files $uri $uri/ /index.php;
}

效果略有区别，我在 Difference of try_files to rewrite in Nginx 文章里有提及。不过，今天我还有一个新发现。
我倾向于使用简介语法，try_files 就比 rewrite 简洁得多，难道 [...]]]></description>
		<wfw:commentRss>http://blog.goods-pro.com/1345/nginx-try_files-syntax/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Avoid PEM pass phrase</title>
		<link>http://blog.goods-pro.com/1229/avoid-pem-pass-phrase/</link>
		<comments>http://blog.goods-pro.com/1229/avoid-pem-pass-phrase/#comments</comments>
		<pubDate>Wed, 25 Nov 2009 23:00:14 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[小小草]]></category>
		<category><![CDATA[apache]]></category>
		<category><![CDATA[nginx]]></category>

		<guid isPermaLink="false">http://blog.goods-pro.com/?p=1229</guid>
		<description><![CDATA[我在制作 SSL key file 时输入了一个 pass phrase。CA 把 SSL 证书发给我后，我在 Nignx 试着加载 key 和 证书，发现每次重启 Nginx 时，都会被要求 Enter PEM pass phrase。岂不很烦，而且万一服务器重启，岂不还要人工干预才能重启 web server？
原本以为把 pass phrase 从 key 文件里拿掉后，要找 CA 重新制作证书，后来发现不用，证书跟 pass phrase 无关。Nginx 的文档没有提及，Apache 倒是有提：
If necessary, you can also create a decrypted PEM version (not recommended) of this RSA private key with:

openssl rsa -in server.key [...]]]></description>
		<wfw:commentRss>http://blog.goods-pro.com/1229/avoid-pem-pass-phrase/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Gracefully restart Nginx</title>
		<link>http://blog.goods-pro.com/1047/gracefully-restart-nginx/</link>
		<comments>http://blog.goods-pro.com/1047/gracefully-restart-nginx/#comments</comments>
		<pubDate>Fri, 07 Aug 2009 13:39:56 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[小小草]]></category>
		<category><![CDATA[nginx]]></category>

		<guid isPermaLink="false">http://blog.goods-pro.com/?p=1047</guid>
		<description><![CDATA[Follow these 3 steps to gracefully stop and start Nginx without losing any queries. It works like a charm.

Test new configuration is correct
nginx -t
Find the Pid
ps -ef &#124; grep "nginx: master process" &#124; grep -v "grep" &#124; awk -F ' ' '{print $2}' 
And kill it. Meanwhile, new configuration is already effective.
kill -HUP ????
(replace ???? [...]]]></description>
		<wfw:commentRss>http://blog.goods-pro.com/1047/gracefully-restart-nginx/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Speed bottleneck of the web server</title>
		<link>http://blog.goods-pro.com/1042/speed-bottleneck-of-the-web-server/</link>
		<comments>http://blog.goods-pro.com/1042/speed-bottleneck-of-the-web-server/#comments</comments>
		<pubDate>Tue, 04 Aug 2009 10:46:03 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[小小草]]></category>
		<category><![CDATA[cache]]></category>
		<category><![CDATA[mysql]]></category>
		<category><![CDATA[nginx]]></category>
		<category><![CDATA[php]]></category>

		<guid isPermaLink="false">http://blog.goods-pro.com/?p=1042</guid>
		<description><![CDATA[非常典型的多层架构：
第一层 Nginx
第二层 php fastcgi
第三层 memcached
第四层 MySql
Apache 有个 mod_php，相当于合并了第一层和第二层，Nginx 没有 module for php，这不是什么问题，分层更利于扩展。第三层的加入完全是为了减轻数据库压力，提高性能。目前第2，3，4层之间的优化差不多到极限了（或者说到我能力的极限了），但第1，2层之间尚有潜力可挖。
not_in_use.php 和 not_in_use.html 都是一个静态文件，没有数据库操作。但 php 文件必须由 Nginx 经由 php fastcgi （使用 unix socket）产生，html 则由 Nginx 直接访问文件系统，就单因素分析，php fastcgi 是普通文件系统速度的34%，所以要想办法绕开 php fastcgi。以下测试在数据中心主机上直接运行 ApacheBench。
测试一：
$ ab -kc 100 -n 500 http://magento/not_in_use.php
This is ApacheBench, Version 2.0.40-dev  apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software [...]]]></description>
		<wfw:commentRss>http://blog.goods-pro.com/1042/speed-bottleneck-of-the-web-server/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>php always takes apache as its session owner</title>
		<link>http://blog.goods-pro.com/986/php-always-takes-apache-as-its-session-owner/</link>
		<comments>http://blog.goods-pro.com/986/php-always-takes-apache-as-its-session-owner/#comments</comments>
		<pubDate>Mon, 13 Jul 2009 23:37:01 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[小小草]]></category>
		<category><![CDATA[nginx]]></category>
		<category><![CDATA[php]]></category>

		<guid isPermaLink="false">http://blog.goods-pro.com/?p=986</guid>
		<description><![CDATA[今天用 yum update php 到 5.2.10 版，发现升级了以后 /var/lib/php/session 的 ownship 又成了 root:apache。这有点恼人，难道每次升级我都要手工改一次 chown nginx:nginx /var/lib/php/session? 或是以后用 apache 的身份来跑 nginx? 我觉得都不太好，太多的场合只认 apache as an only http server，搞得 nginx 很孤立 :(
]]></description>
		<wfw:commentRss>http://blog.goods-pro.com/986/php-always-takes-apache-as-its-session-owner/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Difference of try_files to rewrite in Nginx</title>
		<link>http://blog.goods-pro.com/915/difference-of-try_files-to-rewrite-in-nginx/</link>
		<comments>http://blog.goods-pro.com/915/difference-of-try_files-to-rewrite-in-nginx/#comments</comments>
		<pubDate>Sun, 07 Jun 2009 09:23:47 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[小小草]]></category>
		<category><![CDATA[nginx]]></category>
		<category><![CDATA[url rewrite]]></category>

		<guid isPermaLink="false">http://blog.goods-pro.com/?p=915</guid>
		<description><![CDATA[try_files 是 Nginx 自0.6.36 新增的 directive。通常对 try_files 的理解是——它是
if (!-e $request_filename) {
rewrite .* /index.php;
}
的更简洁的表达。但我发现它们之间还是略有区别，主要表现在两点：

 如使用 rewrite，Nginx 要求 document_root 下必须有一个 index 文件，即使我把另一个目录别名整个 document_root，但因为 Nginx 先校验 document_root 下是否有一个 index 文件，所以得放置一个空 index 文件。try_files 则没有 index 文件校验，直接去第二、第三&#8230; document_root 找对应的文件。
 如使用 try_files $uri $uri/ /index.php，index.php 不能取得 get 变量，例如在 Magento 下，对 http://mydomain/catalogname?mode=list 的访问不能起效，Nginx 交付的页面是 http://mydomain/catalogname。这时必须使用 rewrite。这或许是 try_files 的一个 bug。

]]></description>
		<wfw:commentRss>http://blog.goods-pro.com/915/difference-of-try_files-to-rewrite-in-nginx/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Varnish vs Nginx</title>
		<link>http://blog.goods-pro.com/905/varnish-vs-nginx/</link>
		<comments>http://blog.goods-pro.com/905/varnish-vs-nginx/#comments</comments>
		<pubDate>Wed, 03 Jun 2009 18:12:51 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[小小草]]></category>
		<category><![CDATA[nginx]]></category>

		<guid isPermaLink="false">http://blog.goods-pro.com/?p=905</guid>
		<description><![CDATA[Fedora 10 release note 提及 Varnish，据说“Varnish 是一个高性能 HTTP 加速器”，又看了一些其他网站的介绍，据说比 squid 快了好几倍。squid 是什么？没听说过。但既然同是反向代理服务器，Varnish 和 Nginx 相比如何？
我没实测，但引用别人的测试结论：

根据 Connection Times 获知 Varnish 连接速度快于 Nginx，但 Nginx 处理速度快于 Varnish，等待时间几乎一致，总时间 Nginx 要快于 Varnish 15%左右。
根据 HTML transferred 项获知大负载下 Varnish存在较多的丢包问题。

我想我还是坚持走 Nginx，并走好它。
]]></description>
		<wfw:commentRss>http://blog.goods-pro.com/905/varnish-vs-nginx/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Config CentOS to use the latest software</title>
		<link>http://blog.goods-pro.com/871/config-centos-to-use-the-latest-software/</link>
		<comments>http://blog.goods-pro.com/871/config-centos-to-use-the-latest-software/#comments</comments>
		<pubDate>Sat, 23 May 2009 13:20:19 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[小小草]]></category>
		<category><![CDATA[fedora]]></category>
		<category><![CDATA[linux]]></category>
		<category><![CDATA[nginx]]></category>

		<guid isPermaLink="false">http://blog.goods-pro.com/?p=871</guid>
		<description><![CDATA[1and1 VPS OS 可选清单里没有 Fedora，不得不说是个遗憾。当然 CentOS 也不错，可是以前都没接触，使用 CentOS 会有很长的学习过程，但没办法，只能装个 CentOS 用用看。
以前我调查过，CentOS 讲究兼容性，Fedora 追求技术领先。CentOS 安装真得比当初装 Fedora 要容易（Fedora 从6开始到10，我没有一次是一次启动就安装成功的），今天装CentOS 5很顺利（CentOS 兼容性真的那么好？还是我从 Fedora 学来的经验丰富了？）
装完 CentOS，我就面临一个问题：不能 yum install nginx；yum install php 得来的版本也只是 5.1.6。这个简单的比较才觉得 Fedora 的好。我无法想象我还要下载编译 nginx（那一套我还不熟，怕搞砸了）。不过，Extra Packages for Enterprise Linux (EPEL) 已经做好了一个 repository，只要添加这个 repository，
sudo rpm -Uvh http://download.fedora.redhat.com/pub/epel/5Server/x86_64/epel-release-5-3.noarch.rpm
然后就可以用 yum install nginx。
但是，yum install php 得来的版本只能是 5.1.6，目前还没找到好办法。 
]]></description>
		<wfw:commentRss>http://blog.goods-pro.com/871/config-centos-to-use-the-latest-software/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
