在大型网站上平衡服务器端和客户端代码

发布于 2024-09-11 07:01:11 字数 647 浏览 8 评论 0原文

假设我正在为 Facebook(我不是)或其他一些流量较大的网站编程。

我们的一般布局是:

  1. 所有 CSS 都在外部文件中
  2. 99% 的 JS 在外部文件中
  3. 网站的主干 HTML 由 PHP/MySQL 后端生成。
  4. JS 函数生成经常更改的部分的 DOM。
  5. 我们的服务器有一个就地 API,它返回 JSON 对象,这些对象被馈送到我们的 DOM 构建器(JS 函数),该构建器采用一个 JSON 对象数组,比如说朋友列表,然后生成用于显示朋友列表的所有 html,或事件等。

问题

  1. 这合理吗?
  2. 正如我所提到的,使用专用的 JS 函数来构建 DOM 是常见做法吗?
  3. 这是可扩展的吗? JS 太慢了吗? (顺便说一句,我们几乎只使用 JQuery)

我知道它极大地降低了带宽和服务器负载,因为服务器不再迭代好友列表(它也通过 MySQL 查询该列表)并生成所有 HTML,而是进行查询并返回一个小的 JSON 对象。这对我来说似乎没问题,但我想要第二/第三/第四/...意见。

多谢!

如果我遗漏了任何重要信息,请告诉我。

Let's suppose I am programming Facebook (which i'm not), or some other site that involves heavy traffic.

Our general Layout is:

  1. All CSS is in external files
  2. 99% of JS is in external files
  3. The back bone of the websites HTML is generated by a PHP/MySQL backend.
  4. JS functions to generate the DOM of parts that commonly change.
  5. Our server has an inplace API that returns JSON objects that are fed to our DOM builders (JS functions), which take an JSON object array of lets say, a list of friends, then generated ALL the html used for displaying a list of friends, or events, etc.

Question

  1. Is this reasonable?
  2. Is it common practice to have dedicated JS functions to build the DOM as I have mentioned?
  3. Is this scalable? Is JS too slow? (btw, we use JQuery almost exclusively)

I know that it tremendously lowers bandwidth and server load, as the server is no longer iterating through a list of friends (of which it also queried for via MySQL) and generating all the HTML, but instead making a query and returning a small JSON object. which seems ok to me, but I would like a 2nd/3rd/4th/... opinion.

Thanks alot!

Let me know if I am missing any critical information.

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

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

发布评论

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

评论(3

风透绣罗衣 2024-09-18 07:01:11

我认为你的布局非常好,但我仍然建议你阅读 YAHOO!加快网站速度的最佳实践。它比我更好地总结了它(在我看来非常好读)。

我认为 facebook 为了实现其规模而做的三件最重要的事情:

  1. 缓存 => Memcached。这一点真的很重要。您应该记住,与 MEMORY 相比,执行磁盘 IO 速度较慢(根据我的书,磁盘 5ms / 内存 40-80ns)。 Facebook 几乎所有的活跃数据都在内存中。 这些旧幻灯片表示它们的内存超过 5TB 。现在这将会变得更多!
  2. 嘻哈音乐 => https://github.com/facebook/hiphop-php/wiki/
  3. 离线处理 =>使用消息队列,例如 redisbeanstalkdgearman 仅举几例。

其他一些有趣的链接:

I think your layout is pretty good, but I would still advice you to read YAHOO! Best Practices for Speeding Up Your Web Site. It summarizes it better(very good read in my opinion) than I could do.

I think the three most important things facebook does to achieve it's scale:

  1. CACHING => Memcached. This one is really important. You should remember that doing disk IO is slow compared to MEMORY(disk 5ms / memory 40-80ns according to my book). Facebook has almost all the active data in memory. These old slides say they have more than 5TB in memory. This is going to be way more by now!
  2. HIPHOP => https://github.com/facebook/hiphop-php/wiki/
  3. OFFLINE PROCESSING => Use a message queue like for example redis, beanstalkd, gearman just to name a few.

Some other interesting links:

农村范ル 2024-09-18 07:01:11

鉴于 JS 引擎正在不断开发以提高性能,我认为这是一个非常好的设计。我们将越来越频繁地将其视为 HTML5 和 HTML5。 Co 越来越受欢迎。

Given that JS engines are being constantly developed towards improved performance, I think it's a pretty good design. We will be seeing it more and more often as HTML5 & Co gains popularity.

第几種人 2024-09-18 07:01:11

这就是我正在采取的方法。我对此很满意。 JS当然不会太慢。您需要一个好的 JS 模板系统。 Trimpath JS 模板是我尝试过的模板中我最喜欢的。

This is the approach I'm moving towards. I'm pretty happy with it. JS is certainly not too slow. You'll want a good JS templating system. Trimpath JS Templates is my favorite of those I've tried.

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