在很早的时候，就听网上的文章说:

python有GIL，所以在单进程内，即使使用多线程也无法利用到多核的优势，同一时刻，python的字节码只会运行在一个cpu上。

以前也是奉为真理，直到今天在对自己的python server做性能测试的时候，发现一个python进程的cpu居然达到了120%。

当用c++编程的时候，如果使用多线程，那么确实进程cpu超过100%非常正常，但是对python来说，似乎这样就和网上的文章冲突了。

所以还是决定自己亲身试验一下，编写代码如下：

from thread import start_new_thread

def worker():
    while 1:
        #print 1
        pass

for it in range(0, 15):
    start_new_thread(worker, ())


raw_input()

运行环境为： centos6.4 64位， python 2.7.

得到的结果如下:

可以清楚的看到，pid为31199的python进程cpu达到了787.9%，接近理论能达到的最大值 800%。

而上方的8个cpu也分别达到了近100 ...

测了一下django、flask、bottle、tornado 框架本身最简单的性能。对django的性能完全无语了。

django、flask、bottle 均使用gunicorn+gevent启动，单进程，并且关闭DEBUG，请求均只返回一个字符串ok。

tornado直接自己启动，其他内容一致。

测试软件为 siege，测试os为cenos6 64位，测试命令为:

siege -c 100 -r 100 -b http://127.0.0.1:5000/

django测试结果为:

Transactions:		       10000 hits
Availability:		      100.00 %
Elapsed time:		       18.51 secs
Data transferred:	        0.02 MB
Response time:		        0.18 secs ...

经过这么久在android客户端和服务器端的开发，感觉还是积累了不少东西想要和大家分享一下，但是好想单独拎一个点出来又不太值得，所以就汇集到一起写成系列吧。

一. 关于用户数据存储

首先在注册的协议里，定义如下公共传输字段：

version: 这个其实是xml中配置的versionCode。versionName个人认为没有什么必要，所以就不传了。

channel:  用户渠道，这个和xml中的UMENG_CHANNEL 是共用的，因为一直在使用umeng，所以这样定义反而清楚一些。

device_id: 设备ID

os: 操作系统类型，这里默认传入android

os_version: 操作系统版本

对于小数据量，用户数据存储在mysql中是相对较好的选择，这里直接以django的model为例：

from django.db import models
class User(models.Model):
    device_id = models.CharField(max_length=255, null=True, blank=True)
    version = models.IntegerField()
    channel = models.CharField(max_length=64, null ...

其实之前就有写过关于python web开发框架选择的文章，之前最终选择了bottle，并给出了bottle开发的物理设计，详见之前的文章：回归简单，向Django说再见、bottle做web开发的物理设计，然而经过最近两个星期的实践，又有了一些新的想法。

Bottle作为一个微框架，本身确实有些小型项目的缺点，尝试列举如下:

• 没有原生支持unicode

例如route('/')获取的name并不是unicode类型，get和post的参数也默认并非unicode类型，虽然作者后来在0.10版本中给query和forms加入attr方式来解决这个问题，但是还是有所限制
而flask则是 unicode based，对unicode支持的非常好

• 影响力小，与其他组件的结合比较差

一个典型的例子就是wtforms不支持bottle的files字段，而flask虽然也不支持，但是flask的插件flask-wtforms则完美修正了这个问题

• 功能太基本

关于这一点，可以说是优点也可以说是缺点。绝对的纯粹看起来是件好事，但是真正开发起来又发现完全不是那么回事，自己要重新开发的轮子实在太多了。比如session的支持

• bottle由个人开发，有些地方并不那么专业

比如route的参数method=['GET','POST']，因为是数组，所以用methods更合适；request.forms其实用request.form更合适
再比如static_file函数，必须要求传入一个root_path和一个filename；而flask则有两个函数一个send_file和send_from_directory，支持直接返回file内容

反观flask，不能说flask的一切都是好的，但是确实在这几点上要比bottle做的要好一些，而且flask还有一些很实用的功能，比如实时debug ...

前段时间一直没写博客，昨天更新了一篇，今天突然又来了兴致，那就再更新一篇吧（所以说啊，治疗拖延症最好的方法就是现在开始做） 这篇还是一些技术的整理，主要是用于备忘，大家如果觉得太简单就一笑而过啦~

一. python通过图片内容判断图片类型

前段时间写了一个小站练手，http://xiangshuguo.com，一个支持自由上传的图片小站。 因为要限制上传图片的格式，所以要做文件类型检测，代码如下:

def get_image_type(pd, is_path=True):
    '''
    获取图片的类型，支持传入路径和文件内容
    '''
    if is_path:
        f = file(pd, 'rb')
        data = f.read(10).encode('hex')
    else:
        data = pd.encode('hex')

    ftype = None

    if data.startswith('ffd8'):
        ftype = 'jpeg'
    if data ...

最近因为项目上的需要开始大量使用nginx，因此也想趁机将以前常用的django+apache的架构换成django+nginx+fastcgi，此文是整个搭建的步骤，主要留作备忘，也希望对大家有所帮助。

注意：虽然本文成功的搭建了django运行fastcgi的实例，但是在实际运行中发现了很多问题，比如程序执行异常，进程在每次请求之后退出之类的。可能是我机器的问题，也可能是程序本身bug，大家如果用来搭建外网环境，请务必多多测试。

一.编译nginx

在网上买了一本《实战nginx-取代Apache的高性能服务器》，写的比较浅，主要是些配置方面的东西，不过却正是目前我所需要的。

由于需要支持https和rewrite，所以除了nginx的源码之外，又下载了 openssl-0.9.8r.tar.gz 和 pcre-8.12.tar.gz，把他们和nginx-1.0.4.tar.gz放到同一个目录。

为了方便编译，笔者写了一个脚本，代码如下:

#!/bin/bash

#=============================================================================
#脚本所在绝对目录
abs_path(){
    local path=$1
    local basename=$( basename ...

用php有两个月了，说实话用惯了django，再用php开发真的有点郁闷，简单列一下，并非批评，仅为入门的同学少走弯路：

1. 取不到post的数据 当url为如下形式:

   xx.com/?mod=x&act=y
   

   而method又为post的时候，post的数据会取不到；必须改成如下形式:

   xx.com?mod=x&act=y
   

2. 字符串连接 这么写代码是会报错滴:

   echo 1."xx";
   

   必须这么写才行:

   echo 1 ."xx";
   

3. require之后，不知道自己引入了些什么 这个地方，如果和C或者C++来比确实也没啥问题，关键是python的from x import y 的方式实在是让人赏心悦目，所以忍不住抱怨下。

OK，抱怨完了，言归正传。 其实这些问题都还好，仔细点都能解决，最让我不爽的是php的所有框架（不排除我孤陋寡闻，欢迎大家指教）居然都没有提供一个类似于django的form类。 心灰意冷之时，突然想起来之前看到过一个仿django的php框架，虽然整个框架还有很多问题，不过form类这部分应该完成了吧。 pluf ...

好吧，我知道是大半夜……，但我还是觉得赶紧花上半个小时，把这最新的想法分享出来是值得的~直接进入正题~ 我们来模拟一个场景，需要你去抓去一个页面，然后这个页面有好多url也要分别去抓取，而进入这些子url后，还有数据要抓取。简单点，我们就按照三层来看，那我们的代码就是如下：

def func_top(url):
    data_dict= {}

    #在页面上获取到子url
    sub_urls = xxxx

    data_list = []
    for it in sub_urls:
        data_list.append(func_sub(it))

    data_dict['data'] = data_list

    return data_dict

def func_sub(url):
    data_dict= {}

    #在页面上获取到子url
    bottom_urls = xxxx

    data_list = []
    for it in bottom_urls:
        data_list.append(func_bottom(it))

    data_dict['data'] = data_list

    return data_dict ...

其实很早就想写这篇文章了，虽然晚上介绍vim的文章很多，本博也已经就vim的使用写了70多篇博文，但是由于历史的原因，还有很多人对vim能做什么存在误解，包括:

• vim对中文支持不好
• vim适合临时编辑文本，对IDE的支持不好
• vim的内嵌脚本语言不够强大，不像emacs的lisp那样无所不能

我不知道提出这些论断的人是因为不了不了解vim的现状，还是是对vim心存偏见。

本博在写vim相关文章的时候，一直坚持只谈技术的原则，不会涉及到与其他编辑器尤其是emacs的任何比较，然而最近在看了某些博文之后，觉得为了不让某些已经过时的观点给初学者选择编辑器时造成困扰，写下这篇文章十分必要。

OK，我们正式开始，在文章的末尾，相信大家都会明白上面的几个观点是否正确。

一.普通人的编辑利器

之所以第一点就提到这个，是因为"文字处理"当然是一个编辑器最基本的功能，而能把编辑的体验发挥到极致的也恐怕只有vim而已了。

这一节，也会参考善用佳软对vim的使用心得，相信用户的感受是最好的证明。

1. 免费
   用户再也不用去网上辛苦的下载D版了！
2. 提高输入速度
   这个相信也没有什么好争论的，纯键盘操作的速度是鼠标无法比拟的，虽然会带来一定的学习成本，但是相信还是值得的。
3. 完美支持中文，并支持多种文件编码
   很多编辑器会有处理多字节编码的问题，而vim完美解决了这一点。（如果你的vim没解决，请参考linux下vim的编译以及终端乱码的最终解决方案）
4. 文本笔记管理
   这要归功于vim的一款插件:voom,详情可以参考善用佳软的这篇博文--VOoM(原VOOF)：vim实现带折叠双栏树状文本管理

二 ...

python逐渐成为笔者最常用的语言之一，因此vim对python有些配置的不合理也渐渐显现出来，这次我们先来解决python的缩进问题。 我们来通过例子来说明，来看一下默认配置下python的缩进情况:

1.dict的语法缩进

val1 = {
        1:"1",
        2:"2"
        }

2.list的语法缩进

val2 = [
        1,
        2,
        3
        ]

3.tuple的语法缩进

val3 = (
        1,
        2,
        3
        )

4.函数多行参数的缩进

def fun(
        a,
        b
        ):
    print a,b

5.复杂dict中存在):的情况

val4 = {
        (
            1,
            2
            ):1
        }

很遗憾的发现，这几种常用的写法，默认python缩进都没有完美实现，那么是否有办法优化呢？ 答案是有的，vim.org上提供了一款更好的python缩进插件: http://www.vim.org/scripts/script.php?script_id ...