【问题标题】:UCMA subscribing to presence of many usersUCMA 订阅了多个用户的存在
【发布时间】:2020-02-18 16:25:53
【问题描述】:

我们目前正在设计一个 UCMA 应用程序,该应用程序应该能够订阅多达 15k 用户的状态更新。阅读(相当过时的)documentation 我们注意到以下几点:

Lync Server 2013 还对订阅响应正文长度设置了限制,因此订阅大量用户(通常超过 1000 个用户)的应用程序可能会收到来自 Lync Server 2013 的错误响应。

有谁知道这对于 Skype for Business 2015/2019 是否仍然适用,或者在哪里可以找到当前文档?

同一个文档进一步指出,对于大量订阅,建议限制我们订阅的类别。我们只对存在状态感兴趣,所以这对我们来说是一个很好的解决方法。但是我找不到太多关于这有什么区别的信息,比如如果我们只订阅存在状态,我们可以拥有 2 倍、5 倍或 100 倍的订阅数量吗?

四处搜索我发现this post 似乎是说如果我们创建数百个批次,我们可以订阅更多用户。那么上述 1000 个用户的限制是否适用于每个 BeginSubscription() 调用?

非常感谢!

【问题讨论】:

    标签: skype-for-business skypedeveloper ucma


    【解决方案1】:

    听起来您正在阅读 UCMA 4 (Lync 2013) 文档。 有 UCMA 5 (SfB 2015) documentation 但没有真正的区别。 UCMA 6 (SfB 2019) 可用,但没有任何文档。

    根据个人经验,您可以使用任何 UCMA 版本来完成工作。细节没有改变。

    如果您想订阅 SfB 在线帐户,则必须在 SfB 2015 上使用 UCMA 5 或在 SfB 2019 上使用 UCMA 6,因为 SfB 2015 / 2019 上的 UCMA 4 不适用于 SfB 在线帐户。这是我发现的唯一问题。

    我已经订阅了 100 多个,我认为我们的一些客户使用批量订阅达到了 1k 左右。我使用 100 的批量大小,这对我来说没问题。

    在您自己测试之前,您不会知道如何使用您测试的批量大小执行它是否足够慢或足够快。

    在 15k 大关时,需要处理大量订阅。由于额外的消息/订阅轮询正在进行,这可能会开始在该订阅级别上给 SfB 系统带来不必要的开销。您可能需要考虑在应用程序/机器之间拆分订阅以平衡工作负载。

    如果您发现它运行得不是很好,您可能需要考虑从 UCMA 应用程序切换到在 FE 机器上运行的服务器应用程序(sip 代理)应用程序并嗅探 sip 流量以查看存在更改流量他们发生了。它需要更多的工作,但不会产生像 UCMA 应用程序那样多的开销。

    【讨论】:

    • 感谢您的评论,谢恩!通过 Server App,您是指将相关消息转发到应用程序的 MSPL 脚本吗?该级别是否提供用户在线状态更新?
    • 是的,基于 MSPL 的应用程序。是的,存在是通过 SIP 消息完成的,请参阅 docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sip/…
    猜你喜欢
    • 1970-01-01
    • 2014-08-04
    • 2011-02-01
    • 1970-01-01
    • 2015-09-04
    • 1970-01-01
    • 2019-08-01
    • 1970-01-01
    相关资源
    最近更新 更多