如何对网站进行分析?
我目前有一个 django 网站,它有点慢,所以我想了解发生了什么。我如何对其进行分析以区分:
- 网络效应的影响
- 托管的
- javascript 效应的影响
- 我正在使用服务器端执行(python 代码)的
- 和 sql 访问的影响。由于今晚我碰巧头痛欲裂,所以我没有考虑任何其他影响。
当然,对于其中一些我可以使用 firebug,但有些效果是相关的(例如 javascript 可能会显得很慢,因为它的网络访问速度很慢)
谢谢
I currently have a django site, and it's kind of slow, so I want to understand what's going on. How can I profile it so to differentiate between:
- effect of the network
- effect of the hosting I'm using
- effect of the javascript
- effect of the server side execution (python code) and sql access.
- any other effect I am not considering due to the massive headache I happen to have tonight.
Of course, for some of them I can use firebug, but some effects are correlated (e.g. javascript could appear slow because it's doing slow network access)
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
客户端:
服务器端(我假设你坐在一些类似unix的服务器上):
使用apache bench(ab,apache webserver包的一部分)检查带有小静态内容(小gif或小html页面)的Web服务器) 或 httperf,服务器应该能够每秒至少回答 100 个请求(当然,这在很大程度上取决于测试内容的大小、网络服务器类型、硬件和其他内容,因此不要认真对待这 100 个请求)。如果看起来不错,
ab
或httperf
测试 django,如果速度很慢,这是一个提示你需要更多的CPU能力。使用top
检查服务器上的CPU利用率。如果没问题,问题可能出在 Web 服务器执行 python 代码的方式如果提供半静态内容没问题,则问题可能出在数据库或 IO 绑定上。数据库问题涉及面很广,以下是一些一般性建议:
如果您让我们知道您使用的硬件/软件,我也许能够提供更详细的建议
编辑/PS:忘记一件事:当然您的应用程序可能有一个糟糕的设计并做了很多不必要/低效的事情......
client side:
server side (i assume you sit on some unix-alike server):
check the web server with a small static content (a small gif or a little html page), using apache bench (ab, part of the apache webserver package) or httperf, the server should be able to answerat least 100 requests per second (of course this depends heavily on the size of your test content, webserver type, hardware and other stuff, so dont take that 100 to seriously). if that looks good,
test django with
ab
orhttperf
on a "static view" (one that doesnt use a database object), if thats slow it's a hint that you need more cpu power. check cpu utilization on the server withtop
. if thats ok, the problem might be in the way the web server executes the python codeif serving semi-static content is ok, your problem might be the database or IO-bound. Database problems are a wide field, here is some general advice:
iostat
. if you see lot's of writes then you have get a better disc subsystem, faster raid, SSD hard drives .. or optimize your application to write less.if you let us know what hardware/software you use i might be able to give more detailed advice
edit/PS: forgot one thing: of course your app might have a bad design and does lots of unnecessary/inefficient things ...
查看 Django 调试工具栏 - 这将帮助您处理服务器端代码(例如运行哪些数据库查询以及它们花费了多长时间);通常是 Django 开发的重要资源。
您可以使用 yslow 来分析其他非 Django 特定位。
Take a look at the Django debug toolbar - that'll help you with the server side code (e.g. what database queries ran and how long they took); and is generally a great resource for Django development.
The other non-Django specific bits you could profile with yslow.
有各种各样的工具,但像这样的问题并不难发现,因为它们很大。
你有一个问题,当你删除它时,你会体验到加速。假设加速比是某个因素,例如 2 倍。这意味着程序花费了 50% 的时间来等待缓慢的部分。我所做的就是停止它几次,看看它在等待什么。在这种情况下,我有 50% 的时间会看到这个问题并停止它。
首先,我会在客户端执行此操作。如果我发现 50% 的时间花在等待服务器上,那么我会尝试在服务器端停止它。然后,如果我看到它正在等待 SQL 查询,我可以查看它们。
我几乎可以肯定地发现,所要求的工作比实际需要的要多。它通常不是像“热点”或“算法”这样深奥的东西。这通常是一些愚蠢的事情,比如在一个查询就足够的情况下执行多个查询,以避免编写代码来保存第一个查询的结果。
这是一个示例。
There are various tools, but problems like this are not hard to find because they are big.
You have a problem, and when you remove it, you will experience a speedup. Suppose that speedup is some factor, like 2x. That means the program is spending 50% of its time waiting for the slow part. What I do is just stop it a few times and see what it's waiting for. In this case, I would see the problem 50% of the times I stop it.
First I would do this on the client side. If I see that the 50% is spent waiting for the server, then I would try stopping it on the server side. Then if I see it is waiting for SQL queries, I could look at those.
What I'm almost certain to find out is that more work is being requested than is actually needed. It is not usually something esoteric like a "hotspot" or an "algorithm". It is usually something dumb, like doing multiple queries when one would have been sufficient, so as to avoid having to write the code to save the result from the first query.
Here's an example.
要事第一;确保您知道哪些页面速度较慢。你可能会感到惊讶。我推荐 django_dumpslow。
First things first; make sure you know which pages are slow. You might be surprised. I recommend django_dumpslow.