姜戈性能

发布于 2024-09-28 05:38:40 字数 773 浏览 2 评论 0原文

我正在使用带有 apache mod_wsgi 的 django,我的网站在每个页面上都有动态数据,所有媒体(css、图像、js)都存储在亚马逊 S3 存储桶上,喜欢通过“http://bucket.domain.com/images/*.jpg" 位于标记内。 。 。 。我的问题是,varnish 还能帮助我加快网络服务器的速度吗?

我正在努力击倒这里所有的绊脚石。还有什么我应该看的吗?我在每个页面渲染时为我的代码制作了一个 查询分析器大约0.120 CPU秒,这似乎足够快,但是当我使用ab -c 5 -n 100 http://mysite.com/ 结果仅为每秒请求数:12.70 [#/sec](平均值) 。 。 。

我意识到有很多变数在起作用,但我正在寻找一些关于我可以做的事情的指导,并认为 Varnish 可能是答案。

更新 这是我的分析器的屏幕截图 替代文本

I am using a django with apache mod_wsgi, my site has dynamic data on every page and all of the media (css, images, js) is stored on amazon S3 buckets liked via "http://bucket.domain.com/images/*.jpg" inside the markup . . . . my question is, can varnish still help me speed up my web server?

I am trying to knock down all the stumbling blocks here. Is there something else I should be looking at? I have made a query profiler for my code at each page renders at about 0.120 CPU seconds which seems quick enough, but when I use ab -c 5 -n 100 http://mysite.com/ the results are only Requests per second: 12.70 [#/sec] (mean) . . .

I realize that there are lots of variables at play, but I am looking for some guidance on things I can do and thought Varnish might be the answer.

UPDATE
here is a screenshot of my profiler
alt text

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

乖不如嘢 2024-10-05 05:38:40

提高绩效的唯一方法是衡量拖慢您速度的因素。尽管它不是世界上最好的分析器,但 Django 与热门分析器具有良好的集成(此处描述) 你可以找出是什么占用了这 0.120 cpu 秒。

你用的是2个cpu吗?如果是这种情况,那么当您使用 ab 时,限制可能在数据库中?我这样说只是因为 0.120 * 12.70 是 1.5,这意味着有 0.5 秒的等待时间。这也可能是IO什么的。

无缘无故地添加另一层(例如清漆)通常不是一个好主意。唯一有帮助的情况是,像清漆这样的东西会有所帮助,如果你的客户端速度很慢,连接很差,但 ab 测试没有达到这种条件,坦率地说,这不是一个足够大的问题,不足以保证额外的层。

现在,下一个主题是缓存,varnish 可以提供帮助。您的页面是为每个用户定制的,还是可以长期保持静态?通常,除了简单的登录状态屏幕之外,页面都是静态的——在这种情况下,请考虑使用 cookie 将登录状态加载到 javascript。如果您能够缓存整个页面,那么它们在 ab 中将会非常快。然而,下一个问题是 ab 并不是真正的网站良好基准,因为用户不会只是坐在一个页面上并反复按 f5。

The only way you can improve your performance is if you measure what is slowing you down. Though it's not the best profiler in the world, Django has good integration with the hotshot profiler (described here) and you can figure out what is taking those 0.120 cpu seconds.

Are you using 2 cpus? If that's the case than perhaps the limitation is in the db when you use ab? I only say that because 0.120 * 12.70 is 1.5 which means that there's .5 seconds waiting for something. This could also be IO or something.

Adding another layer for no reason such as varnish is generally not a good idea. The only case where something like varnish would help is if you have slow clients with poor connections hold onto threads, but the ab test is not hitting this condition and frankly it's not a large enough issue to warrant the extra layer.

Now, the next topic is caching, which varnish can help with. Are your pages customized for each user, or can it be static for long periods of time? Often times pages are static except for a simple login status screen -- in this case consider off loading that login status to javascript with cookies. If you are able to cache entire pages then they would be extremely fast in ab. However, the next problem is that ab is not really a good benchmark of your site, since users aren't going to just sit at one page and hit f5 repeatedly.

辞旧 2024-10-05 05:38:40

在安装 varnish 之前需要考虑一些事情:

  • 首先,您是否在 Django 中启用了页面缓存中间件?
  • etag 是否已设置并正常工作?
  • 您的数据库服务器性能是否处于最佳状态?
  • 您是否考虑过在代码中使用 memcached 设置缓存以获得常见结果? (特别是向非登录用户显示的首页和静态页面)

除了绝对必须为每个用户显示显着不同的数据的查询繁重的动态页面之外,0.12 秒似乎是一个很长的时间来提供一个页面。了解如何在应用程序中进行缓存以提高性能。如果您的页面除了用户名或类似内容之外基本上是静态的,请缓存页面的计算部分。

当 Django 的缓存正常工作时,公共页面上的 ab 应该快如闪电。如果您没有使用 Apache 的任何其他功能,请考虑使用更轻、更快的东西,例如 lighttpd 或 nginx。

Eric Florenzano 整理了一个非常有用的项目,名为 django-newcache,它实现了一些高级缓存行为。如果您遇到内置缓存的限制,请考虑一下。 http://github.com/ericflo/django-newcache

A few things to think about before you go installing varnish:

  • First off, have you enabled the page caching middleware within Django?
  • Are etags set up and working properly?
  • Is your database server performing optimally?
  • Have you considered setting up caching using memcached within your code for common results? (particularly front pages and static pages displayed to non-logged-in users)

Except for query heavy dynamic pages that absolutely must display substantially different data for each user, .12 seconds seems like a long time to serve a page. Look at how you can work caching into your app to improve that performance. If you have a page that is largely static other than a username or something similar, cache the computed part of the page.

When Django's caching is working properly, ab on public pages should be lightning fast. If you aren't using any of the other features of Apache, consider using something lighter and faster like lighttpd or nginx.

Eric Florenzano has put together a pretty useful project called django-newcache that implements some advanced caching behavior. If you're running into the limitations of the built-in caching, consider it. http://github.com/ericflo/django-newcache

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文