黑森 vs Tibco RV

发布于 2024-08-30 05:39:15 字数 74 浏览 5 评论 0原文

我希望在 Java 应用程序的性能方面比较 Tibco rv 和 Hessian。

任何让我开始的指示都很感激。谢谢。

I'm looking to contrast Tibco rv and Hessian in terms of performance - for a Java application.

Any pointer to get me started appreciated. thanks.

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

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

发布评论

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

评论(2

生来就爱笑 2024-09-06 05:39:15

取决于你所说的“性能”是什么意思。

我有很多 Tibco 经验,但没有 Hessian,所以我只能评论 RV 方面的事情。

RV 非常有效(我的意思是非常有效)使用网络和服务器资源,它广泛使用 TCP/IP 广播以避免向 n 个客户端发送相同的消息。此外,消息不会直接发送到客户端,而是发送到计算机上的端点,然后该端点将消息转发到登录到该计算机的任何客户端。

另外,核心产品已经有好几年的历史了,被设计为在 1995 年左右被认为相当普通的硬件上运行(单处理器 200 mhz 256MB 内存 SparcStation 是服务器端的典型!)所以在今天的硬件上它可以处理巨大的容量位于“顶部”列表底部的两个消息。

有一些缺点(与 Webshpere MQ 相比);事务支持是有限的,不符合 MQ 或数据库标准,而且没有内置的有保证的交付或“死信”处理,尽管在应用程序中围绕此进行编码相当容易。

Depends what you mean by "performance".

I have had a lot of Tibco experience but no Hessian so I can only comment of the RV side of things.

RV makes very efficient (and I mean VERY efficient) use of network and server resouces, it makes extensive use of TCP/IP broadcast to avoid sending the same message to n clients. Additionally messages are not sent directly to clients but to an end point on machine which then forwards the message to any clients logged on to the machine.

Additionaly the core product is several years old and was designed to run on what was considered quite modest harware circa 1995 ( single processer 200 mhz 256MB memory SparcStation would have been typical for the server end! ) so on todays hardware it can handle a vast volume of messages while sitting twoards the bottom of the "top" list.

There are a couple of downsides (compared with say Webshpere MQ); transactional support is limited and not up to MQ or database standards plus there is no built in guarenteed delivery or "dead letter" processing, although its fairly easy to code around this in an application.

草莓味的萝莉 2024-09-06 05:39:15

我要开始的地方是:

首先检查消息传递服务的底层结构。

TIBCO Rendezvous 看起来像是直接构建在 TCP/IP 之上,并且具有广泛的跨平台支持。

Hessian Messaging 似乎是之上的一层代码标准 RPC。这可能使其更简单、更容易维护,但也意味着它完全依赖于 RPC 实现。

另一种方法是比较有多少人使用它以及它的测试情况。

最后,一件好事是看看 TIBCO 和 Hessian 是否提供了演示版本,您可以在自己的环境中实际进行压力测试,以便最好地了解它们在您独特的设置中的性能。

The places I would go to start would be:

First examine the underlying structure of the messaging service.

TIBCO Rendezvous looks like it's built directly on top of TCP/IP and has broad cross platform support.

Hessian Messaging appears to be a layer of code on top of standard RPC. This makes it simpler and easier to maintain maybe, but also means that it's completely dependent on the RPC implementation.

Another approach would be to compare how many people use it and how well tested it is.

Finally, a good thing to do would be to see if TIBCO and Hessian provide demo versions that you can actually stress test in your own environment, to get the best idea of the performance of either in your unique setting.

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