Django 应用程序基准测试
我有兴趣测试 Django 应用程序的性能,获取逐行性能数据的最佳方法是什么?
注意:谷歌搜索后发现很多人对 django 本身进行基准测试。 我不是在寻找 django 基准测试,我只是想测试我正在编写的 django 应用程序的性能:)
谢谢!
编辑:“逐行”我只是指对各个函数、数据库调用等进行计时,以在非常细粒度的级别上找出瓶颈所在
I'm interested in testing the performance of my django apps as I go, what is the best way to get line by line performance data?
note: Googling this returns lots of people benchmarking django itself. I'm not looking for a benchmarks of django, I'm trying to test the performance of the django apps that I'm writing :)
Thanks!
edit: By "line by line" I just mean timing individual functions, db calls, etc to find out where the bottlenecks are on a very granular level
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这有两层。 我们已经准备好#1 的大部分内容来进行测试。 我们将从#2 开始。
孤立的 Django。 普通的 Django 单元测试在这里运行良好。 创建一些循环测试几个(少于 6 个)“典型”用例的测试。 获取这个、发布那个等等。收集计时数据。 这不是真正的 Web 性能,但它是一个易于使用的测试场景,可用于调整。
您的整个网络堆栈。 在这种情况下,您需要一个运行 Squid、Apache、Django、MySQL 等的常规服务器。 您需要第二台计算机作为客户端通过 urllib2 运行您的网站,执行一些(少于 6 个)“典型”用例。 获取这个、发布那个等等。收集计时数据。 这仍然不是“真正的”网络性能,因为它不是通过互联网,但它已经是您无需进行真正复杂的设置即可获得的最接近的性能。
请注意,#2(端到端)包含大量性能缓存。 如果您的客户端脚本正在执行类似的工作,那么缓存将非常有益。 如果您的客户端脚本每次都执行独特的操作,那么缓存的好处就会减少。
最困难的部分是确定“典型”工作负载是什么。 这不是功能测试,因此工作负载不必包括所有内容。 此外,客户端运行的并发会话越多,速度就越慢。 当您的测试客户端是处理过程中最慢的部分时,不要费力尝试优化您的服务器。
编辑
如果“逐行”意味着“分析”,那么您必须运行一个 Python 分析器。
https://docs.python.org/library/profile.html
请注意, Django ORM 层中有大量缓存。 因此,运行视图函数六次来获得一组有意义的测量值是不明智的。 您必须运行一组“典型”操作,然后在配置文件中找到热点。
一般来说,您的应用程序很容易优化——您不应该做太多事情。 您的视图函数应该很短并且没有任何处理可言。 同样,您的表单和模型方法函数应该非常短。
There's two layers to this. We have most of #1 in place for our testing. We're about to start on #2.
Django in isolation. The ordinary Django unit tests works well here. Create some tests that cycle through a few (less than 6) "typical" use cases. Get this, post that, etc. Collect timing data. This isn't real web performance, but it's an easy-to-work with test scenario that you can use for tuning.
Your whole web stack. In this case, you need a regular server running Squid, Apache, Django, MySQL, whatever. You need a second computer(s) to act a client exercise your web site through urllib2, doing a few (less than 6) "typical" use cases. Get this, post that, etc. Collect timing data. This still isn't "real" web performance, because it isn't through the internet, but it's as close as you're going to get without a really elaborate setup.
Note that the #2 (end-to-end) includes a great deal of caching for performance. If your client scripts are doing similar work, caching will be really beneficial. if your client scripts do unique things each time, caching will be less beneficial.
The hardest part is determining what the "typical" workload is. This isn't functional testing, so the workload doesn't have to include everything. Also, the more concurrent sessions your client is running, the slower it becomes. Don't struggle trying to optimize your server when your test client is the slowest part of the processing.
Edit
If "line-by-line" means "profiling", well, you've got to get a Python profiler running.
https://docs.python.org/library/profile.html
Note that there's plenty of caching in the Django ORM layer. So running a view function a half-dozen times to get a meaningful set of measurements isn't sensible. You have to run a "typical" set of operations and then find hot-spots in the profile.
Generally, your application is easy to optimize -- you shouldn't be doing much. Your view functions should be short and have no processing to speak of. Your form and model method functions, similarly, should be very short.
逐行获取 Django 应用程序性能数据(分析)的一种方法是使用 WSGI 中间件组件,例如 repoze.profile。
假设您将 mod_wsgi 与 Apache 一起使用,您可以将 repoze.profile 插入到您的应用程序中,如下所示:
现在您可以将浏览器指向 /_profile 以查看您的配置文件数据。 当然,这不适用于 mod_python 或内部 Django 服务器。
One way to get line by line performance data (profiling) your Django app is to use a WSGI middleware component like repoze.profile.
Assuming you are using mod_wsgi with Apache you can insert repoze.profile into your app like this:
And now you can point your browser to /_profile to view your profile data. Of course this won't work with mod_python or the internal Django server.