导读：本篇文章首席CTO笔记来给大家介绍有关怎么测django并发量的相关内容，希望对大家有所帮助，一起来看看吧。
如何有效的遍历django的QuerySet
最近做了一个小的需求，在django模型中通过前台页面的表单的提交
（post），后台对post的参数进行解析，通过models模型查询MySQL，将数据结构进行加工，返回到前台页面进行展示。由于对django中
QuerySet特性的不熟悉，所以测试过程中发现了很多问题。
开始的阶段没有遇到什么问题，我们举例，在models有一张员工表
employee，对应的表结构中，postion列表示员工职位，前台post过来的参数赋给position，加上入职时间、离职时间，查询操作通过
models.filter(position=params)完成，获取的员工信息内容由QuerySet和当前展示页与每页展示的记录数进行简单的计
算，返回给前台页面进行渲染展示。编码如下：
1 def get_employees(position, start, end):
2 return employee.objects.filter(alert_time__lt=end,alert_time__gt=start).filter(position__in=position)
3
4
5 @login_required
6 def show(request):
7 if not validate(request):
8 return render_to_response('none.html',
9 context_instance=RequestContext(request, 'msg':'params error')
10 )
11
12 position = request.REQUEST.get('position')
13 time_range = request.REQUEST.get('time')
14 start, end = time_range[0], time_range[1]
15
16 num_per_page, page_num = get_num(request)
17 all_employees = get_employees(position, start, end)
18 # 根据当前页与每页展示的记录数，取到正确的记录
19 employees = employees_events[(page_num-1)*num_per_page:page_num*num_per_page]
20
21 return render_to_response('show_employees.html',
22 context_instance=RequestContext(
23 request,
24 'employees': employees,
25 'num_per_page': num_per_page,
26 'page_num':page_num,
27 'page_options' : [50, 100, 200]
28 )
29 )
运行之后可以正确的对所查询的员工信息进行展示，并且查询速度很快。
employee表中存放着不同职位的员工信息，不同类型的详细内容也不相同，假设employees有一列名为infomation，存储的是员工的详
细信息，infomation = {'age': 33, 'gender': 'male', 'nationality': 'German',
'degree': 'doctor', 'motto': 'just do
it'}，现在的需求是要展示出分类更细的员工信息，前台页面除了post职位、入职离职时间外，还会对infomation中的内容进行筛选，这里以查
询中国籍的设计师为例，在之前的代码基础上，需要做一些修改。员工信息表employee存放于MySQL中，而MySQL为ORM数据库，它并未提供类
似mongodb一样更为强大的聚合函数，所以这里不能通过objects提供的方法进行filter，一次性将所需的数据获取出来，那么需要对type
进行过滤后的数据，进行二次遍历，通过information来确定当前记录是否需要返回展示，在展示过程中，需要根据num_per_page和
page_num计算出需要展示数据起始以及终止位置。
1 def get_employees(position, start, end):
2 return employee.objects.filter(alert_time__lt=end,alert_time__gt=start).filter(position__in=position)
3
4
5 def filter_with_nation(all_employees, nationality, num_per_page, page_num):
6 result = []
7
8 pos = (page_num-1)*num_per_page
9 cnt = 0
10 start = False
11 for employee in all_employees:
12 info = json.loads(employee.information)
13 if info.nationality != nationality:
14 continue
15
16 # 获取的数据可能并不是首页，所以需要先跳过前n-1页
17 if cnt == pos:
18 if start:
19 break
20 cnt = 0
21 pos = num_per_page
22 start = True
23
24 if start:
25 result.append(employee)
26
27 return employee
28
29
30 @login_required
31 def show(request):
32 if not validate(request):
33 return render_to_response('none.html',
34 context_instance=RequestContext(request, 'msg':'params error')
35 )
36
37 position = request.REQUEST.get('position')
38 time_range = request.REQUEST.get('time')
39 start, end = time_range[0], time_range[1]
40
41 num_per_page, page_num = get_num(request)
42 all_employees = get_employees(position, start, end)
43
44 nationality = request.REQUEST.get('nationality')
45
46 employees = filter_with_nation(all_employees, num_per_page, page_num)
47
48 return render_to_response('show_employees.html',
49 context_instance=RequestContext(
50 request,
51 'employees': employees,
52 'num_per_page': num_per_page,
53 'page_num':page_num,
54 'page_options' : [50, 100, 200]
55 )
56 )
当编码完成之后，在数据employee表数据很小的情况下测试并未发现问
题，而当数据量非常大，并且查询的数据很少时，代码运行非常耗时。我们设想，这是一家规模很大的跨国公司，同时人员的流动量也很大，所以employee
表的数据量很庞大，而这里一些来自于小国家的员工并不多，比如需要查询国籍为梵蒂冈的员工时，前台页面进入了无尽的等待状态。同时，监控进程的内存信息，
发现进程的内存一直在增长。毫无疑问，问题出现在filter_with_nation这个函数中，这里逐条遍历了employee中的数据，并且对每条
数据进行了解析，这并不是高效的做法。
在网上查阅了相关资料，了解到：
1 Django的queryset是惰性的，使用filter语句进行查询，实际上并没有运行任何的要真正从数据库获得数据
2 只要你查询的时候才真正的操作数据库。会导致执行查询的操作有：对QuerySet进行遍历queryset，切片，序列化，对 QuerySet 应用 list()、len()方法，还有if语句
3 当第一次进入循环并且对QuerySet进行遍历时，Django从数据库中获取数据，在它返回任何可遍历的数据之前，会在内存中为每一条数据创建实例，而这有可能会导致内存溢出。
上面的原来很好的解释了代码所造成的现象。那么如何进行优化是个问题，网上有
说到当QuerySet非常巨大时，为避免将它们一次装入内存，可以使用迭代器iterator()来处理，但对上面的代码进行修改，遍历时使用
employee.iterator()，而结果和之前一样，内存持续增长，前台页面等待，对此的解释是：using iterator()
will save you some memory by not storing the result of the cache
internally (though not necessarily on PostgreSQL!); but will still
retrieve the whole objects from the database。
这里我们知道不能一次性对QuerySet中所有的记录进行遍历，那么只能对
QuerySet进行切片，每次取一个chunk_size的大小，遍历这部分数据，然后进行累加，当达到需要的数目时，返回满足的对象列表，这里修改下
filter_with_nation函数：
1 def filter_with_nation(all_employees, nationality, num_per_page, page_num):
2 result = []
3
4 pos = (page_num-1)*num_per_page
5 cnt = 0
6 start_pos = 0
7 start = False
8 while True:
9 employees = all_employees[start_pos:start_pos+num_per_page]
10 start_pos += num_per_page
11
12 for employee in employees:
13 info = json.loads(employee.infomation)
14 if info.nationality != nationality:
15 continue
16
17 if cnt == pos:
18 if start:
19 break
20 cnt = 0
21 pos = num_per_page
22 start = True
23
24 if start:
25 result.append(opt)
26
27 cnt += 1
28
29 if cnt == num_per_page or not events:
30 break
31
32 return result
运行上述代码时，查询的速度更快，内存也没有明显的增长，得到效果不错的优
化。这篇文章初衷在于记录自己对django中queryset的理解和使用，而对于文中的例子，其实正常业务中，如果需要记录员工详细的信息，最好对
employee表进行扩充，或者建立一个字表，存放详细信息，而不是将所有信息存放入一个字段中，避免在查询时的二次解析。
python 中 django 的问题-------- 请高人指点 尽量详细点哦 初学django
django的模块一般都不能单独执行，如果是用的命令行，要使用python manage.py shell，而不要直接使用python
如何用nginx关联django应用
通过Nginx部署Django（基于ubuntu)
Django的部署可以有很多方式，采用nginx+uwsgi的方式是其中比较常见的一种方式。
在这种方式中，我们的通常做法是，将nginx作为服务器最前端，它将接收WEB的所有请求，统一管理请求。nginx把所有静态请求自己来处理（这是NGINX的强项）。然后，NGINX将所有非静态请求通过uwsgi传递给Django，由Django来进行处理，从而完成一次WEB请求。
可见，uwsgi的作用就类似一个桥接器。起到桥梁的作用。
Linux的强项是用来做服务器，所以，下面的整个部署过程我们选择在Ubuntu下完成。
一、安装Nginx
Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，并在一个BSD-like 协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好。
Nginx同样为当前非常流行的web服务器。利用其部署Django，我们在此也做简单的介绍。
Nginx官网：
打开ubuntu控制台（ctrl+alt+t）利用Ubuntu的仓库安装。
fnngj@ubuntu:~$ sudo apt-get install nginx #安装
启动Nginx：
fnngj@ubuntu:~$ /etc/init.d/nginx start #启动
fnngj@ubuntu:~$ /etc/init.d/nginx stop #关闭
fnngj@ubuntu:~$ /etc/init.d/nginx restart #重启
修改Nginx默认端口号，打开/etc/nginx/nginx.conf 文件，修改端口号。
复制代码
server {
listen 8088; # 修改端口号
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
root html;
index index.html index.htm;
}
复制代码
大概在文件36行的位置，将默认的80端口号改成其它端口号，如 8088。因为默认的80端口号很容易被其它应用程序占用。
然后，通过上面命令重启nginx。访问：http//127.0.0.1:8088/
如果出现如上图，说明Nginx启动成功。
二、安装uwsgi
通过pip安装uwsgi。
root@ubuntu:/etc# python3 -m pip install uwsgi
测试uwsgi，创建test.py文件：
def application(env, start_response):
start_response('200 OK', [('Content-Type','text/html')])
return [b"Hello World"]
通过uwsgi运行该文件。
fnngj@ubuntu:~/pydj$ uwsgi --http :8001 --wsgi-file test.py
接下来配置Django与uwsgi连接。此处，假定的我的django项目位置为：/home/fnngj/pydj/myweb
fnngj@ubuntu:~/pydj$ uwsgi --http :8001 --chdir /home/fnngj/pydj/myweb/ --wsgi-file myweb/wsgi.py --master --processes 4 --threads 2 --stats 127.0.0.1:9191
常用选项：
http ： 协议类型和端口号
processes ： 开启的进程数量
workers ： 开启的进程数量，等同于processes（官网的说法是spawn the specified number ofworkers / processes）
chdir ： 指定运行目录（chdir to specified directory before apps loading）
wsgi-file ： 载入wsgi-file（load .wsgi file）
stats ： 在指定的地址上，开启状态服务（enable the stats server on the specified address）
threads ： 运行线程。由于GIL的存在，我觉得这个真心没啥用。（run each worker in prethreaded mode with the specified number of threads）
master ： 允许主进程存在（enable master process）
daemonize ： 使进程在后台运行，并将日志打到指定的日志文件或者udp服务器（daemonize uWSGI）。实际上最常用的，还是把运行记录输出到一个本地文件上。
pidfile ： 指定pid文件的位置，记录主进程的pid号。
vacuum ： 当服务器退出的时候自动清理环境，删除unix socket文件和pid文件（try to remove all of the generated file/sockets）
三、Nginx+uwsgi+Django
接下来，我们要将三者结合起来。首先罗列一下项目的所需要的文件：
myweb/
├── manage.py
├── myweb/
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
└── myweb_uwsgi.ini
在我们通过Django创建myweb项目时，在子目录myweb下已经帮我们生成的 wsgi.py文件。所以，我们只需要再创建myweb_uwsgi.ini配置文件即可，当然，uwsgi支持多种类型的配置文件，如xml，ini等。此处，使用ini类型的配置。
复制代码
# myweb_uwsgi.ini file
[uwsgi]
# Django-related settings
socket = :8000
# the base directory (full path)
chdir = /home/fnngj/pydj/myweb
# Django s wsgi file
module = myweb.wsgi
# process-related settings
# master
master = true
# maximum number of worker processes
processes = 4
# ... with appropriate permissions - may be needed
# chmod-socket = 664
# clear environment on exit
vacuum = true
复制代码
这个配置，其实就相当于在上一小节中通过wsgi命令，后面跟一堆参数的方式，给文件化了。
socket 指定项目执行的端口号。
chdir 指定项目的目录。
module myweb.wsgi ，可以这么来理解，对于myweb_uwsgi.ini文件来说，与它的平级的有一个myweb目录，这个目录下有一个wsgi.py文件。
其它几个参数，可以参考上一小节中参数的介绍。
接下来，切换到myweb项目目录下，通过uwsgi命令读取myweb_uwsgi.ini文件启动项目。
复制代码
fnngj@ubuntu:~$ cd /home/fnngj/pydj/myweb/
fnngj@ubuntu:~/pydj/myweb$ uwsgi --ini myweb_uwsgi.ini
[uWSGI] getting INI configuration from myweb_uwsgi.ini
*** Starting uWSGI 2.0.12 (32bit) on [Sat Mar 12 13:05:06 2016] ***
compiled with version: 4.8.4 on 26 January 2016 06:14:41
os: Linux-3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:18:00 UTC 2015
nodename: ubuntu
machine: i686
clock source: unix
detected number of CPU cores: 2
current working directory: /home/fnngj/pydj/myweb
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
chdir() to /home/fnngj/pydj/myweb
your processes number limit is 15962
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to TCP address :8000 fd 3
Python version: 3.4.3 (default, Oct 14 2015, 20:37:06) [GCC 4.8.4]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x8b52dc0
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 319920 bytes (312 KB) for 4 cores
*** Operational MODE: preforking ***
WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0x8b52dc0 pid: 7158 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 7158)
spawned uWSGI worker 1 (pid: 7160, cores: 1)
spawned uWSGI worker 2 (pid: 7161, cores: 1)
spawned uWSGI worker 3 (pid: 7162, cores: 1)
spawned uWSGI worker 4 (pid: 7163, cores: 1)
复制代码
注意查看uwsgi的启动信息，如果有错，就要检查配置文件的参数是否设置有误。
再接下来要做的就是修改nginx.conf配置文件。打开/etc/nginx/nginx.conf文件，添加如下内容。
复制代码
……
server {
listen 8099;
server_name 127.0.0.1
charset UTF-8;
access_log /var/log/nginx/myweb_access.log;
error_log /var/log/nginx/myweb_error.log;
client_max_body_size 75M;
location / {
include uwsgi_params;
uwsgi_pass 127.0.0.1:8000;
uwsgi_read_timeout 2;
}
location /static {
expires 30d;
autoindex on;
add_header Cache-Control private;
alias /home/fnngj/pydj/myweb/static/;
}
}
……
复制代码
listen 指定的是nginx代理uwsgi对外的端口号。
server_name 网上大多资料都是设置的一个网址（例，wwwexamplecom），我这里如果设置成网址无法访问，所以，指定的到了本机默认ip。
在进行配置的时候，我有个问题一直想不通。nginx到底是如何uwsgi产生关联。现在看来大概最主要的就是这两行配置。
include uwsgi_params;
uwsgi_pass 127.0.0.1:8000;
include 必须指定为uwsgi_params；而uwsgi_pass指的本机IP的端口与myweb_uwsgi.ini配置文件中的必须一直。
现在重新启动nginx，翻看上面重启动nginx的命令。然后，访问：http//127.0.0.1:8099/
通过这个IP和端口号的指向，请求应该是先到nginx的。如果你在页面上执行一些请求，就会看到，这些请求最终会转到uwsgi来处理。
如何利用django的session框架实现合理地统计浏览量
这种需求用session个人认为并不合理 可以选择存表或走缓存或走cookie 建议走缓存
django定时器_djcelery+mq的使用
-1、配置 settings.py
启动worker： celery -A 项目名 worker -l info -P eventlet
启动beat ： celery -A 项目名beat -l info
启动celery后台（需要查看才启动）： celery flower
启动mq：自行百度
django后台也可以查看定时任务
结语：以上就是首席CTO笔记为大家介绍的关于怎么测django并发量的全部内容了，希望对大家有所帮助，如果你还想了解更多这方面的信息，记得收藏关注本站。