大应用程序 大用户群 低带宽

发布于 2024-09-15 05:30:52 字数 236 浏览 4 评论 0原文

我的网页上有一个相当大(4MB)的小程序,供分散在 WAN 上的数千名用户使用。这些用户的带宽范围从微不足道的 128Kbps 到 10Mbps。

当有新版本的小程序可用时,就会出现此问题;它由所有用户浏览器自动下载,有效地阻塞了网络。

他们真的很讨厌这里的“发布日”早上:)

有什么策略可以解决这个问题吗?

编辑:我只能从一对服务器集中提供这个小程序。我无法对托管或网络基础设施进行任何修改。

I've got an applet that is rather large (4MB) on a web page used by a few thousand users scattered across a WAN. Bandwidths to these users range from a paltry 128Kbps to 10Mbps.

The problem occurs when a new version of the applet is made available; it is downloaded automatically by all the users browsers effectively chocking the network.

They really hate 'release day' morning around here :)

Is there any strategy to work around this problem?

Edit: I can only serve this applet centrally from one pair of servers. I cannot make any modifications to the hosting or network infrastructure.

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

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

发布评论

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

评论(3

吻安 2024-09-22 05:30:52

以下是一些想法:

  • 将您的用户社区分为 N 个相等的组,并为每个组提供不同的小程序 URL。然后错开更新每个组的小程序副本的时间。

  • 将小程序放在经过调整以谎报小程序修改日期的服务器上,并使用它来(粗略地)限制浏览器获取更新后的小程序的速率。

  • 将小程序推送到大量用户的本地网络上的位置。让中央服务器发出 HTTP 重定向,以便每个浏览器从“关闭”位置获取小程序。

  • 部署缓存 HTTP 代理和 本地网络上的 autoproxy 文件,并阻止对小程序的直接访问,强制用户通过代理获取小程序。

最后一个选择可能是最好的。

Here are some ideas:

  • Divide your user community into N equal groups, and provide a different applet URL for each for group. Then stagger the times at which each group's copy of the applet is updated.

  • Put the applet on a server that has been tweaked to lie about the applet's modification date, and use this to (crudely) throttle the rate at which browsers fetch the updated applet.

  • Push the applet to locations on the local networks of large groups of users. Have the central server issue HTTP redirects so that each browser picks up the applet from a "close" location.

  • Deploy caching HTTP proxies & autoproxy files on the local networks, and block direct access to the applet forcing the users to get the applet via the proxies.

The last option is probably the best.

若相惜即相离 2024-09-22 05:30:52

除了 Stephen C 提到的之外,我还想添加您应该考虑的另一个策略。

  • 考虑将您的小程序代码库分解为不同的模块(存档)。
  • 这些模块会更新,而不是整个 4MB 小程序。您可以使用特殊的类加载器来检查给定模块的新版本是否可用。
  • 对于补丁来说,有一个单独的“补丁”存档,该存档在任何其他存档之前加载,以便从补丁存档加载任何更新的类,而不是从旧的已下载存档中加载。
  • java web start 已经做了一些这些事情可以避免整个更新。您可以查看链接(开发人员文档)以获取一些指导。

Apart from what Stephen C mentions, I'd like to add another strategy that you should consider.

  • Consider breaking your applet codebase into different modules (archives)
  • These modules are updated instead of the entire 4MB applet. You can have a special classloader that checks if a new version of a given module is available.
  • For patches have a separate "patch" archive that loads before any other archives so that any updated classes are loaded from the patch archive instead of the older already downloaded archives.
  • The java web start already does some of these things to avoid entire updates. You can take a look the link (developer documentation) for a few pointers.
韵柒 2024-09-22 05:30:52

如果你可以在目录中放置一个 .htaccess ,你可以添加 expiresByType ,这样客户端就不会每次都询问服务器。

你看过pack200吗?和(pack200 + .htaccess)
你看过索引 Jar 吗?

安东尼

If you can put a .htaccess in the directory you can add expiresByType so that the client doesn't ask the server everytime.

Have you looked at pack200? and (pack200 + .htaccess)
Have you looked at indexed Jar?

Anthony

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