【问题标题】:Adding Azure webrole instances does not affect MVC4 webservice throughput添加 Azure webrole 实例不会影响 MVC4 Web 服务吞吐量
【发布时间】:2013-05-24 15:01:21
【问题描述】:

作为 Azure webrole 的一部分,我有一个非常简单的 MVC4 发布操作:

[HttpPost]
    public ActionResult Index(Request request)
    {
        return new JsonResult() 
        { 
            Data = "OK", 
            JsonRequestBehavior = JsonRequestBehavior.AllowGet 
        };
    }
  1. 我将 webrole 部署到 Azure。
  2. 我使用了基准测试 (ab.exe),发现 25 个并发请求的处理时间不再超过 1 秒。
  3. 现在我想通过添加一个新的 webrole 实例进行横向扩展,因此我预计 +25 个并发用户也会对 1 秒的延迟感到满意。
  4. 我又运行了一次 becnhmark,结果与 1 个 webrole 实例的结果相同。

P.S 我有免费的 Azure 订阅。 Webroles 具有较小的 VM 大小。

为什么当我添加新的 webrole 实例时,webservice 容量没有增加?我错过了一些配置还是什么?

【问题讨论】:

    标签: .net asp.net-mvc-4 azure azure-web-roles


    【解决方案1】:

    对于 25 个并发用户,您预计会发生什么变化?

    通过更多实例横向扩展的想法是处理更多并发用户,而不是更快地处理少量用户......

    我建议你测试边缘情况——比如1000并发用户,用单个实例找到饱和点。假设单个实例可以安全地处理546 并发用户。现在增加实例数,用100 并发用户预热测试。增加到1000 并发用户。您的服务现在可以处理1000 并发用户吗,而不仅仅是546 ...这是添加更多实例的想法...

    所有虚数。

    更新

    有趣,你说你用:

    ab -n 25 -c 25 -p json.file -T "application/json; charset=utf-8" xxxxx.cloudapp.net

    现在来自文档:

    -c concurrency 一次执行的多个请求数。默认是一次一个请求。

    -n requests 为基准测试会话执行的请求数。默认是只执行一个请求,通常 导致不具代表性的基准测试结果。

    当您只执行 25 个并发请求时,您期望得到什么结果?我建议你使用以下参数:

    ab -n 150 -c 1000 -p json.file -T "application/json; charset=utf-8" xxxxx.cloudapp.net

    然后再次检查结果!

    【讨论】:

    • 这正是我所做的。我的饱和点是 25,与 1 个 Web 实例的 546 相反。
    • 再来一次。我有“什么都不做”的 MVC4 网络服务。我希望任何潜在用户等待响应的时间不要超过 1 秒。所以我想确定有多少并发用户可以与 web 服务交互并且等待时间不超过 1 秒。我发现它是25个并发用户。然后我又添加了 1 个 webrole 实例。现在我预计 50 个并发用户可以与 web 服务交互,并且他们中的任何一个都不会等待超过 1 秒。但事实并非如此 - 50 个并发用户将等待他们的响应 2 秒!因此再添加 1 个实例没有效果。我想知道为什么?
    • 你有足够的热身准备吗?
    • 是的,我有。我什至做了10个实例,但没有任何效果。是免费订阅的配置还是限制?但是,它允许我添加 10 个实例,我发现它们在 Azure 管理门户中运行良好。
    • 有趣的观察。我必须自己测试才能看到它。您能否提供您正在使用的确切 ab.exe 命令行?
    猜你喜欢
    • 1970-01-01
    • 2017-08-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-09-02
    • 1970-01-01
    • 2021-12-28
    • 2020-07-04
    相关资源
    最近更新 更多