我这几天在微博上写了一句话: 回归简单，即便开始反而会变得更加复杂。 回想起当年刚用Django写素材管理系统还历历在目，最近却已经逐渐脱离Django了。 成长总是分阶段的吧，勇敢的抛弃一些东西，接纳新的东西，也许就是成长了。 至于原因呢，也是我一直在总结的，大家可以一起看一下。 Django适合做中型项目，但却不适合小型和大型项目 为什么这么说呢？

• 对于中型项目来说，Django可以说提供了你需要用到的一切，session，orm，admin等等，只要你按照Django规定的思路来，你会发现开发和维护是如此顺手。
• 但是如果是小型项目呢？ 我可能不需要session，我也不需要数据库，但是我却要为Django那些繁琐的东西配置半天。当我被这些繁琐而无用的东西搞晕的时候，我感觉更像是在搭积木，而不是在创造一个伟大的东西。
• 而对于大型项目来说，Django默认带的组件又满足不了需求，甚至连架构都可能要被替换，所以Django所自带的很多特性都将无法使用。 由于工作的关系，在大型项目中，有一类不得不说的服务，那就是SNS应用。 SNS应用的特点是什么？注册用户量极大，活跃很少。大批的用户蜂拥进入可能只是看一眼就再没回来，但是你的数据却因为这些无用的用户变得庞大无比。进而导致Django默认的那些Model，admin全部都形同虚设，Django的那些所谓的优势荡然无存。 博友反馈这里没说清楚，我再描述一下:
  1. 互联网的数据模型与关系数据模型不匹配。互联网数据更适合NoSQL，所以Admin对关系（外键、关联）的处理就没有任何用处了，而直接展示一个blob字段也并没有比用sql语句直观多少。（BTW ...

之前的文章已经提到了 django+fastcgi的运行并不如意（web.py+spawn-fcgi却正常很多……），所以特意抽时间研究了一下uwsgi，试了一下，运行的很好，也很快，哈哈。 所以笔者的所有之前用apache+django搭建的项目（如fuload等）都已经替换成了nginx+django+uwsgi。 一.安装uwsgi

1. 到http://projects.unbit.it/uwsgi/wiki/WikiStart#Getit 下载最新版本的uwsg。
2. 解压后,如果没有安装libxml2，又不想安装的话，那么编辑文件 buildconf/default.ini， 把

   xml_implementation = libxml2
   

   改成

   xml_implementation = false
   

3. 执行编译

   python uwsgiconfig.py --build
   

4. 执行安装

   python setup.py install
   

这样 ...

在上一篇文章linux下nginx+python+fastcgi部署总结(django版)中，我们部署了nginx+django+fastcgi的环境，这次我们来部署一下nginx+web.py+fastcgi。 其实web.py上的官方网站已经说的比较清楚了，原文如下: http://webpy.org/cookbook/fastcgi-nginx 这里主要讲一下一些原文没有照顾到的地方。

一.安装依赖

spawn-cgi

lup

二.配置nginx

在server配置项下增加

location / {
    #这两种方法都可以，只不过spawn-cgi启动的方法不同
    #fastcgi_pass 127.0.0.1:9002;
    fastcgi_pass unix:webpy.sock;

    fastcgi_param REQUEST_METHOD $request_method;
    fastcgi_param QUERY_STRING $query_string;
    fastcgi_param CONTENT_TYPE $content_type;
    fastcgi_param CONTENT_LENGTH $content_length;
    fastcgi_param ...