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

Google Code的项目控制因为其简洁深受很多开源作者的喜欢，PT好几个项目都是存放在Google Code上，不过之前遇到了一个些少恼人的Bug：

当建立了Wiki页，因为某种原因重置了SVN仓库，那原来的Wiki页将无法修改、无法删除（返回500 Server Error）。

重置SVN一般属于特殊情况，比如要把另外一个服务器的SVN仓库搬到另外一个SVN，而只保留后来的版本数据，才需要重置SVN仓库。我当时的情况是，不小心把包含自己帐号密码的测试脚本提交了上去SVN；版本管理的特点是版本修改是无法被抹除的，情急之下只好放弃版本痕迹，备份了文件，请求了SVN重置；之后就发现原先的Wiki页无法修改了。

一番查找后，发现Google Code自身的Support里面早有人发现了这个问题，可以看到，这个Bug第一次在2007年11月就有人提出了，一直到现在都陆续有人确认Bug依然存在……所以当时我就没管那个有问题的Ghost Page了，任其放着；两年都没有修复的bug看了没什么好指望的了；

不过最近这个问题有人提出了个颇为纠结的解决办法：创建wiki/the_page文件（跟之前的wikipage同名），然后不断修改递交svn，当svn的revision版本号高于重置之前wiki page最后修改的版本号，就可以修改或者删除这个Ghost Page了……

想到我那个项目现在的版本号早就超过了之前重置SVN仓库时候的版本号，直接跑去wikipage点Delete this page，哈，直接搞定了！

从这个Bug可以透视到Google Code的Wiki页构建机制：Wiki页跟SVN仓库内相应文件是紧密互动的，在Web对Wiki页的修改就相对于直接提交了相应SVN内的文件，当直接修改SVN内的Wiki文件时候，Web上的Page自动根据SVN刷新WEB页的缓冲，并记录文件的修改版本号；而重置了SVN仓库将导致SVN的版本号从0重新开始，这样Wiki页的缓冲模块没法找到相应的版本号对应的wiki文件进行操作，所以报告500错误；只能当版本号重新达到原先的最后修改时，Wiki Web才能正常的和SVN交互。

另外有趣的是，Google的程序员似乎对修复这个Bug没什么兴趣；可能容易引起新的bug吧，呵呵。