Java EE：迎合Web 2.0 - 编程入门网

高延迟和低带宽客户机

以手机和其他限制带宽的客户机为目标的应用程序日趋流行。即使服务器可以为特定客户机提供快速服务，客户机仍然不能迅速地使用数据，这要归咎于其低带宽连接和设备本身的物理限制。虽然客户机是通过低吞吐量连接加载数据，服务器在占用 servlet 线程时仍然未被充分利用或处于等待状态。随着越来越多的移动设备使用网络服务以及无线频段的充分利用，这类客户机的吞吐量和延迟性将逐渐减少，除非开发出一种通信机制来提供更好的可伸缩性。

与典型的 Web 1.0 应用程序相比，这些因素往往会生成更多的服务器通信量和请求数。在高负载期间，这种通信量难于控制（然而，Ajax 也提供了更多的机会对通信量进行优化；与支持相同用例的简单 Web 应用程序相比，Ajax 生成的通信量通常更少）。

更多内容

Web 2.0 的特征就是比上一代 Web 应用程序拥有更大量的内容和更大的规模。

在 Web 1.0 世界中，内容通常只有经过业务实体的明确允许后才被发布到公司网站。企业需要控制所显示的文本的每个字符。因此，如果计划发布的内容超出了框架的大小限制，则要对内容进行优化或将其分成几个较小的部分。

Web 2.0 站点的一个特性就是不会限制内容的大小或创建。大部分 Web 2.0 内容由用户和社区生成。组织和企业仅仅提供工具实现内容创建和发布。由于使用了大量图像、音频和视频，内容的大小也相应增加。

Java EE：迎合Web 2.0(3)

持久连接

建立客户机到服务器的新连接会耗费很多时间。如果某些交互在预期之中，则建立一次客户机/服务器通信，然后重复使用该连接，这样做会获得更高的效率。持久连接对于发送客户机通知也很有用。但是 Web 2.0 应用程序的客户机通常位于防火墙之后，一般很难或不能直接建立服务器到客户机的连接。Ajax 应用程序需要发送请求轮询特定事件。要减少轮询请求的数量，一些 Ajax 应用程序使用 Comet 模式：该服务器被设计为在某个事件发生以前保持等待状态，然后发送应答，同时保持连接打开。

对等消息传递协议，如 SIP、BEEP 和 XMPP，逐渐使用持久连接。流式直播视频也从持久连接中获益良多。

更容易发生 Slashdot 效应

Web 2.0 应用程序拥有大量的访客，这一点使某些站点更容易发生 “Slashdot 效应” — 如果某个流行的 blog、新闻站点或社会型网站提及某个站点时，该站点的通信量负载会猛增。所有 Web 站点都应该准备好处理比普通负载高几个数量级的通信量。这种情况下更重要的一点是，站点在如此高的负载下不会发生崩溃。

延迟问题

与操作吞吐量相比，操作延迟对 Java EE 应用程序的影响更大。即使应用程序使用的服务可以处理大量操作，延迟仍然保持不变或者进一步恶化。目前的 Java EE API 还无法很好地处理这一情况，因为这种情况违背了这些 API 设计中暗含的延迟假设。

在使用同步 API 时，为论坛或 blog 中的大型页面提供服务将开启一个处理线程。如果每个页面需要一秒钟的服务时间（例如 LiveJournal 这类应用程序，包含很多较大的页面），并且线程池包含 100 个线程，那么一秒钟的时间内无法为超过 100 个页面提供服务 — 这种性能无法接受。增加线程池中的线程数量收效甚微，因为当线程池中的线程数量增加时，应用程序-服务器性能将开始降低。

Java EE 架构无法利用 SIP、BEEP 和 XMPP 这样的消息传递协议，因为 Java EE 的同步 API 持续使用单个线程。由于应用服务器使用有限的线程池，持续使用一个线程将使应用服务器在使用这些协议发送和接收消息时无法处理其他请求。同样要注意，使用这些协议发送的消息可长可短（

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!