‘壹’ PHP和Python哪个更有前途
看个人的兴趣，如果喜欢做网站的话，就学php，现在好多网站都是用php编写的，并且php是后来兴起的语言，外面的Php程序员还挺缺的！！
如果喜欢做系统脚本编程的，就学python，现在好多系统都支持python编写的脚本，python学起来也挺容易的，发展前途来蛮不错的！
不过现在php容易找工作一点，发展势头比phthon高，，不过以后就不好说了！
这两门学精了，都好有前途！
‘贰’ 如果V2EX在今天才开始开发，会用什么Python Web框架
从GitHub中整理出的15个最受欢迎的Python开源框架。这些框架包括事件I/O，OLAP，Web开发，高性能网络通信，测试，爬虫等。
Django: Python Web应用开发框架
Django 应该是最出名的Python框架，GAE甚至Erlang都有框架受它影响。Django是走大而全的方向，它最出名的是其全自动化的管理后台：只需要使用起ORM，做简单的对象定义，它就能自动生成数据库结构、以及全功能的管理后台。
Diesel：基于Greenlet的事件I/O框架
Diesel提供一个整洁的API来编写网络客户端和服务器。支持TCP和UDP。
Flask：一个用Python编写的轻量级Web应用框架
Flask是一个使用Python编写的轻量级Web应用框架。基于Werkzeug WSGI工具箱和Jinja2
模板引擎。Flask也被称为“microframework”，因为它使用简单的核心，用extension增加其他功能。Flask没有默认使用的数
据库、窗体验证工具。
Cubes：轻量级Python OLAP框架
Cubes是一个轻量级Python框架，包含OLAP、多维数据分析和浏览聚合数据（aggregated data）等工具。
Kartograph.py：创造矢量地图的轻量级Python框架
Kartograph是一个Python库，用来为ESRI生成SVG地图。Kartograph.py目前仍处于beta阶段，可以在virtualenv环境下来测试。
Pulsar：Python的事件驱动并发框架
Pulsar是一个事件驱动的并发框架，有了pulsar，可以写出在不同进程或线程中运行一个或多个活动的异步服务器。
Web2py：全栈式Web框架
Web2py是一个为Python语言提供的全功能Web应用框架，旨在敏捷快速的开发Web应用，具有快速、安全以及可移植的数据库驱动的应用，兼容Google App Engine。
Falcon：构建云API和网络应用后端的高性能Python框架
Falcon是一个构建云API的高性能Python框架，它鼓励使用REST架构风格，尽可能以最少的力气做最多的事情。
Dpark：Python版的Spark
DPark是Spark的Python克隆，是一个Python实现的分布式计算框架，可以非常方便地实现大规模数据处理和迭代计算。DPark由豆瓣实现，目前豆瓣内部的绝大多数数据分析都使用DPark完成，正日趋完善。
Buildbot：基于Python的持续集成测试框架
Buildbot是一个开源框架，可以自动化软件构建、测试和发布等过程。每当代码有改变，服务器要求不同平台上的客户端立即进行代码构建和测试，收集并报告不同平台的构建和测试结果。
Zerorpc：基于ZeroMQ的高性能分布式RPC框架
Zerorpc是一个基于ZeroMQ和MessagePack开发的远程过程调用协议（RPC）实现。和 Zerorpc 一起使用的 Service API 被称为 zeroservice。Zerorpc 可以通过编程或命令行方式调用。
Bottle: 微型Python Web框架
Bottle是一个简单高效的遵循WSGI的微型python Web框架。说微型，是因为它只有一个文件，除Python标准库外，它不依赖于任何第三方模块。
Tornado：异步非阻塞IO的Python Web框架
Tornado的全称是Torado Web Server，从名字上看就可知道它可以用作Web服务器，但同时它也是一个Python Web的开发框架。最初是在FriendFeed公司的网站上使用，FaceBook收购了之后便开源了出来。
webpy: 轻量级的Python Web框架
webpy的设计理念力求精简（Keep it simple and powerful），源码很简短，只提供一个框架所必须的东西，不依赖大量的第三方模块，它没有URL路由、没有模板也没有数据库的访问。
Scrapy：Python的爬虫框架
Scrapy是一个使用Python编写的，轻量级的，简单轻巧，并且使用起来非常的方便。
‘叁’ Python几种主流框架比较
从GitHub中整理出的15个最受欢迎的Python开源框架。这些框架包括事件I/O，OLAP，Web开发，高性能网络通信，测试，爬虫等。
Django: Python Web应用开发框架
Django 应该是最出名的Python框架，GAE甚至Erlang都有框架受它影响。Django是走大而全的方向，它最出名的是其全自动化的管理后台：只需要使用起ORM，做简单的对象定义，它就能自动生成数据库结构、以及全功能的管理后台。
Diesel：基于Greenlet的事件I/O框架
Diesel提供一个整洁的API来编写网络客户端和服务器。支持TCP和UDP。
Flask：一个用Python编写的轻量级Web应用框架
Flask是一个使用Python编写的轻量级Web应用框架。基于Werkzeug WSGI工具箱和Jinja2
模板引擎。Flask也被称为“microframework”，因为它使用简单的核心，用extension增加其他功能。Flask没有默认使用的数
据库、窗体验证工具。
Cubes：轻量级Python OLAP框架
Cubes是一个轻量级Python框架，包含OLAP、多维数据分析和浏览聚合数据（aggregated data）等工具。
Kartograph.py：创造矢量地图的轻量级Python框架
Kartograph是一个Python库，用来为ESRI生成SVG地图。Kartograph.py目前仍处于beta阶段，你可以在virtualenv环境下来测试。
Pulsar：Python的事件驱动并发框架
Pulsar是一个事件驱动的并发框架，有了pulsar，你可以写出在不同进程或线程中运行一个或多个活动的异步服务器。
Web2py：全栈式Web框架
Web2py是一个为Python语言提供的全功能Web应用框架，旨在敏捷快速的开发Web应用，具有快速、安全以及可移植的数据库驱动的应用，兼容Google App Engine。
Falcon：构建云API和网络应用后端的高性能Python框架
Falcon是一个构建云API的高性能Python框架，它鼓励使用REST架构风格，尽可能以最少的力气做最多的事情。
Dpark：Python版的Spark
DPark是Spark的Python克隆，是一个Python实现的分布式计算框架，可以非常方便地实现大规模数据处理和迭代计算。DPark由豆瓣实现，目前豆瓣内部的绝大多数数据分析都使用DPark完成，正日趋完善。
Buildbot：基于Python的持续集成测试框架
Buildbot是一个开源框架，可以自动化软件构建、测试和发布等过程。每当代码有改变，服务器要求不同平台上的客户端立即进行代码构建和测试，收集并报告不同平台的构建和测试结果。
Zerorpc：基于ZeroMQ的高性能分布式RPC框架
Zerorpc是一个基于ZeroMQ和MessagePack开发的远程过程调用协议（RPC）实现。和 Zerorpc 一起使用的 Service API 被称为 zeroservice。Zerorpc 可以通过编程或命令行方式调用。
Bottle: 微型Python Web框架
Bottle是一个简单高效的遵循WSGI的微型python Web框架。说微型，是因为它只有一个文件，除Python标准库外，它不依赖于任何第三方模块。
Tornado：异步非阻塞IO的Python Web框架
Tornado的全称是Torado Web Server，从名字上看就可知道它可以用作Web服务器，但同时它也是一个Python Web的开发框架。最初是在FriendFeed公司的网站上使用，FaceBook收购了之后便开源了出来。
webpy: 轻量级的Python Web框架
webpy的设计理念力求精简（Keep it simple and powerful），源码很简短，只提供一个框架所必须的东西，不依赖大量的第三方模块，它没有URL路由、没有模板也没有数据库的访问。
Scrapy：Python的爬虫框架
Scrapy是一个使用Python编写的，轻量级的，简单轻巧，并且使用起来非常的方便。
‘肆’ Python 有哪些好的 Web 框架
python的web框架很多
django (大而全，模板，orm都自带)
flask (pocoo出品，比属精品，自带jinja2模板，可以替换)
web.py (这个我没用过，作者自杀，白瞎了一个高手)
bottle (只有一个文件的框架，需要自己构建整个开发体系)
uliweb (中国人开发的，也很不错)
Tornado (异步框架，适合长连接，比如在线聊天之类的)
Python框架虽然说是百花齐放，但仍然有那么一家是最大的，它就是Django。Django为人所称道的地方主要有：
①完美的文档，Django的成功，我觉得很大一部分原因要归功于Django近乎完美的官方文档（包括Django book）。
②
全套的解决方案，Django象Rails一样，提供全套的解决方案（full-stack framework + batteries
included），基本要什么有什么（比如：cache、session、feed、orm、geo、auth），而且全部Django自己造，开发网
站应手的工具Django基本都给你做好了，因此开发效率是不用说的，出了问题也算好找，不在你的代码里就在Django的源码里。
③强大的URL路由配置，Django让你可以设计出非常优雅的URL，在Django里你基本可以跟丑陋的GET参数说拜拜。
④自助管理后台，admin interface是Django里比较吸引眼球的一项contrib，让你几乎不用写一行代码就拥有一个完整的后台管理界面。
‘伍’ web前端开发主要是做什么的
前端开发是创建WEB页面或APP等前端界面呈现给用户的过程，通过HTML，CSS及JavaScript以及衍生出来的各种技术、框架、解决方案，来实现互联网产品的用户界面交互。
前端开发跟随移动互联网发展带来了大量高性能的移动终端设备应用。HTML5，Node.js的广泛应用，各类UI框架，JS类库层出不穷，开发难度也在逐步提升。
前端框架
学好Web框架，熟悉掌握HTML、服务器端脚本语言、CSS和JavaScript之后，学习Web框架可以加快Web开发速度，节约时间。PHP程序员可选的框架包括CakePHP、CodeIgniter、Zend等，Python程序员喜欢使用Django和webpy，Ruby程序员常用RoR。
‘陆’ 为什么 Nginx 已经这么成熟，Python 还有各种如 web.py 等 web 框架
nginx是服务器，web.py是web应用框架。
简言之，前者封装对网络io的处理，后者负责具体应用的逻辑，解决的问题是不一样的。形象点呢，一个请求来了，nginx先把请求拦下来，发现要的是现成的东西(静态文件)，它就直接把现成的静态文件返回给客户端，这样速度非常快，如果是其他的请求，再交给web.py解决，web.py解决完了之后，只是生成要返回的内容，并不自己做网络io，而是由nginx处理的。
这样多好，一个安心处理网络、并发，顺便把遇到简单的请求直接ko掉。另一个专心处理应用的逻辑。
当然nginx能做的不只是这些，而为了开发方便web.py等框架都是内置简单的web服务器的。
至于tornado，它里面既有web应用框架，也有web服务器，而且这个服务器用的还是高性能单线程非阻塞异步的模型，是个例外。
‘柒’ nginx 502 webpy bad gateway问题怎么解决
Nginx 502的触发条件
502错误最通常的出现情况就是后端主机当机。在upstream配置里有这么一项配置：proxy_next_upstream，这个配置指定了 nginx在从一个后端主机取数据遇到何种错误时会转到下一个后端主机，里头写上的就是会出现502的所有情况拉，默认是error timeout。error就是当机、断线之类的，timeout就是读取堵塞超时，比较容易理解。我一般是全写上的：
proxy_next_upstream error timeout invalid_header http_500 http_503;不过现在可能我要去掉http_500这一项了，http_500指定后端返回500错误时会转一个主机，后端的jsp出错的话，本来会打印一堆 stacktrace的错误信息，现在被502取代了。但公司的程序员可不这么认为，他们认定是nginx出现了错误，我实在没空跟他们解释502的原理 了……
503错误就可以保留，因为后端通常是apache resin，如果apache死机就是error，但resin死机，仅仅是503，所以还是有必要保留的。
解决办法
遇到502问题，可以优先考虑按照以下两个步骤去解决。
1、查看当前的PHP FastCGI进程数是否够用：
复制代码 代码如下:
netstat -anpo | grep "php-cgi" | wc -l
如果实际使用的“FastCGI进程数”接近预设的“FastCGI进程数”，那么，说明“FastCGI进程数”不够用，需要增大。
2、部分PHP程序的执行时间超过了Nginx的等待时间，可以适当增加nginx.conf配置文件中FastCGI的timeout时间，例如：
复制代码 代码如下:
http { fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300; ...... } ......
php.ini中memory_limit设低了会出错，修改了php.ini的memory_limit为64M，重启nginx，发现好了，原来是PHP的内存不足了。
如果这样修改了还解决不了问题，可以参考下面这些方案：
一、max-children和max-requests
一台服务器上运行着nginx php(fpm) xcache，访问量日均 300W pv左右。
最近经常会出现这样的情况：php页面打开很慢，cpu使用率突然降至很低，系统负载突然升至很高，查看网卡的流量，也会发现突然降到了很低。这种情况只持续数秒钟就恢复了。
检查php-fpm的日志文件发现了一些线索。
复制代码 代码如下:
Sep 30 08:32:23.289973 [NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200, cur:51200 Sep 30 08:32:23.290212 [NOTICE] fpm_sockets_init_main(), line 371: using inherited socket fd=10, “127.0.0.1:9000″ Sep 30 08:32:23.290342 [NOTICE] fpm_event_init_main(), line 109: libevent: using epoll Sep 30 08:32:23.296426 [NOTICE] fpm_init(), line 47: fpm is running, pid 30587
在这几句的前面，是1000多行的关闭children和开启children的日志。
原来，php-fpm有一个参数 max_requests，该参数指明了，每个children最多处理多少个请求后便会被关闭，默认的设置是500。因为php是把请求轮询给每个 children，在大流量下，每个childre到达max_requests所用的时间都差不多，这样就造成所有的children基本上在同一时间 被关闭。
在这期间，nginx无法将php文件转交给php-fpm处理，所以cpu会降至很低(不用处理php，更不用执行sql)，而负载会升至很高(关闭和开启children、nginx等待php-fpm)，网卡流量也降至很低(nginx无法生成数据传输给客户端)
解决问题很简单，增加children的数量，并且将 max_requests 设置未 0 或者一个比较大的值：
打开 /usr/local/php/etc/php-fpm.conf调大以下两个参数(根据服务器实际情况，过大也不行）
复制代码 代码如下:
<value>5120</value><value>600</value>
然后重启php-fpm。
二、增加缓冲区容量大小
将nginx的error log打开，发现“pstream sent too big header while reading response header from upstream”这样的错误提示。查阅了一下资料，大意是nginx缓冲区有一个bug造成的,我们网站的页面消耗占用缓冲区可能过大。参考老外写的修 改办法增加了缓冲区容量大小设置，502问题彻底解决。后来系统管理员又对参数做了调整只保留了2个设置参数：client head buffer，fastcgi buffer size。
三、request_terminate_timeout
如果主要是在一些post或者数据库操作的时候出现502这种情况，而不是在静态页面操作中常见，那么可以查看一下php-fpm.conf设置中的一项：
request_terminate_timeout
这个值是max_execution_time，就是fast-cgi的执行脚本时间。
0s
0s为关闭，就是无限执行下去。（当时装的时候没仔细看就改了一个数字）问题解决了，执行很长时间也不会出错了。优化fastcgi中，还可以改改这个值5s 看看效果。
php-cgi进程数不够用、php执行时间长、或者是php-cgi进程死掉，都会出现502错误。Nginx 502 Bad Gateway错误的解决办法2
今天，我的VPS频繁提示Nginx 502 Bad Gateway错误了，重启了VPS解决之后又出现，很烦。有点想不通，前两天网站达到了1290的访问量都没有出什么问题，怎么这次就出现了502 Bad Gateway？郁闷啊！！！在搜索了很久，终于找到了不少相关的答案，希望修改之后不会再出现这个错误了。唉，既然在网上找了那么久的答案，那当然得把有用的东西记录下，免得我下次再去谷歌~
由于我是采用了LNMP一键安装包 ，出了问题肯定要先到官方论坛去搜索下了，真好，官方有个这样的置顶帖，大家先瞧瞧。
LNMP一键安装包官方的：
第一种原因：目前lnmp一键安装包比较多的问题就是502 Bad Gateway，大部分情况下原因是在安装php前，脚本中某些lib包可能没有安装上，造成php没有编译安装成功。解决办法：可以尝试根据lnmp一键安装包中的脚本手动安装一下，看看是什么错误导致的。
第二种原因：
在php.ini里，eaccelerator配置项一定要放在Zend Optimizer配置之前，否则也可能引起502 Bad Gateway
第三种原因：
在安装好使用过程中出现502问题，一般是因为默认php-cgi进程是5个，可能因为phpcgi进程不够用而造成502，需要修改/usr/local/php/etc/php-fpm.conf 将其中的max_children值适当增加。
第四种原因：
php执行超时，修改/usr/local/php/etc/php.ini 将max_execution_time 改为300
第五种原因：
磁盘空间不足，如mysql日志占用大量空间
第六种原因：
查看php-cgi进程是否在运行
也有网友给出了另外的解决办法：
Nginx 502 Bad Gateway的含义是请求的PHP-CGI已经执行，但是由于某种原因（一般是读取资源的问题）没有执行完毕而导致PHP-CGI进程终止，一般来说Nginx 502 Bad Gateway和php-fpm.conf的设置有关。
php-fpm.conf有两个至关重要的参数，一个是max_children，另一个是request_terminate_timeout，但是这个值不是通用的，而是需要自己计算的。在安装好使用过程中出现502问题，一般是因为默认php-cgi进程是5个，可能因为phpcgi进程不够用而造成502，需要修改/usr/local/php/etc/php-fpm.conf 将其中的max_children值适当增加。
计算的方式如下：
如果你的服务器性能足够好，且宽带资源足够充足，PHP脚本没有系循环或BUG的话你可以直接将 request_terminate_timeout设置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。而如果你做不到这一点，也就 是说你的PHP-CGI可能出现某个BUG，或者你的宽带不够充足或者其他的原因导致你的PHP-CGI假死那么就建议你给 request_terminate_timeout赋一个值，这个值可以根据服务器的性能进行设定。一般来说性能越好你可以设置越高，20分钟-30分 钟都可以。而max_children这个值又是怎么计算出来的呢？这个值原则上是越大越好，php-cgi的进程多了就会处理的很快，排队的请求就会很少。 设置max_children也需要根据服务器的性能进行设定，一般来说一台服务器正常情况下每一个php-cgi所耗费的内存在20M左右。
按照官方的答案，排查了相关的可能，并结合了网友的答案，得出了下面的解决办法。
1、查看php fastcgi的进程数（max_children值）
代码：netstat -anpo | grep “php-cgi” | wc -l
5（假如显示5）
2、查看当前进程
代码：top观察fastcgi进程数,假如使用的进程数等于或高于5个，说明需要增加（根据你机器实际状况而定）
3、调整/usr/local/php/etc/php-fpm.conf 的相关设置
<value name=”max_children”>10</value><value name=”request_terminate_timeout”>60s</value>max_children最多10个进程，按照每个进程20MB内存，最多200MB。request_terminate_timeout执行的时间为60秒，也就是1分钟。
‘捌’ webpy + nginx with fastcgi方案怎么样
起初我很是奇怪，按理说只有当静态文件不存在时nginx才会返回404错误，而现在访问的是配置在nginx.conf中的一个动态路径，该动态路径请求通过fastcgi最终会映射到某个python class的GET或POST方法中，那为什么nginx会返回404呢？
查阅相关文档之后发现
fastcgi在遇到webpy或其他后端http模块处理极慢的情况下，也就是说超过nginx允许的应答时间，nginx就会对此动态路径请求做出404的应答
针对此情况，我开始着手准备一系列测试和实验
实验
实验一：剥离fastcgi，单独使用webpy，进行压力测试
这个实验很简单，只需要注释掉一行代码，便可以以纯webpy方式访问，基于webpy的python应用main入口一般都是这样：
?
1
2
3
4
if __name__ == "__main__":
web.wsgi.runwsgi = lambda func, addr=None: web.wsgi.runfcgi(func,addr)
app.add_processor(web.loadhook(session_hook))
app.run()
只需要注释掉第二行即可，之后在终端下运行python <filename>.py，webpy会默认监听本地的8080端口，之后无论是通过浏览器还是其他方式访问相应地址即可
同时，还需要准备一份发起http请求的代码，python用来干这活最简单不过了
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
import httplib
server = "192.168.2.2:8080"
url = "/user/[email protected]&password=111&rnd=33"
class perftest:
def __init__(self):
pass
def run(self):
conn = httplib.HTTPConnection(server)
for i in range(100):
try:
conn.request("GET", url)
rsp = conn.getresponse()
if 200 == rsp.status:
print "headers", rsp.getheaders()
content = rsp.read()
print "content", content
except Exception, ex:
print "ERR:", ex
conn.close()
跑了几次压力之后，webpy扛不住了…开始大面积抛异常，大致意思是python自带的logging模块出错，因为有频繁的文件打开关闭操作，某个操作导致文件句柄被非法访问…
在查看相关的log封装类之后发现，python的日志模块设计实在是有点不够内聚，也可以说不够彻底吧，不由得想起了之前用过的log4net，真是简洁啊
出错的原因在项目中开发同事封装的log模块多次执行了addHandler和removeHandler操作，据说在之前的开发过程中还出现过一行日志打印多遍的情况，而且随着程序的运行，相同的日志会越来越多…
顺手将该封装修改为单例类之后，故障解除
处理完之后接着跑压力，webpy还是会偶尔打印异常信息，不过已经变成了session访问异常，还好的是出现面积很小，于是开始增加压力测试的并发量，结果表明稳定度还是可以的，性能也在可以接受的范围之内
实验二：保持最终部署环境不变(nginx+fastcgi+webpy)，继续压力测试
在上次测试解决完日志的问题之后，我开始以真实环境做相关的测试，要注意的是使用nginx之后，需要访问nginx.conf中配置绑定的相关端口，不再是webpy默认的8080端口
继续做上述的压力测试，性能也在可以接受的范围之内
实验三：模拟用户环境
根据测试MM所描述的，浏览器在B子系统出错过程中扮演了很关键的角色，于是我分别使用几个浏览器和纯粹的python代码分别访问相同的地址
几种组合的测试发现：
浏览器在只访问B子系统的情况下，一直表现正常
一旦浏览器访问过A子系统之后，再次访问B子系统即出现测试MM描述的404现象
python代码一直访问正常