So I wrote this script to make my life easier, only to provide basic infomation like the server IP, and those configuraion will be done at the background, then tared packages are ready there for both server and clients.

Source is available at Google Code.

Script is recommanded running at your work station, and then upload only the server part tared file to the server, for secure concideration.

Features

• Provide tared config which ready for any server distribution.
• Random VPN subnet will be generated to avoid conflicting.
• Random digital subffixed server/client CommonName will be assigned (if you don't provide one) for clearer management.
• Configuration file is copied from the distributed OpenVPN in your system, which include full explnations of different options when you have to edit them. Default values is set by sed.
• tls-auth enabled by default.

Usage

For new setup:

1

./ovpn_menu.sh

Just do as promoted. When select 5 to exit, all the files will be packed into a single NAME-all.tar.gz, you should save it to somewhere safe. And if you want to sign some more certificate from this root ca, put this tar file as the argument.

1

./ovpn_menu.sh /path/to/YOUR-VPN-all.tar.gz

At last the script also provide you iptables commands that should be useful to setup the server.

Download

Direct download via wget/curl should be ok:

http://ptcoding.googlecode.com/git/ovpn_menu.sh

Ubuntu 10.04 这个版本已经服役两年，虽说是LTS，但最近起发现已经有点力不从心，主要是ppa上一些比较重要的库，如PHP 5.3，ningx的团队已经停止维护，uwsgi则总是落后半年的样子。很大一个原因是这些包在新版的Ubuntu里面已经有官方维护，ppa的第三方维护会缺乏跟进。所以在一定意义上，可以宣布Ubuntu 10.04死亡了。

但Ubuntu的包维护策略就是那样，要么自己维护所有用到的包，要么每隔一段时间就跟着官方一次大升级。觉得不爽就干脆把VPS的系统也改成Archlinux。

现象

一番大迁移后所有的东西都正常上线，但直到一个多星期后的昨天晚上才注意到博客的性能问题。 因为博客那里有nginx直接读取静态的缓冲机制，所以动态执行非常慢之前都没留意到。

把缓冲关闭就非常明显了，任何一次点击的页面都要10秒才能打开。

排查

引起应用缓慢的因素是非常多的，概括来说有两种：IO慢、运算慢。

运算慢是不大常见的，虽说PHP性能一直受到诟病。但如果是这个问题是很明显的，top里面php的子进程会占满CPU，高居不下。此前排查过一个drupal的站点，是因为前端模板的组件方式存在循环引用，用profile过程看，正则替换的regrex函数占了绝大多的CPU时间。

在SSH看到，打开页面的10秒内php-fpm的子进程基本没占CPU，排除这个可能。

IO慢就复杂了，每个组件都有IO，得先确定IO的范围。

首先想到是数据库Mysql，arch的包太新，有bug？linode主机的磁盘快挂了，磁盘很慢？这些都不好判断，确定这些得借助工具。

Profiling是追踪一个应用的运行流程，记录所有的函数调用栈、记录调用时间的过程，是追查性能问题的最佳帮手。Python里面是有个repoze.profile的wsgi中间件很方便进行排查，但我没做过完整PHP开发，就暂时不大清楚有什么方便的profile方案 （以前弄过早忘了），但google一下还是有很多方案的 ，不过我首先想起newrelic的应用监控系统就提供了这个功能。

Newrelic针对WEB应用和服务器监控服务，其中的服务器监控是免费的，但对应用的监控只有14天试用；所以我赶紧重新申请个帐号，用来监控一下wordpress。安装好监控模块后，超过2s的响应会在他们的Transaction traces记录下来。

图表数据可以排除数据库问题，几十个数据库的操作都是在ms级别完成，而在apt-blog.net的耗时花了10秒。其实我一开始对这个报告也没看懂，newrelic的直观性还有待提高，其实在这里出现域名的意思是有网络请求，比如askimet的评论、插件的更新等都要和外部请求，这里就会出现域名。

而现在出现了自己博客的域名，那问题就是，程序里面某个地方需要请求自己的域名，可能是检查状态的操作，被卡住了，直到超时才返回。

本机程序访问不到本机，基本确定是iptables规则出问题了，在filter表的最后插入这样一句：

-A INPUT -j LOG

iptables的规则一般是，除非明文允许，否则拒绝，所以经过一系列的规则后如果还没有没ACCEPT的，在最后的都是被DROP了，把这句放最后可以看到究竟是什么包被DROP了。

查看/var/log/everything.log看到这样的记录：

Mar 31 03:17:32 (none) kernel: [17554800.765033] IN=lo OUT= MAC=00:00:00:00:00:0 0:00:00:00:00:00:00:08:00 SRC=106.187.36.50 DST=106.187.36.50 LEN=60 TOS=0x00 PR EC=0x00 TTL=64 ID=31529 DF PROTO=TCP SPT=45594 DPT=80 WINDOW=32792 RES=0x00 SYN URGP=0

这里透露了重要信息：IN=lo SRC=106.187.36.50 DST=106.187.36.50，PHP确实有访问本地网络，送了给lo网卡，SRC和DST都是本地的公网地址。赶紧检查iptables的规则，果然没了对lo设备的允许规则。一般配置机器我都是用记录在自己的Wiki的iptables那套规则的。关于lo的这几句可能一时没仔细想其作用，迁移系统那天脑抽手贱就删掉了。

加入允许lo设备的这句：

-A INPUT -i lo -j ACCEPT

至此，问题解决。

我家里用的是一家三线的便宜小区宽带，标称有几个M的带宽，虽说有些资源确实能达到这个速度，但发现直连VPN的速度从来都没上去过，大概30k/s，不难猜测到，ISP在链路上做了手脚，即所谓的Layer 7 Priority QoS。因为入线是100M进宅然后PPPoE，不像ADSL那样直接物理链路就限制了连接速度，在链路层做QoS也很合理。平时HTTP打开网页、下载到合适链路的话很容易达到满速，而OpenVPN的TCP/UDP包估计就被当成P2P流量被限制了，所以网速一点都不给力。

用OpenVPN科学上网是最稳定最灵活的方式了，它基于udp/tcp的协议，比pptp、l2tp等直接跑IP包的开销虽说大一点，但好处就是容易把数据流重新封装，避开链路的关卡。显然它也支持HTTP代理，所以把OpenVPN变成HTTP协议，就可以在家里跑上满速的VPN。

How

OpenVPN要过HTTP代理，只能用TCP协议，这个需要服务端和客户端都要稍作修改。

Polipo as Tunnel Proxy

首先在VPS上安装一个http proxy，我选择polipo，比较轻量级。

apt-get install polipo

配置也是很简单的，编辑/etc/polipo/config，原来的配置文件基本全都是注释，直接在文件底部加上：

proxyAddress = "0.0.0.0"
proxyPort = 8128
authCredentials = "user:password3.141592654"
tunnelAllowedPorts = 1194

• polipo默认只监听本地的127.0.0.1，要拿来做服务就要监听外网
• polipo默认监听8123，为了不让扫代理的盯上，自己随便写个端口
• 加上http basic验证，这个密码不要紧，后面让openvpn自动应答
• 允许管道模式连接openvpn的1194端口

OpenVPN

Server

服务端倒是不需要很多配置，确定是tcp模式监听连接（我是多开一个openvpn server，子网错开，个人喜欢吧）

Client

客户端就要指定使用代理的方式：

remote 127.0.0.1 1194
http-proxy YOUR.VPS.IP.HERE.com 8128 pw.txt
http-proxy-retry

这个pw.txt是上述的HTTP的认证信息，用户名密码各一行。

现在连接OpenVPN，可以看到连接过程的Log有这么几句，基本就确定OpenVPN over HTTP成功了！

Sun Mar  4 19:12:58 2012 Attempting to establish TCP connection with 199.101.103.107:8192 [nonblock]
Sun Mar  4 19:12:59 2012 TCP connection established with [IPADDR]:8128
Sun Mar  4 19:12:59 2012 Send to HTTP proxy: 'CONNECT 127.0.0.1:1194 HTTP/1.0'
Sun Mar  4 19:12:59 2012 Attempting Basic Proxy-Authorization
Sun Mar  4 19:13:00 2012 HTTP proxy returned: 'HTTP/1.1 200 Tunnel established'

Related

最后透露一下我的科学上网环境是在跑OpenWRT的路由器上跑VPN，然后配合chnroute的路由表，当然dnsmasq也经过配置负责把国内常用域名的解释交给国内的114.114.114.114服务器，这样基本一回家手机kindle电脑等全都是翻墙环境，而且速度非常良好。

Reference

• The Polipo Manual

但是有时候某台工作站没有打开这个VNC服务，只有SSH，但是又必须通过桌面来操作，这时候自带的vino server就好像不容易跑起来。

x11vnc这个小工具就可以派上用场，它对当前的x11 session建立VNC服务，很简单直接运行x11vnc，就等你连接5900端口了。当然，如果一定要指定一个session，有个-display参数可以指定，或者看看x11vnc --help，好长好长～～～

UPDATE: 2012/03/15 Nginx的ppa团队决定不再维护php包了……所以只能用别人的ppa..

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

apt-get install python-software-properties
add-apt-repository ppa:nginx/stable
#add-apt-repository ppa:nginx/php5 #not valid any more
add-apt-repository ppa:brianmercer/php5
 
#Ubuntu 10.10 以后可不需添加以上源
 
apt-get update
apt-get install nginx
apt-get install php5-cgi php5-mysql php5-fpm php5-curl php5-mcrypt
 
#或者你需要更齐全的php包：
#aptitude install php5-cgi php5-mysql php5-fpm php5-curl php5-gd php5-idn php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-mhash php5-ming php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl
 
service nginx start
service php5-fpm start

FPM Tunning

php5-fpm默认参数启动的服务器还是比较耗资源的，如果环境不充裕（如512内存以下的VPS），可以做下配置。

这个包的fpm的默认配置文件是/etc/php5/fpm/main.conf，但对子进程的配置是在其包含的/etc/php5/fpm/pool.d/目录内，里面有个www.conf，可以对以下的参数做以下修改：

pm = dynamic              ;动态管理php-fpm的子进程
pm.max_children = 5       ;最多的时候开不超过5个
pm.start_servers = 2      ;启动服务时候开2个
pm.min_spare_servers = 2  ;空闲时候最少留2个
pm.max_spare_servers = 5  ;最多留5个
pm.max_requests = 300     ;每个子进程最多处理300个请求就退出换新的子进程。

按需调整这些参数可以达到最佳动态分配资源的效果。

如果单独一个hg仓库，直接运行hg serve就已经是在线仓库，用nginx做的http_proxy反向代理就够了，各种功能齐全。但是要host多个hg仓库，需要用hgwebdir。

Ubuntu当中安装的mercurial已经包含了架设仓库所用的程序，包括cgi/fcgi/wcgi的，主接口在/usr/share/doc/mercurial-common/examples下的hgwebdir.(ws|(f)c)gi。虽然其中的wsgi有效的只有三行。

Mercurial官方Wiki上主要介绍了用apache2来跑cgi方式的仓库，但是作为python的程序，wsgi才是最原生的嘛。用Nginx+uwsgi的方式，资源占用、响应效率等，都要比apache + cgi靠谱。

Nginx+uwsgi的方式很普遍，参见本博客之前的MoinMoin 与 Nginx, fastcgi 与 uwsgi 的配置一文。

但是因为uwsgi处于快速开发过程当中，ppa的打包也还不十分成熟，里面的路径跟以前有些不一样了。

add-apt-repository ppa:nginx/stable
add-apt-repository ppa:uwsgi/release
apt-get update
apt-get install nginx uwsgi-python python-virtualenv mercurial
 
mkdir -p /var/www/hgwebdir
virtualenv /var/www/hgwebdir/python-home
 
cat >/var/www/hgwebdir/hgwebdir_wsgi.py << EOF
from mercurial import demandimport; demandimport.enable()
from mercurial.hgweb.hgwebdir_mod import hgwebdir
 
class hgwebdir_with_fixed_staticfile(hgwebdir):
    def __call__(self, env, respond):
        response = super(self.__class__, self).__call__(env, respond)
        return response[0] if isinstance(response, tuple) else response
 
application = hgwebdir_with_fixed_staticfile('/var/www/hgwebdir/hgweb.config')
EOF
 
cat >/var/www/hgwebdir/hgweb.config << EOF
[collections]
/home/hg-repo = /home/hg-repo
 
[web]
style = monoblue
allow_archive = gz, zip, bz2
baseurl = /
push_ssl = true
hidden = false
allow_read = *
allow_push = user1 user2
 
[extensions]
#highlight =
EOF
 
cat >/etc/uwsgi-python/apps-enabled/uwsgi.xml << EOF
<uwsgi>
  <limit-as>256</limit-as>
  <processes>6</processes>
  <memory-report/>
  <vhost/>
  <no-site/>
</uwsgi>
EOF
 
cat >/etc/nginx/sites-enabled/hgwebdir << EOF
server {
    listen   80;
    client_max_body_size 512m;
    server_name hg.mydomian.com;
    location / {
                include uwsgi_params;
                uwsgi_pass unix:///var/run/uwsgi-python/uwsgi/socket;
                uwsgi_param UWSGI_PYHOME /var/www/hgwebdir/python-home;
                uwsgi_param UWSGI_CHDIR /var/www/hgwebdir/;
                uwsgi_param UWSGI_SCRIPT hgwebdir_wsgi;
                uwsgi_param UWSGI_SCHEME \$scheme;
                uwsgi_param REMOTE_USER \$remote_user;
        }
}
EOF
 
mkdir /home/hg-repo
cd /home/hg-repo
hg init example-repo1
hg init example-repo2
chown -R www-data:www-data /home/hg-repo
 
/etc/init.d/nginx restart
/etc/init.d/uwsgi-python restart

所以，/home/hg-repo下的所有仓库(新建的两个空仓库example-repo1/2)都会被hgwebdir列表在目录上，直接使用其地址就可以pull/push了。

注意的是hgweb.config文件里面的配置，push_ssl = true只允许使用https协议的时候push，也就是需要另外配置一个支持https的nginx。这个属于nginx的基本配置，这里不重提了。

对于不公开的仓库，除了HTTPS，还需要用户名密码，只需要配置nginx的basic http auth，上面命令当中的uwsgi_param REMOTE_USER $remote_user一行配置会把http auth的USER通过协议发送到hgweb，完成其认证过程。

其实hgweb的认证仅仅是用户名的匹配，hgweb.config里面的allow_push = user1 user2是全局设定，各个仓库的.hg/hgrc里面的同样的[web]区下也可以定义allow_push/read，即仓库各自的读写权限。

hgweb.config中注释掉的highlight一行，是启动语法高亮插件用的，打开需要先安装python-pygments包，不然会出错。

这个版本的uwsgi程序的log在/var/log/uwsgi-python/uwsgi.log，如果出任何问题，大概看看log的提示按提示去修复即可。

Update: 2011-3-17

原hgwebdir的程序跟wsgi2协议兼容不好，会出现仓库目录的首页里面的静态文件全部无法打开，log里面的信息是invalid WSGI2.0 response size: 1 .。 上述代码中已经修复（见1楼留言。） Thank You, Leonid.

Vimpress had been updated to 2.x, usage and configurations are now different, read the officle page in vim.org:

http://www.vim.org/scripts/script.php?script_id=3510

If you noticed Vimpress before and got more than one wordpress to write, must glad now to know this VimRePressed support multiple configs and swith freely.

The new VimRePressed (Version: 1.2.0) Changes:

      Add: MarkdownPreview command to preiview markdown in browser.
      Add: MarkdownNewPost command to convert a markdown
           written post into html and set to the new post view.
      Add: Move blog configs info to personal .vimrc
      Add: Multiple config is now supported, and with :BlogSwitch
           command added.
      Add: Show which blog your editing at :BlogList view.
      Fix: Running :BlogList in the List view got error.

Now you got to wirte your blog config in your own ~/.vimrc file. (CAREFUL when your share your vim configure with others then. Use a source my_vimpress.vimrc instead. )

let VIMPRESS=[{'username':'user',
              \'password':'pass',
              \'blog_url':'http://your-first-blog.com/'
              \},
              \{'username':'user',
              \'password':'pass',
              \'blog_url':'http://your-second-blog.com/'
              \}]

The syntax looks just like python or json, dictionarys in a list(or array), only that line brake need to write in the vim way.

BlogSwitch command rotate you from the first blog to the last, then the first. If you got confused, BlogList command can show you which one you're connecting to.

Then the Markdown support. I added two command to save my time saving .mkd file then convert them into html then check in a browser, MarkdownPreview command can do this for me. When flawless, the MarkdownNewPost command switch me to the new post view with all thing I write into html, which is ready to publish.

Download: from google code

SVN Version also available:

1

svn checkout http://ptcoding.googlecode.com/svn/trunk/vimpress

但是Nginx的改写规则就没这么容易让代码来配置了，虽然wp-super-cache的第二种缓存方式就是为这种使用环境设计，但实际上是用了PHP来提供静态数据了，在使用apache benchmark压力的时候，php-cgi依然占很高的CPU占有率。

通过编写nginx的rewrite规则还是可以让nginx直接读取静态文件，参考来自Code Exchange: nginx rewrite rules for WordPress + WP Super Cache，这里的配置被很多地方引用过，但实际尝试使用过程看到那里面的代码还需要微调。

    server {
        listen          80;
        server_name     apt-blog.net;
        root    /var/www/pt-sites/wordpress;
        index   index.html index.htm index.php;
        location / {
                # enable search for precompressed files ending in .gz
                # nginx needs to be complied using –-with-http_gzip_static_module
                # for this to work, comment out if using nginx from aptitude
                gzip_static on;
 
# if the requested file exists, return it immediately
                if (-f $request_filename) {
                        break;
                }
 
set $supercache_file '';
                set $supercache_uri $request_uri;
 
if ($request_method = POST) {
                        set $supercache_uri '';
                }
 
# Using pretty permalinks, so bypass the cache for any query string
                if ($query_string) {
                        set $supercache_uri '';
                }
 
if ($http_cookie ~* "comment_author_|wordpress|wp-postpass_" ) {
                        set $supercache_uri '';
                }
 
# !!!! IMPORTANT
                # if we haven't bypassed the cache, specify our supercache file
                if ($supercache_uri ~ ^(.+)$) {
                        set $supercache_file /wp-content/cache/supercache/$http_host/$1/index.html;
                }
 
# only rewrite to the supercache file if it actually exists
                if (-f $document_root$supercache_file) {
                        rewrite ^(.*)$ $supercache_file break;
                }
 
# all other requests go to Wordpress
                if (!-e $request_filename) {
                        rewrite ^(.*)$ /index.php?q=$1 last;
                }
 
}
        location ~ \.php$ {
              include        fastcgi_params;
              fastcgi_pass   127.0.0.1:9000;
              fastcgi_index  index.php;
              fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        }
    }

需要重点关注的是set $supercache_uri这一行，这里的路径是wp-super-cache生成静态文件的路径，配置文件起作用的时候，这个路径会和$document_root组成最终静态文件的绝对路径，最终输出文件。所以如果这个路径不对的话，最终还是交给了index.php，缓冲就不起作用了。

wp-super-cache在wordpress目录/wp-content/cache/supercache/$http_host/下生成了各个请求url的目录，目录下是一个index.html静态文件，可以在wordpress工作时候，在这个目录下用命令watch find观察（在缓冲不多的情况下），总之小心的把这个路径写好，因为估计每个博客的permanent link的样式都不一样，wp-super-cache生成的目录也不一样，需要仔细调试一下。

当然这里的规则并没有安全包含了wp-super-cache 插件的功能，比如识别手机客户端之类的，如果需要还得仔细根据插件生成的.htaccess规则来添加到nginx。

完成后用apache benchmark压一下，Request per second应该很容易上百，而且php-cgi应该不会出现在top的列表前面了，CPU应该集中在nginx的子进程上，而且都是个位数CPU占有率，系统的load非常低。

Tips: 发现测试结果不对时，可以尝试删除/wp-content/cache整个目录，让wp重新生成所有缓冲。

顺便说一下，如果仅使用ab测试压力，用不着安装整个apache2，只需要apt-get install apache2-utils。

• 5.0系统断网自动修复程序黑莓断续膏(AntiBrokenNet！)
• BrokenNetFixup断网修复工具

区别是前者后台自动修复，后者要手动运行修复。

从网友的留言看出，虽然软件虽然有效，但没有稳定的服务器，软件刚出现时候确实有一批地址提供了服务，但很快就失效了。北京小C这里提供了模拟MDS服务器的程序，是VC写的一个小UDP服务器，虽然原理很简单，但用一台Windows的服务器来跑成本太高了，当然很难稳定提供。

其实服务只是很简单的几行代码，稍微改了一下就可以在Linux下面运行。一台低端Linux VPS的费用大概一年200RMB，这个费用对大多数人来说都不是什么问题的，所以推荐想要稳定防断网服务器的人去弄一台，一台可以很多人共享了。VPS侦探 、Lowendbox上有很多这样的推荐。

Linux版本的MDS服务器代码在Google Code上，可以直接下载。

在服务器（Debian/Ubuntu系统）上编译并运行：

1
2
3
4
5

sudo apt-get install build-essential
wget http://ptcoding.googlecode.com/svn/trunk/mds_server.c
gcc -Wall -o mds_server mds_server.c
sudo cp mds_server /usr/local/bin/
/usr/local/bin/mds_server

现在可以设置手机的续断软件使用这个服务器来连接断网测试了，手机连接的时候，会实时打印出手机的连接信息跟PIN码。

当然最好把程序加入系统自动启动：

sudo touch /var/log/mds_server.log
sudo chown nobody /var/log/mds_server.log
sudo sed -i '/^exit 0/isu nobody -c "nohup /usr/local/bin/mds_server >>/var/log/mds_server.log &"' /etc/rc.local

这样程序会在系统启动后自动在后台运行，运行的LOG会记录在/var/log/mds_server.log文件当中。

下面也无偿提供一枚MDS服务器，就是跑在我的Linux服务器上的。

地址：119.134.250.11
端口：19781

另外服务端口可以修改源代码里面的宏：

1

#define LOCAL_SERVER_PORT 19781

Wiki我选择了用Python的MoinMoin，一定程度上受CPYUG社区 ZoomQuiet 大妈的推荐影响，首次试用感觉非常impresive，所以就定了。再加上 GraphViz 工具的支持，实在的强大。

在vps上服务，肯定是无视apache的，内存有限。之前架设过用来上Twitter奶瓶腿，是Nginx + php-cgi的方案，nginx是必须的。

Python跟web前端的架构方式有太多选择了，五花八门，MoinMoin的发行包里面都提供了moin.cgi moin.scgi moin.ajp moin.fcgi moin.wsgi等多种启动方式。MoinMoin里面全部通过内置的flup作为中间件提供这些接口，目前我仅尝试使用了fastcgi和wsgi。

虽然解压了moin的源码包就可以直接运行里面的wikiserver.py来本地访问了，但在服务器上通常是由nginx/lighttpd等服务来综合转发。php的话是通过spawn-fcgi启动一些php-cgi的进程，服务器接受到动态的请求就通过本地socket跟php-cgi通讯，返回的结果展现回给客户。php-cgi是使用FastCGI协议的。

MoinMoin 源码当中wiki/server/moin.fcgi就是一个类似php-cgi功能的fastcgi服务，类似地可以使用spawn-fcgi来启动moin.fcgi，作为后端的处理进程。

Running MoinMoin Wiki with Nginx via FastCGI and Flup该文章很形象解释了fastcgi的角色，以及提供了一段很方便的服务脚本来启动spawn-fcgi。

Client ----> Nginx Web Frontend -----------+
                                           | fastcgi_pass
                                          \|/
                            +-------------------------+
              moin.fcgi     | spawn-fcgi-moin.socket  |
spawn-fcgi ---------------> |           or            |
                            |     localhost:port      |
                            +-------------------------+

但是文章当中的nginx配置不完整，而且复杂了，这是我的配置：

server {
        listen   80; ## listen for ipv4
        server_name  wiki.apt-blog.net;
 
        access_log  /var/log/nginx/wiki.apt-blog.net.access.log;
        error_log   /var/log/nginx/wiki.apt-blog.net.error_log;
 
        location / {
                include fastcgi_params;
                fastcgi_param PATH_INFO $fastcgi_script_name;
                fastcgi_param SCRIPT_NAME /;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                if (!-f $request_filename) {
                        fastcgi_pass unix:/var/run/spawn-fcgi-moin.socket;
                }
        }
}

当然那文章中的配置有考虑对静态文件直接由nginx服务，不通过flup这一层，有一定优化，这里省去了这些。其实增多一个/moin_static193(据版本号不同而不同)的location即可，可参考后面使用uwsgi做服务时候的配置。

文章还提到wikiconfig.py里面一个fix_script_name变量，是1.9版本新加入的，需要xxx.com/wiki这样访问的童鞋就不用像以前版本那样要在nginx配置里面写一大堆东西了。

Fastcgi就这么多，不算太复杂。Fastcgi虽然很流行，但弊端不少，首先是速度，在一台虚拟机上测试，用ab居然跑出每秒20个请求的速度……虽然平均下来还是有5、60次，但真的，唉。php-cgi还支持产生多个工作进程以并行和均衡请求，提高效率，fastcgi似乎就没这样的东西了。

刚好这天observer专栏杂记写了一篇配置Nginx＋uwsgi更方便地部署python应用，当中也提到fcgi和 mod_python的各种不便，然后介绍了uwgi，高性能、多应用。

uwgi充当了python解析器的角色，使用wsgi的接口和Python程序交互，这个过程中做了优化，和上层nginx之间则设计了更加轻量的协议。nginx0.8.40以后官方默认带了uwgi的协议模块，所以使用很方便。

uwgi的文档有些简略，但是重点都是在wiki/Example里面了。 MoinMoin在uwgi的配置在其中一句带过：

/usr/bin/uwsgi -s /tmp/moin.sock --wsgi-file wiki/server/moin.wsgi -M -p 4

uwgi的-w参数是把某个py文件作为module，import使用，但是wsgi文件不被认识，所以新版里面多了这么个--wsgi-file参数。但是如果是多站点呢！

nginx配置的虚拟主机里面的uwsgi_param UWSGI_SCRIPT参数会让uwgi按模块导入名称，相当于命令行里面的-w，但是moinmoin的moin.wsgi文件，不是py结尾，只能用--wsgi-file参数。扫了一圈uwgi的wiki/Example和RunOnNginx，都没提到这个问题，倒是在这里提到在旧版的uwgi当中没有--wsgi-file参数，需要把wsgi文件改名成py结尾来导入，好吧，确实那样成功了。

至于性能，一开始我发现uwgi占的内存也不少，一个worker时候就占了20M多的内存，所以没开更多的工作进程；Fastcgi也差不多，然后用Apache Benchmark测试，好像两者区别不大。于是看了下fcgi vs. gunicorn vs. uWSGI的测评，才发现uwgi要开多个worker进程才有性能！于是开了8个，性能出来了，秒请求马上就上千！ 显然是uwgi打开了多个进程，充分利用了机器的CPU，还做了均衡请求。

最后，我的Wiki使用uwgi后的nginx配置：

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

server {
    server_name  wiki.apt-blog.net;
    access_log  /var/log/nginx/wiki.apt-blog.net.access.log;
    error_log   /var/log/nginx/wiki.apt-blog.net.error_log;
    location / {
        include uwsgi_params;
        #uwsgi_pass 127.0.0.1:9096;
        uwsgi_pass unix:///tmp/uswgi.sock;
        uwsgi_param UWSGI_PYHOME /usr/local/lib/moinmoin;
        uwsgi_param UWSGI_CHDIR /var/local/wiki-moinmoin/server;
        uwsgi_param UWSGI_SCRIPT moin_wsgi;
    }
    location /moin_static193/ {
        alias /usr/local/lib/moinmoin/lib/python2.6/site-packages/MoinMoin/web/static/htdocs/;
    }
}

完整配置指南：

#安装
sudo -s
add-apt-repository ppa:nginx/stable
add-apt-repository ppa:uwsgi/release
apt-get update
apt-get install nginx uwsgi-python python-virtualenv
 
#组件配置
cat >/etc/uwsgi-python/apps-enabled/uwsgi.xml << EOF
<uwsgi>
  <limit-as>256</limit-as>
  <processes>6</processes>
  <memory-report/>
  <vhost/>
  <no-site/>
</uwsgi>
EOF
 
cat >/etc/nginx/sites-enabled/moinmoin << EOF
server {
    listen   80;
    access_log  /var/log/nginx/wiki.access_log;
    error_log   /var/log/nginx/wiki.error_log;
 
    client_max_body_size 64;
    server_name wiki.mydomian.com;
    location / {
                include uwsgi_params;
                uwsgi_pass unix:///var/run/uwsgi-python/uwsgi/socket;
                uwsgi_param UWSGI_PYHOME /var/www/moinmoin/python-home/;
                uwsgi_param UWSGI_CHDIR /var/www/moinmoin/;
                uwsgi_param UWSGI_SCRIPT moin_wsgi;
                uwsgi_param UWSGI_SCHEME $scheme;
                uwsgi_param REMOTE_USER $remote_user;
        }
}
EOF
 
#Python环境预备
mkdir /var/www/moinmoin
virtualenv /var/www/moinmoin/python-home
cd /tmp
wget http://static.moinmo.in/files/moin-1.9.3.tar.gz
tar xvfz moin-1.9.3.tar.gz
source /var/www/moinmoin/python-env/bin/activate
cd /tmp/moin-1.9.3
python setup.py install
deactivate
 
#MoinMoin环境
cp -r /tmp/moin-1.9.3/wiki /var/www/moinmoin
cd /var/www/moinmoin/wiki
cp config/wikiconfig.py wikiconfig.py
cp server/moin.wsgi moin_wsgi.py
sed -i '/# a2)/isys.path.insert(0, os.path.abspath(os.path.dirname(__file__)))'
 
#可选
rm -rf config server
 
#重启
/etc/init.d/nginx restart
/etc/init.d/uwsgi-python restart