- 浏览: 634071 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
liuche20083736:
非常好
从问题看本质: 研究TCP close_wait的内幕 -
xiaopohai85707:
优化算法与原来需求不符
过滤字符的性能调优?挤一挤还是有的 -
kmy_白衣:
生成的area图有时候 标签的数值和图标上看上去的数值不一致。 ...
OpenFlashChart2之恶心文档 -
tom&jerry:
大神,请教一个问题,按名称排序为何无效,用的2.4.3 XPA ...
深入浅出jackrabbit之十三 查询之AST和QT -
jd2bs:
改成精确匹配可以了< filter-mapping &g ...
细谈Ehcache页面缓存的使用
/**
*作者:张荣华
*日期:2008-11-15
**/
之前网上有很多关于django的测试,他们的测试结果都表明django在fastcgi模式下,使用线程模型要比进程模型快,而且更稳定,具体文章见:
http://irobot.blog.hexun.com/20332312_d.html
http://taoyh163.blog.163.com/blog/static/19580356200802433559850/
但是ahuaxuan根据操作系统的原理判断结果不应该是这样,理论上来讲,进程应该更快。为了证明自己的观点,于是做了以下测试。
那么在讲解我的测试方法之前,按照惯例,现来讲以下dango中fastcgi模式的一些知识点。
dango的fastcgi模式有如下几个重要参数:
相信做java的同学一看就比较明白了,很多参数和tomcat中是一样的,主要有一个host,port,socket需要讲解一下,host和port我们知道应该是成对出现的,那么socket是什么呢,其实他们都是socket,只不过,host+port模式是tcp sock,而socket是unix sock,他们都是套接字,一个是操作系统本地的,一个是网络套接字而已。
我的测试工具是apachbench,简称ab,在apache的bin目录中有这个工具。我的web服务器是lighttpd1.4。
我一共划分了4个场景,第一个场景是操作数据库的请求,第二个场景是请求缓存的场景,而且使用线程模型,第3和第4个场景都是fastcgi的进程模型。
场景一
涉及到查数据库的url,每次请求一条简单的sql语句。
python manage.py runfcgi method=threaded host=127.0.0.1 port=3033 daemonize=false
请求数 并发数 总时间
场景二
不涉及到数据的url,执行一段判断后返回(可以认为数据都放在缓存中)。
python manage.py runfcgi method=threaded host=127.0.0.1 port=3033
请求数 并发数 总时间
5000 50 7.734s
5000 25 7.545s
5000 10 7.481s
5000 100 7.776s
场景一和场景 二对比可以发现,带有数据操作的请求明显需要更多的时间,之间从缓存中拿数据,每秒中fastcgi可以处理1000个请求。
场景三
不涉及到数据的url,执行一段判断后返回(可以认为数据都放在缓存中)。使用进程模型。
python manage.py runfcgi method=prefork host=127.0.0.1 port=3033
请求数 并发数 总时间
5000 50 22 s
5000 25 25 s
5000 10 15 s
5000 100 21 s
通过场景二和三的对比,我们可以看出线程模型在默认情况下比进程模型更加快。不过根据操作系统的特性,ahuaxuan认为事有蹊跷。理论上来讲,在速度方面,进程模型不应该比线程模型慢,虽然网上有的文章确实有提到线程模型比进程模型快,不过ahuaxuan觉得他们的测试是有问题的。在研究了django的fastcgi参数之后,再根据做java的经验我发现问题可能出现在进程的创建上。于是调整参数,继续测试。
场景四
不涉及到数据的url,执行一段判断后返回(可以认为数据都放在缓存中)。将最大进程数和最小进程数调整到50。
python manage.py runfcgi method=prefork host=127.0.0.1 port=3033 daemonize=false minspare=50 maxspare=50
请求数 并发数 总时间
5000 100 8.16s
第一次:
第二次
分析,一模一样的两次请求,为什么差两倍的速度呢,根据ahuaxuan的分析,问题应该出在进程的创建上,第二次测试,由于进程已经存在,所以速度非常的快,比线程模型快了2倍不到一点。
5000 25 8.90s
5000 10 8.78s
5000 50 7.90s
对比场景三和场景四发现,在进程模式下在没有指定maxspare和minspare值的情况下,由于每次并发大的时候都动态的去创建进程,效率明显下降,5000个请求居然需要20s之多。而一旦设置了maxspare和minspare之后,只有第一次请求的时候,需要创建进程,之后经常已经存在,不需要创建,也不需要动态的消亡(maxspare和minspare值太小会导致fastcgi父进程频繁的创建和销毁子进程,非常的消耗cpu),整个应用程序的处理能力大大提高。
再对比场景二和场景四,可以发现不管是进程模式还是线程模式,每秒都能处理超过1000次的请求。而且在并发较大的情况下,进程模式效率更高。由此可见在网站访问量巨大的情况下,使用进程模型才是比较好的选择,而不是网上所说的使用线程模型。
后来为了作对比,ahuaxuan在线程模型上也加了maxspare=50,minspare=50,不过性能和没有加几乎一样,可见,这两个参数对进程模型的影响比较大。而且也可以进一步说明操作系统创建进程消耗确实大。
从这个对比结果,我们还可以得知:
1线程创建在ubuntu中的代价比进程小的多。(根据观察,在创建进程的时候,cpu上升到100%,而线程模型的cpu只有80%的样子)
2在进程已经存在的情况下,处理请求的能力,进程要比线程能力强。而且要强出1/3左右的样子
最后,贴出我的机器配置
cpu:t8100
内存:2g
硬盘:5400转的希捷
希望本文能够给对django性能有怀疑,以及对fastcgi下认为线程模型更快的同学有所帮助。
从你的测试结果得出的结论是:
在线程模型下,scgi的速度比fastcgi更快
于是我也做一个测试
测试cast:
./ab -c 100 -n 5000 http://localhost/mark.html
django启动命令:python manage.py runfcgi host=127.0.0.1 port=3033 method=prefork protocol=scgi daemonize=false
结果:
对比我的测试场景二,发现,scgi下的线程模型和fastcgi下的线程模型也是差不多
你的测试结果怎么相差那么多,能给出你的测试方法吗?
------------------------------------------
但是在进程模型下,scgi和fastcgi谁快呢
于是我又做了一个测试:
测试case:
./ab -c 100 -n 5000 http://localhost/mark.html
django启动命令:python manage.py runfcgi host=127.0.0.1 port=3033 method=prefork protocol=scgi daemonize=false minspare=50 maxspare=50
测试结果
第一次请求:
第二次请求
结合我文章中的场景四可以得出结论
在scgi模式下的进程模型和fastcgi模式下的进程模型速度不相上下
没试,不过我想不会高到哪里去的,因为fastcgi的进程模型已经够快了,每天2000w根本不是什么难事,关键看程序怎么写。反正django给我们带来的特性已经支持每天2000w了
其实写这篇文章的主要目的是为了给进程模型讨会一个公道,也省得网上一些文章继续误导大家
5000次请求只要5秒钟,而且是在我的笔记本上。
*作者:张荣华
*日期:2008-11-15
**/
之前网上有很多关于django的测试,他们的测试结果都表明django在fastcgi模式下,使用线程模型要比进程模型快,而且更稳定,具体文章见:
http://irobot.blog.hexun.com/20332312_d.html
http://taoyh163.blog.163.com/blog/static/19580356200802433559850/
但是ahuaxuan根据操作系统的原理判断结果不应该是这样,理论上来讲,进程应该更快。为了证明自己的观点,于是做了以下测试。
那么在讲解我的测试方法之前,按照惯例,现来讲以下dango中fastcgi模式的一些知识点。
dango的fastcgi模式有如下几个重要参数:
protocol=PROTOCOL fcgi, scgi, ajp, ... (default fcgi) host=HOSTNAME hostname to listen on.. port=PORTNUM port to listen on. socket=FILE UNIX socket to listen on. method=IMPL prefork or threaded (default prefork) maxrequests=NUMBER number of requests a child handles before it is killed and a new child is forked (0 = no limit). maxspare=NUMBER max number of spare processes / threads minspare=NUMBER min number of spare processes / threads. maxchildren=NUMBER hard limit number of processes / threads daemonize=BOOL whether to detach from terminal. pidfile=FILE write the spawned process-id to this file. workdir=DIRECTORY change to this directory when daemonizing. outlog=FILE write stdout to this file. errlog=FILE write stderr to this file. umask=UMASK umask to use when daemonizing (default 022).
相信做java的同学一看就比较明白了,很多参数和tomcat中是一样的,主要有一个host,port,socket需要讲解一下,host和port我们知道应该是成对出现的,那么socket是什么呢,其实他们都是socket,只不过,host+port模式是tcp sock,而socket是unix sock,他们都是套接字,一个是操作系统本地的,一个是网络套接字而已。
我的测试工具是apachbench,简称ab,在apache的bin目录中有这个工具。我的web服务器是lighttpd1.4。
我一共划分了4个场景,第一个场景是操作数据库的请求,第二个场景是请求缓存的场景,而且使用线程模型,第3和第4个场景都是fastcgi的进程模型。
场景一
涉及到查数据库的url,每次请求一条简单的sql语句。
python manage.py runfcgi method=threaded host=127.0.0.1 port=3033 daemonize=false
请求数 并发数 总时间
5000 50 22.86s 5000 25 23.37s 5000 10 23.37s 5000 100 21.58s
场景二
不涉及到数据的url,执行一段判断后返回(可以认为数据都放在缓存中)。
python manage.py runfcgi method=threaded host=127.0.0.1 port=3033
请求数 并发数 总时间
5000 50 7.734s
Concurrency Level: 50 Time taken for tests: 7.883 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 5505084 bytes HTML transferred: 4685937 bytes Requests per second: 634.28 [#/sec] (mean) Time per request: 78.830 [ms] (mean) Time per request: 1.577 [ms] (mean, across all concurrent requests) Transfer rate: 681.98 [Kbytes/sec] received
5000 25 7.545s
Concurrency Level: 25 Time taken for tests: 7.859 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 5504770 bytes HTML transferred: 4685000 bytes Requests per second: 636.20 [#/sec] (mean) Time per request: 39.296 [ms] (mean) Time per request: 1.572 [ms] (mean, across all concurrent requests) Transfer rate: 684.01 [Kbytes/sec] received
5000 10 7.481s
Concurrency Level: 10 Time taken for tests: 7.920 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 5503153 bytes HTML transferred: 4685000 bytes Requests per second: 631.28 [#/sec] (mean) Time per request: 15.841 [ms] (mean) Time per request: 1.584 [ms] (mean, across all concurrent requests) Transfer rate: 678.52 [Kbytes/sec] received
5000 100 7.776s
Concurrency Level: 100 Time taken for tests: 7.776 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 5504370 bytes HTML transferred: 4685937 bytes Requests per second: 643.04 [#/sec] (mean) Time per request: 155.511 [ms] (mean) Time per request: 1.555 [ms] (mean, across all concurrent requests) Transfer rate: 691.32 [Kbytes/sec] received
场景一和场景 二对比可以发现,带有数据操作的请求明显需要更多的时间,之间从缓存中拿数据,每秒中fastcgi可以处理1000个请求。
场景三
不涉及到数据的url,执行一段判断后返回(可以认为数据都放在缓存中)。使用进程模型。
python manage.py runfcgi method=prefork host=127.0.0.1 port=3033
请求数 并发数 总时间
5000 50 22 s
Concurrency Level: 50 Time taken for tests: 22.676 seconds Complete requests: 5000 Failed requests: 15 (Connect: 0, Receive: 0, Length: 15, Exceptions: 0) Write errors: 0 Non-2xx responses: 15 Total transferred: 5519788 bytes HTML transferred: 4676480 bytes Requests per second: 220.50 [#/sec] (mean) Time per request: 226.762 [ms] (mean) Time per request: 4.535 [ms] (mean, across all concurrent requests) Transfer rate: 237.71 [Kbytes/sec] received
5000 25 25 s
Concurrency Level: 25 Time taken for tests: 25.330 seconds Complete requests: 5000 Failed requests: 15 (Connect: 0, Receive: 0, Length: 15, Exceptions: 0) Write errors: 0 Non-2xx responses: 15 Total transferred: 5481652 bytes HTML transferred: 4676480 bytes Requests per second: 197.40 [#/sec] (mean) Time per request: 126.649 [ms] (mean) Time per request: 5.066 [ms] (mean, across all concurrent requests) Transfer rate: 211.34 [Kbytes/sec] received
5000 10 15 s
Concurrency Level: 10 Time taken for tests: 15.463 seconds Complete requests: 5000 Failed requests: 9 (Connect: 0, Receive: 0, Length: 9, Exceptions: 0) Write errors: 0 Non-2xx responses: 9 Total transferred: 5536528 bytes HTML transferred: 4679888 bytes Requests per second: 323.35 [#/sec] (mean) Time per request: 30.926 [ms] (mean) Time per request: 3.093 [ms] (mean, across all concurrent requests) Transfer rate: 349.66 [Kbytes/sec] received
5000 100 21 s
Concurrency Level: 100 Time taken for tests: 21.225 seconds Complete requests: 5000 Failed requests: 15 (Connect: 0, Receive: 0, Length: 15, Exceptions: 0) Write errors: 0 Non-2xx responses: 15 Total transferred: 5541355 bytes HTML transferred: 4676480 bytes Requests per second: 235.57 [#/sec] (mean) Time per request: 424.498 [ms] (mean) Time per request: 4.245 [ms] (mean, across all concurrent requests) Transfer rate: 254.96 [Kbytes/sec] received
通过场景二和三的对比,我们可以看出线程模型在默认情况下比进程模型更加快。不过根据操作系统的特性,ahuaxuan认为事有蹊跷。理论上来讲,在速度方面,进程模型不应该比线程模型慢,虽然网上有的文章确实有提到线程模型比进程模型快,不过ahuaxuan觉得他们的测试是有问题的。在研究了django的fastcgi参数之后,再根据做java的经验我发现问题可能出现在进程的创建上。于是调整参数,继续测试。
场景四
不涉及到数据的url,执行一段判断后返回(可以认为数据都放在缓存中)。将最大进程数和最小进程数调整到50。
python manage.py runfcgi method=prefork host=127.0.0.1 port=3033 daemonize=false minspare=50 maxspare=50
请求数 并发数 总时间
5000 100 8.16s
第一次:
Concurrency Level: 100 Time taken for tests: 9.682 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 5557585 bytes HTML transferred: 4685000 bytes Requests per second: 516.42 [#/sec] (mean) Time per request: 193.642 [ms] (mean) Time per request: 1.936 [ms] (mean, across all concurrent requests) Transfer rate: 560.55 [Kbytes/sec] received
第二次
Concurrency Level: 100 Time taken for tests: 5.134 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 5560000 bytes HTML transferred: 4685000 bytes Requests per second: 973.84 [#/sec] (mean) Time per request: 102.686 [ms] (mean) Time per request: 1.027 [ms] (mean, across all concurrent requests) Transfer rate: 1057.53 [Kbytes/sec] received
分析,一模一样的两次请求,为什么差两倍的速度呢,根据ahuaxuan的分析,问题应该出在进程的创建上,第二次测试,由于进程已经存在,所以速度非常的快,比线程模型快了2倍不到一点。
5000 25 8.90s
Concurrency Level: 25 Time taken for tests: 5.347 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 5559748 bytes HTML transferred: 4685000 bytes Requests per second: 935.07 [#/sec] (mean) Time per request: 26.736 [ms] (mean) Time per request: 1.069 [ms] (mean, across all concurrent requests) Transfer rate: 1015.38 [Kbytes/sec] received
5000 10 8.78s
Concurrency Level: 10 Time taken for tests: 5.723 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 5562916 bytes HTML transferred: 4687811 bytes Requests per second: 873.64 [#/sec] (mean) Time per request: 11.446 [ms] (mean) Time per request: 1.145 [ms] (mean, across all concurrent requests) Transfer rate: 949.22 [Kbytes/sec] received
5000 50 7.90s
Concurrency Level: 50 Time taken for tests: 5.239 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 5560923 bytes HTML transferred: 4685937 bytes Requests per second: 954.43 [#/sec] (mean) Time per request: 52.387 [ms] (mean) Time per request: 1.048 [ms] (mean, across all concurrent requests) Transfer rate: 1036.63 [Kbytes/sec] received
对比场景三和场景四发现,在进程模式下在没有指定maxspare和minspare值的情况下,由于每次并发大的时候都动态的去创建进程,效率明显下降,5000个请求居然需要20s之多。而一旦设置了maxspare和minspare之后,只有第一次请求的时候,需要创建进程,之后经常已经存在,不需要创建,也不需要动态的消亡(maxspare和minspare值太小会导致fastcgi父进程频繁的创建和销毁子进程,非常的消耗cpu),整个应用程序的处理能力大大提高。
再对比场景二和场景四,可以发现不管是进程模式还是线程模式,每秒都能处理超过1000次的请求。而且在并发较大的情况下,进程模式效率更高。由此可见在网站访问量巨大的情况下,使用进程模型才是比较好的选择,而不是网上所说的使用线程模型。
后来为了作对比,ahuaxuan在线程模型上也加了maxspare=50,minspare=50,不过性能和没有加几乎一样,可见,这两个参数对进程模型的影响比较大。而且也可以进一步说明操作系统创建进程消耗确实大。
从这个对比结果,我们还可以得知:
1线程创建在ubuntu中的代价比进程小的多。(根据观察,在创建进程的时候,cpu上升到100%,而线程模型的cpu只有80%的样子)
2在进程已经存在的情况下,处理请求的能力,进程要比线程能力强。而且要强出1/3左右的样子
最后,贴出我的机器配置
cpu:t8100
内存:2g
硬盘:5400转的希捷
希望本文能够给对django性能有怀疑,以及对fastcgi下认为线程模型更快的同学有所帮助。
评论
4 楼
ahuaxuan
2008-11-15
剑 事 写道
lighttpd+fastcgi+threaded Requests per second: 591.93 [#/sec] (mean)
lighttpd+scgi+threaded Requests per second: 806.19 [#/sec] (mean)
我用scgi 不过没测试过
lighttpd+scgi+threaded Requests per second: 806.19 [#/sec] (mean)
我用scgi 不过没测试过
从你的测试结果得出的结论是:
在线程模型下,scgi的速度比fastcgi更快
于是我也做一个测试
测试cast:
./ab -c 100 -n 5000 http://localhost/mark.html
django启动命令:python manage.py runfcgi host=127.0.0.1 port=3033 method=prefork protocol=scgi daemonize=false
结果:
Concurrency Level: 100 Time taken for tests: 8.240 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 5512708 bytes HTML transferred: 4685000 bytes Requests per second: 606.80 [#/sec] (mean) Time per request: 164.800 [ms] (mean) Time per request: 1.648 [ms] (mean, across all concurrent requests) Transfer rate: 653.34 [Kbytes/sec] received
对比我的测试场景二,发现,scgi下的线程模型和fastcgi下的线程模型也是差不多
你的测试结果怎么相差那么多,能给出你的测试方法吗?
------------------------------------------
但是在进程模型下,scgi和fastcgi谁快呢
于是我又做了一个测试:
测试case:
./ab -c 100 -n 5000 http://localhost/mark.html
django启动命令:python manage.py runfcgi host=127.0.0.1 port=3033 method=prefork protocol=scgi daemonize=false minspare=50 maxspare=50
测试结果
第一次请求:
Concurrency Level: 100 Time taken for tests: 9.617 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 5557396 bytes HTML transferred: 4685000 bytes Requests per second: 519.91 [#/sec] (mean) Time per request: 192.342 [ms] (mean) Time per request: 1.923 [ms] (mean, across all concurrent requests) Transfer rate: 564.32 [Kbytes/sec] received
第二次请求
Concurrency Level: 100 Time taken for tests: 5.330 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 5559979 bytes HTML transferred: 4685000 bytes Requests per second: 938.02 [#/sec] (mean) Time per request: 106.607 [ms] (mean) Time per request: 1.066 [ms] (mean, across all concurrent requests) Transfer rate: 1018.63 [Kbytes/sec] received
结合我文章中的场景四可以得出结论
在scgi模式下的进程模型和fastcgi模式下的进程模型速度不相上下
3 楼
剑事
2008-11-15
lighttpd+fastcgi+threaded Requests per second: 591.93 [#/sec] (mean)
lighttpd+scgi+threaded Requests per second: 806.19 [#/sec] (mean)
我用scgi 不过没测试过
lighttpd+scgi+threaded Requests per second: 806.19 [#/sec] (mean)
我用scgi 不过没测试过
2 楼
ahuaxuan
2008-11-15
剑 事 写道
protocol=scgi
没试,不过我想不会高到哪里去的,因为fastcgi的进程模型已经够快了,每天2000w根本不是什么难事,关键看程序怎么写。反正django给我们带来的特性已经支持每天2000w了
其实写这篇文章的主要目的是为了给进程模型讨会一个公道,也省得网上一些文章继续误导大家
5000次请求只要5秒钟,而且是在我的笔记本上。
1 楼
剑事
2008-11-15
protocol=scgi
发表评论
-
使用netbeans来开发django应用
2009-03-22 12:03 5176周六,朋友介绍我使用netbeans来开发django应用,于 ... -
闲来无聊,用python抓取天气信息,简单就是美啊
2009-02-06 11:39 5565/** * 作者:张荣华 * 日期:2009-02-26 ** ... -
在top监视窗口显示Django当前正在执行的请求URL
2008-12-03 23:06 1505在top监视窗口显示Django当前正在执行的请求URL ... -
完善坛子工具库之--python版memcached遍历脚本
2008-10-22 22:39 2755今天看到robbin大哥用ru ... -
why,how日志监控(附ahuaxuan用python写的日志分析器)
2008-10-21 17:16 2411/** *作者:ahuaxuan *日期:2008-10- ... -
初识django, 一起进入python的世界吧
2008-09-08 11:22 8951[size=medium]这几天花了点时间看了一下python ...
相关推荐
django环境测试前端代码django环境测试前端代码django环境测试前端代码django环境测试前端代码django环境测试前端代码django环境测试前端代码django环境测试前端代码django环境测试前端代码django环境测试前端代码...
yet-another-django-profiler, Django 性能分析中间件和管理命令 yet-another-django-profiler自述文件 然而,另一个 Django 探查器尝试合并多年来创建的它的他 Django 分析实用程序的最佳特性。 ( 有关更多背景信息...
`model_test/`模型测试模块 `result_show/`结果展示模块 `flow_system/`配置模块 `home`主页模块 `requirement.txt`配置要求 `manage.py`django主要运行程序 ## Data `data_raw`存放流量收集来的原始样本 `...
虽然本文是以Django为例,但其他框架和语言的优化原则也是类似的。通过使用这些优化方法,文中例程的查询响应时间从原来的77秒减少到了3.7秒。 本文用到的例程是从一个我曾经使用过的真实项目改编而来的,是性能优化...
浅析Django处理流程和结构分析django.doc浅析Django处理流程和结构分析django.doc
基于Django构建在线文本分类预测系统代码、模型、数据集:SVM模型在线预测与部署 基于 Django 3.2 框架,参考博客:https://blog.csdn.net/wangyaninglm/article/details/116334297
具体可以参考此界面...用现在的数据进行数据清洗和分析,然后采用机器学习算法训练模型,可以对数据输入数据进行预测 目前的数据集和相关特征字段 数据说明 有 3 种类型的输入特征:
一些框架基本知识测试 对于新手上手快 简单测试 Django框架
Django 的测试守护程序。 基于 将尝试找到进行更改的应用程序并仅为该应用程序运行测试。 如果找不到它或影响整个项目的更改,则将运行所有测试。 它不会注意到来自其他应用程序的测试使用已更改的应用程序。 即...
django模型models中常用字段和参数
python课程设计基于Django的学生心理测试系统源码+数据库。获老师指导已通过的高分项目。python课程设计基于Django的学生心理测试系统源码+数据库。获老师指导已通过的高分项目。python课程设计基于Django的学生心理...
,基于Python的django社交网络分析系统源码基于Python的django社交网络分析系统源码基于Python的django社交网络分析系统源码基于Python的django社交网络分析系统源码基于Python的django社交网络分析系统源码基于...
动态创建一个模型的多个table name, 并通过 Django ORM 操作
使用Python Django的Web自动化测试平台
djangobench, 基于时间的Django 性能评估与基准测试 Djangobench一套利用时间测量 Django 性能的工具和测试基准。正在运行基准测试以下是简短版本:mkvirtualenv djangobenchpip install -e git://github.com
Django项目测试实战代码
django-performance-testing:通过自动化测试对Django进行性能测试!
系统的整体框架主要分为注册登录、票房汇总、预测和分析四个部分,注册登录主要为系统提供了...分析主要是通过echarts框架对票房数据的分析结果进行展示,展示的形式包括柱状图、折线图等等。 使用前请仔细查看说明文档
基于Django框架和LDA机器学习模型实现北京旅游路线推荐系统python源码.zip基于Django框架和LDA机器学习模型实现北京旅游路线推荐系统python源码.zip基于Django框架和LDA机器学习模型实现北京旅游路线推荐系统python...