生产 Web 应用程序的“平均”每秒请求是多少？

我对什么是“快速”没有参照系; 我一直想知道这个问题，但是从来没有找到一个直接的答案..。

149918 次浏览
小开

这是一个非常公开的问题。

你在问我 1. 生产应用程序的平均请求负载 被认为是快的东西

这些不一定有联系。

每秒平均请求数由

同时使用的人数

他们每秒发出的页面请求的平均数

额外请求的数量(即 ajax 调用等)

至于什么叫快。.你的意思是一个网站能接受的请求有多少？或者，如果一个硬件可以每秒处理 xyz # 的请求，那么它是否被认为是快速的？

小开

当我走到我的网站主机的控制面板，打开 phpMyAdmin，点击“显示 MySQL 运行时信息”，我得到:

这个 MySQL 服务器已经运行了53天15小时28分53秒。它开始于2008年10月24日凌晨4:03。

查询统计: 自启动以来，已向服务器发送了3,444,378,344个查询。

总计3,444米
每小时2.68米
每分钟44.59公里
每秒743.13 < br >

在过去的53天里，平均每秒钟有743个 mySQL 查询！

我不知道你怎么样，但是对我来说，那很快! 非常快! ！

小开
最佳答案

OpenStreetMap 似乎有 每秒10-20

Wikipedia 似乎是 每秒30000到70000分布在 300台服务器上(每台机器每秒100到200个请求，其中大部分是缓存)

Geograph 正在获得 每周7000张图片(每95秒上传1次)

小开

请注意，命中率图将是正弦模式的“高峰时间”可能2倍或3倍的速率，你得到当用户睡觉。(当您安排每天的批处理工作在服务器上进行时，可能会很有用)

你甚至可以在维基百科这样的“国际”(多语言，本地化)网站上看到这种效果

小开

每个用户通常少于2秒-即用户看到比这更慢的反应认为系统是慢的。

现在告诉我你连接了多少用户。

小开

你可以在“ slashdot 效应分析”中搜索 你会看到什么的图表，如果网站的某些方面突然在新闻中流行起来，例如 这是维基百科上的图表。

生存下来的 Web 应用程序往往能够生成静态页面，而不是通过处理语言处理每个请求。

有一个很棒的视频(我想可能是在 ted.com 上？我觉得可能是 Flickr 网络团队干的？有人知道这个链接吗?)如何在单一服务器之外扩展网站，例如如何在只读和读写服务器之间分配连接，以便为不同类型的用户提供最佳效果。

小开

不确定是否还有人对此感兴趣，但这个信息 是关于推特的(和 这里也是) :

统计数据

  • 超过350,000用户。实际数字一如既往，非常超级绝密。
  • 每秒600个请求。
  • 平均每秒200-300个连接。达到每秒800个连接。
  • MySQL 每秒处理2400个请求。
  • 180个 Rails 实例，使用 Mongrel 作为“ web”服务器。
  • 1个 MySQL 服务器(一个大的8核框)和1个从服务器。从服务器只读取统计和报告。
  • 30 + 处理零工的流程。
  • 8辆 Sun X4100。
  • 在 Rails 中以200毫秒处理请求。
  • 在数据库中花费的平均时间为50-100毫秒。
  • 超过16GB 的 memcached。
小开

就我个人而言，我喜欢每次都进行分析... ... 请求/秒和平均时间/请求，并且喜欢看到最大请求时间。如果你有61个请求/秒，很容易翻转，然后你可以直接翻转到1000ms/61个请求。

为了回答你的问题，我们自己做了一个大型的负载测试，发现它适用于我们使用的各种亚马逊硬件(最好的值是32位中型 CPU，当它降到 $$/event/second 时) ，我们的请求/秒从29个请求/秒/节点到150个请求/秒/节点。

提供更好的硬件当然会带来更好的结果，但不会带来最好的投资回报率。无论如何，这篇文章是伟大的，因为我正在寻找一些相似之处，看看我的数字是否在球场和分享我的，以防有人正在寻找。我的是纯粹的负载，因为我可以去。

注意: 多亏了请求/第二次分析(而不是 ms/request) ，我们发现了一个主要的 linux 问题，我们正试图解决 linux (我们测试了一个 C 和 java 服务器)冻结所有调用到套接字库时，在过多的负载下，这似乎很奇怪。完整的帖子可以在这里找到实际上... 。 Http://ubuntuforums.org/showthread.php?p=11202389

我们仍在努力解决这个问题，因为它给我们带来了巨大的性能提升，当这个问题解决后，我们的测试从2分42秒提升到1分35秒，所以我们看到了33% 的性能提升... ... 更不用说，DoS 攻击越糟糕，这些暂停时间越长，所有的 CPU 都会降到零并停止处理... ... 在我看来，服务器处理应该在面对 DoS 时继续运行，但出于某种原因，在 DoS 期间，它会时不时地冻结，有时长达30秒! ! ！

附加: 我们发现它实际上是一个 jdk 竞争条件错误... ... 很难在大的集群上隔离，但是当我们运行1个服务器1数据节点，但是其中10个，我们可以每次都重现它，只要看看它发生在哪个服务器/数据节点上就可以了。将 jdk 切换到早期版本修复了这个问题。我记得我们在 jdk1.6.0 _ 26上。

小开

我有一个客户使用我们的软件在一个商业网络应用服务器。软件在40台服务器上运行。这个软件是一个有10年历史的 JavaAPI。

4000 TPS.


提交答案