【问题标题】:Optimizing performance of data visualisation web application优化数据可视化 Web 应用程序的性能
【发布时间】:2012-12-10 06:43:18
【问题描述】:

我正在重写一个 3 年前编写的数据可视化网络工具。从那时起,浏览器的 JavaScript 引擎变得更快了,所以我想把部分工作从服务器转移到客户端。

在页面上,数据在表格和地图(或图表)中可视化,它使用相同的数据,但方式不同,因此准备显示数据的两种算法是不同的。

在用户与数据下拉选择器(3 主 + 2 子取决于 3 主)的每次交互之前,发送了 3 个 ajax 请求,php 完成所有工作并仅发送回必要的数据(在 html 中用于表/xml 用于图表)非常小的响应,没有性能问题,并且 javascript 正在附加响应并且所做的只是追逐更改事件。

所以性能还可以,但是每次更改标准时,用户都必须等待 ajax 响应:/

现在我的想法是在一个 ajax 请求中发回一个 json 对象,仅在主要 3 个标准组合的每次更改时,然后让 javascript 填充表格中的数据和 ajaxsuccess 上的图表/地图,然后再进行更改2 个子标准中的一个。

我犹豫的是服务器发送的json的结构,payload的平衡。

确实,如果只需要一种算法来创建所需的 json 结构来显示原始数据中的数据,我会让 php 将数据处理到该对象中,以便 javascript 无需任何额外处理即可处理它;但有 2 个。

所以

  • 如果我让 php 处理数据以创建 2 个对象(一个用于表/一个用于图表),我将 json 响应的大小加倍并增加客户端的内存使用量;我不喜欢这种方法,因为这两个对象包含相同的数据,只是结构不同且冗余是邪恶的,不是吗?

  • 1234563 ajaxsuccess 所以他们准备好以防这个子标准发生变化?)- 对于使用旧浏览器/小内存的用户,我有点担心......

(未处理的原始 json 对象,根据标准在 3kb 和 12kb 之间变化,在 500 和 2000 条记录之间)

我没有找到最好的方法...

那么对于这个单一的原始数据到多个结构化对象的工作,你会让 php(增加响应大小并发送冗余数据)或 javascript(增加 javascript 有效负载)处理原始数据吗?

非常感谢您的意见

【问题讨论】:

  • 我们在这里讨论了多少数据?除非您在谈论数万条记录,否则即使是较旧的客户端机器/浏览器也应该能够处理这个问题(如果您要处理这么多记录,那么您可能会遇到比您所描述的更大的问题)。只需将原始数据传递一次,让客户端操心渲染。
  • 对于 3 个主要标准的每个组合,原始数据是 36 个州 *(2 到 10 个不同的人群)*(4 到 6 个不同的结果类型)-> 300 到 2000 条记录( stateid、resulttypeid、groupid、百分比)
  • 补充一下,3 个主要标准有 60 种不同的组合(所以在 db 中总共有大约 100 000 条记录,因此我选择从服务器请求数据不超过这个级别);次要问题是:在用户请求另一个组合的数据之后将以前的原始数据保留在客户端内存中是否明智(加:如果返回以前看到的数据,则不会再次发送 ajax 请求;减:如果查看多个组合,结束客户端内存中有数十个对象,每个对象平均有数千条原始记录)
  • 回答我自己的附属问题,我想我会缓存 http 请求而不是将响应保留在 javascript 范围内

标签: php javascript ajax json performance


【解决方案1】:

我找到了合适的解决方案,所以我会回答我自己的问题。

我听从了@Daverandom 的建议:

  • PHP 发送原始数据(以及几个取决于主要标准组合的参数)

  • JavaScript 处理原始数据并将其呈现在页面中

  • 如果子标准发生变化,JavaScript 会重新处理原始数据,因为在测试时循环过程似乎非常快并且不会冻结浏览器,因此无需将结构化对象保留在范围

  • 激进的缓存标头与 JSON AJAX 响应一起发送(这些数据永远不会改变 - 每年只会添加新记录),以防用户重新查阅已经查阅过的数据:因此原始数据不会保留在JavaScript 范围(如果没有显示)

  • 最重要的是,由 php 回显的 JSON 字符串会缓存在服务器上(因为这些数据永远不会改变),因此这减少了数据库查询并缩短了响应时间

最终的代码整洁,易于维护,应用程序运行完美。

感谢@Daverandom 的帮助。

【讨论】:

  • 我也做过类似的事情。我倾向于给客户一个巨大的数据负载并让他们处理它。开销和等待不必要的 http 响应通常很糟糕。
  • 什么是巨大的?我猜我是老派,因为这对我来说是一件大事,将以前的服务器工作的一部分转移到客户端!
  • 我想我已经增加了大约 100k pre gzip - 我会更多。我这样做是为了提高交互速度。带有大量变化标准的数据可视化是一个很好的用例。对数据进行一般过滤以查找某些记录也是如此——当搜索结果接近即时时,这真的很好,因为所有数据都在浏览器内存中,您永远不需要访问网络。我什至在收到数据后对数据建立了微薄的索引,这样我就不需要对这么多记录进行巨大的线性循环。
  • 有趣的谢谢;在这种情况下,所有数据记录将达到大约 100000 条(每年 + 20000 条),在 gzip 之前可能有 400 或 500kb,所以我猜想这非常大!虽然可能会尝试索引过程,但这是有道理的......总是很少(或太多?)害怕压倒客户端内存
  • 记录在gzip之后是400kb,而不是之前&现在这个应用程序在每次请求时都会收到80到170kb的pregzip;效果很好
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-12-30
  • 1970-01-01
  • 2021-10-16
  • 2023-04-10
相关资源
最近更新 更多