标签归档:python

RSS feed of python

最后更新于 .

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

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.

得到的结果如下:

E588C2D7 1608 42CC B800 AD5338C87F47

可以清楚的看到,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.startswith('424d ...

最后更新于 .

最近因为项目上的需要开始大量使用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:http://www.pluf.org/ 果然不出所料! 看过我之前博文的朋友应该都知道我把CodeIgniter的db访问类单独拆了出来(参见:抽离CodeIgniter的数据库访问类!),没错,这次我又做了同样的事情。 拆分的方法这里就不详细描述了,其实就是SafeString.php这个文件从别的目录拷贝过来,并且定义了一个pluf_form_inc ...

最后更新于 .

好吧,我知道是大半夜……,但我还是觉得赶紧花上半个小时,把这最新的想法分享出来是值得的~直接进入正题~

我们来模拟一个场景,需要你去抓去一个页面,然后这个页面有好多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,详情可以参考善用佳软的这篇博文-- ...

最后更新于 .

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 ...