⑴ 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的执行脚本时间。0s0s为关闭，就是无限执行下去。（当时装的时候没仔细看就改了一个数字）问题解决了，执行很长时间也不会出错了。优化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 -l5（假如显示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分钟。
⑵ python web开发 用什么工具
python web开发常用的工具：
1. Django
Django无疑是最通用的web开发框架之一，适用博客做一个后端和为企业做一个内容管理系统。
优点：从几乎为零的状态建设出一个全功能的web应用程序。
备注：Python面向对象的设计非常干净，而且配备了令人难以置信的支持库。Python可以很容易地与其他流行的编程语言如Java，C和C ++集成。
⑶ python webpy使用其它文件的应用
urls=("/(.*)","index")直接把urls写成这样子试试
⑷ 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入口一般都是这样：?1234 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用来干这活最简单不过了?1234567891011121314151617181920212223 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代码一直访问正常
⑸ python初学者提问：怎么在本地服务器上运行.py文件
看不出，你说的疑惑在哪里？新的index.html，里面调用函数什么的不是也可以重新生成吗？php和js
⑹ 如何用python和web.py搭建一个网站
环境搭建。
环境搭建比较繁琐，记得当时也是满世界找资料，所以我直接打包好了所有的文件（apache(已经放进去python-wscgi) + web.py+apache所需要的vs2010运行库+python+网站文件），直接解压放上去就能用。有需要同学让我传一个或者网盘发一把就行。
装apache并配置python-wscgi，这个比较惨，花了好多时间去搜索才搞定，主要是windows上的python-wscgi不好难找。为了节省以后的开发时间，我把配置好的apache给打包了，反正也是绿色的，新建网站只需要在服务器上配置开机启动apache，并在apache的config里面修改下自己网站路径就行。2. 开发。
开发阶段倒是没什么好说的，web.py官方有教程，不过这里我需要提几点建议：如果可以务必全站用utf-8编码。
建立数据库建议写个生成脚本，比如createDataBase.py，有改动重新运行一遍，不要试用ide去建。
⑺ python web.py has no attribute 'application'
这是模块名冲突导致的。你自己的文件不要命名为web.py，可以改名为myapp.py，然后再试一下。
⑻ python的.py文件如何在ie上访问以及几个问题
1,可以,看web.py或者dijango2,必须有web框架支持,否则py用ie访问就变成下载或者文本方式查看了3,你写的是本地文件,不是网络开发.给你一个地址好好学学http://webpy.org/
⑼ webpy怎么访问文件呢
把原来静态页的文件放到static目录里就可以访问了，此static文件夹放在运行py文件同一个目录中，静态页中链接前加static/就可以了
⑽ python web开发用哪个框架比较好
（1）Django。Django的文档最完善、市场占有率最高、招聘职位最多估计大家都没什么意见。完美的文档，Django的成功，我觉得很大一部分原因要归功于Django近乎完美的官方文档（包括Django book）。全套的解决方案，Django象Rails一样，提供全套的解决方案（full-stack framework + batteries included），基本要什么有什么（比如：cache、session、feed、orm、geo、auth），而且全部Django自己造，开发网 站应手的工具Django基本都给你做好了，因此开发效率是不用说的，出了问题也算好找，不在你的代码里就在Django的源码里。（2）Pylons和Django的设计理念完全不同，Pylons本身只有两千行左右的Python代码，不过它还附带有一些几乎就是Pylons御用 的第三方模块。Pylons只提供一个架子和可选方案，你可以根据自己的喜好自由的选择Template、ORM、form、auth等组件，系统高度可 定制。我们常说Python是一个胶水语言(glue language)，那么我们完全可以说Pylons就是一个用胶水语言设计的胶水框架。（3）Tornado即是一个Web server（对此本文不作详述），同时又是一个类web.py的micro-framework，作为框架Tornado的思想主要来源于Web.py，大家在Web.py的网站首页也可以看到Tornado的大佬Bret Taylor的这么一段话（他这里说的FriendFeed用的框架跟Tornado可以看作是一个东西）：（4）Bottle和Flask作为新生一代Python框架的代表，挺有意思的是都采用了decorator的方式配置URL路由。（5）Flask 精简（6）web.py 非常精简
