uwsgi

## nginx 反向代理配置 - Nginx是轻量级的高性能Web服务器，提供了诸如HTTP代理和反向代理、负载均衡、缓存等一系列重要特性，在实践之中使用广泛。 - C语言编写，执行效率高 - nginx 作用 - 负载均衡， 多台服务器轮流处理请求 - 反向代理 - 原理: - 客户端请求nginx,再由nginx 请求 uwsgi, 运行django下的python代码 - ubuntu 下 nginx 安装 $ sudo apt install nginx ```shell vim /etc/apt/sources.list 更改国内源 sudo apt-get update ``` - nginx 配置 cd /etc/nginx/ - 修改nginx 的配置文件 /etc/nginx/sites-enabled/default ``` # 在server节点下添加新的location项，指向uwsgi的ip与端口。 server { ... location / { uwsgi_pass 127.0.0.1:8000; # 重定向到127.0.0.1的8000端口 include /etc/nginx/uwsgi_params; # 将所有的参数转到uwsgi下 } ... } ``` - nginx服务控制 ```shell $ sudo /etc/init.d

配置uWSGI - 添加配置文件 `项目文件夹/uwsgi.ini` - 如: mysite1/uwsgi.ini ```ini [uwsgi] # 套接字方式的 IP地址:端口号 # socket=127.0.0.1:8000 # Http通信方式的 IP地址:端口号 http=127.0.0.1:8000 # 项目当前工作目录 chdir=/home/tarena/.../my_project 这里需要换为项目文件夹的绝对路径 # 项目中wsgi.py文件的目录，相对于当前工作目录 wsgi-file=my_project/wsgi.py # 进程个数 process=4 # 每个进程的线程个数 threads=2 # 服务的pid记录文件 pidfile=uwsgi.pid # 服务的目志文件位置 daemonize=uwsgi.log # 开启主进程管理模式 master=true ``` - 修改settings.py将 DEBUG=True 改为DEBUG=False - 修改settings.py 将　ALLOWED_HOSTS = [] 改为　ALLOWED_HOSTS = ['网站域名'] 或者 ['服务监听的ip地址'] - uWSGI的运行管理 - 启动 uwsgi ```shell $ cd 项目文件夹 $ sudo uwsgi --ini 项目文件夹

布署 1.服务器介绍 ①服务器：私有服务器、公有服务器 ②私有服务器：公司自己购买、自己维护，只布署自己的应用，可供公司内部或外网访问 ③公有服务器：集成好运营环境，销售空间或主机，供其布署自己的应用 ④私有服务器成本高，需要专业人员维护，适合大公司使用 ⑤公有服务器适合初创公司使用，成本低 ⑥常用的公有服务器，如阿里云、青云等，可根据需要，按流量收费或按时间收费 ⑦此处的服务器是物理上的一台非常高、线路全、运行稳定的机器 2.服务器环境配置 ①在本地的虚拟环境中，项目根目录下，执行命令收集所有包 pip freeze > requirements.txt ②通过ftp软件将开发好的项目上传到此服务器的某个目录 ③安装并创建虚拟环境，如果已有则跳过此步 sudo apt-get install python-virtualenv sudo easy_install virtualenvwrapper mkvirtualenv [虚拟环境名称] ④在虚拟环境上工作，安装所有需要的包 workon [虚拟环境名称] pip install -r reuirements.txt ⑤更改settings.py文件 DEBUG = False ALLOW_HOSTS=['*',]表示可以访问服务器的ip ⑥启动服务器，运行正常，但是静态文件无法加载 3.WSGI ①python manage

I have a very basic flask application under uwsgi, managed by signals under supervisorctl. I use cheaper for scaling workers and ran into very disturbing situation. uwsgi is killing oldest worker, even when it is processing a request, causing 500. How to prevent uwsgi from killing workers processing the request, for the sake of cheaping? Any help/hints deeply appreciated. Found another similar post without response: UWSGI killing workers too fast Config: uwsgi version: 2.0.4 # Auto-scaling workers = 30 cheaper = 2 cheaper-step = 3 cheaper-algo = backlog cheaper-overload = 2 Logs: [pid: 15601

对Django的认识？ 1.Django是走大而全的方向，它最出名的是其全自动化的管理后台：只需要使用起ORM，做简单的对象定义，它就能自动生成数据库结构、以及全功能的管理后台。 2.Django内置的ORM跟框架内的其他模块耦合程度高。 应用程序必须使用Django内置的ORM，否则就不能享受到框架内提供的种种基于其ORM的便利； 理论上可以切换掉其ORM模块，但这就相当于要把装修完毕的房子拆除重新装修，倒不如一开始就去毛胚房做全新的装修。 3.Django的卖点是超高的开发效率，其性能扩展有限；采用Django的项目，在流量达到一定规模后，都需要对其进行重构，才能满足性能的要求。 4.Django适用的是中小型的网站，或者是作为大型网站快速实现产品雏形的工具。 5.Django模板的设计哲学是彻底的将代码、样式分离； Django从根本上杜绝在模板中进行编码、处理数据的可能。 """ 测试代码 """ Django 、Flask、Tornado的对比 1.Django走的是大而全的方向,开发效率高。它的MTV框架,自带的ORM,admin后台管理,自带的sqlite数据库和开发测试用的服务器 给开发者提高了超高的开发效率 2.Flask是轻量级的框架,自由,灵活,可扩展性很强,核心基于Werkzeug WSGI工具和jinja2模板引擎 3.Tornado走的是少而精的方向

Hi I'm trying to get an ajax response from a wsgi server behind nginx (if that matters). I think I'm having issues reading the request as it would seem the variable request_body_size is always 0; I get a return value of "No Request" in the alert box when I would like to see "test string". I cant find many docs on this or examples of this working, so if anyone knows how to fix this I would be grateful. I have this python code in the WSGI script: import os, sys from cgi import parse_qs def application(environ, start_response): try: request_body_size = int(environ.get('CONTENT_LENGTH', 0)) except

记录线上服务器通过linux性能检测工具glances检测到 cpu、内存爆满，且是uwsgi进程占用，对于服务器内核，以及uwsgi配置优化 参考文章 https://blog.csdn.net/orangleliu/article/details/48531759 uwsgi.log日志报错 Tue Jun 2 17:33:27 2015 - *** uWSGI listen queue of socket "127.0.0.1:9080" (fd: 3) full !!! (101/100) *** Tue Jun 2 17:33:28 2015 - *** uWSGI listen queue of socket "127.0.0.1:9080" (fd: 3) full !!! (101/100) *** 解决思路： 1.修改内核配置 2.修改uwsgi配置 内核修改 #对于一个经常处理新连接的高负载 web服务环境来说，默认的 128 太小了 net.core.somaxconn = 262144 ​#表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数 net.ipv4.tcp_max_syn_backlog = 8192 #网卡设备将请求放入队列的长度 net.core.netdev_max_backlog = 65536

I'm writing a Django application, which needs to perform long async tasks. Initial idea was to start a subprocess from the view that does that job, and to monitor the progress in another views. The idea works fine when application is started via manage.py runserver , but it doesn't when it is run under uwsgi. The child process is started, but after the view returns uwsgi waits for the child process end, which breaks the whole idea. I can see the request details in the uwsgi log (number of bytes generated, etc), but the socket isn't closed, so the browser waits too. I have seen other