后台数据量很大,请求的数据接口多，造成前台页面生成的时候很慢，请求一下有什么好的优化方法

[qq_43401202]

所有数据在一个页面上显示，页面类似货币走势图

[qq_3524932331]

有分页的话 做下分页

[wilson1966]

如果是同一时间的大量请求,可设检查码,请用户输入数字来查验(判断非机器人操作),减少同一时间的大量请求。

[HQChart]

1. 提高api的响应速度，如果请求多可以加负载均衡， 后面都配几台api 服务器。
2. 减少api的json格式冗余度压缩数据量， 像你的货币走势图应该是有分钟数据， 千万不要用key,value的json来存放， 用单数组的方式来存放一个字段的数据 如: time:[1001, 1002, 1003, .....], open:[10.1,10.2,10.1, ....]
3. 走势图中的指标在前端计算， 不要放在后台计算， 后台只返回基础的 开高低收事件等数据。
4. 数据更新， 千万不要又是把历史数据在下一遍， 只下载当天的数据，在前端拼接到你之前已经下载好的数据后面。

https://opensource.zealink.com/hqweb/demo/phone.html 这个我做的K线图 大概取了4年的数据吧。 你可以查考下。源码在https://github.com/jones2000/HQChart

[qq_31227035]

参考bootstrap 的分页，根本不用自己写

[田小瘦]

前台数据是如何渲染的? 可以考虑异步分页加载

[Gemini_Kanon]

负载均衡，集群减少项目压力

[LKratos_大师兄]

楼主你怎么解决的？我也遇到这个问题，返回300w+的数据，近70兆，前端经常崩溃。真不知道那些回复说搞分页的，回复都不带脑子，趋势图怎么分页，分页这么基础的东西，谁都会想到的。最低限度，多维度查询的一天的一个走势图，无法预先加载数据。如果要搞预处理，把所有维度的条件，组合起来，这样每天查询上一天的数据，但是2的n次方种维度的数据存起来，真的行不通

[_念_]

引用 8 楼 LKratos_大师兄 的回复:

楼主你怎么解决的？我也遇到这个问题，返回300w+的数据，近70兆，前端经常崩溃。真不知道那些回复说搞分页的，回复都不带脑子，趋势图怎么分页，分页这么基础的东西，谁都会想到的。最低限度，多维度查询的一天的一个走势图，无法预先加载数据。如果要搞预处理，把所有维度的条件，组合起来，这样每天查询上一天的数据，但是2的n次方种维度的数据存起来，真的行不通

都这么大了，直接生成一个json或者js文件呗。 或者考虑拆分一下，按小时去查，然后前端自己拼接数据，修改交互逻辑，不要一次显示全部。如果存在多条线，还可以每次单查一条线的。说到底，就是看数据能不能拆分。。。

[hookee]

不是事实的数据用Cache

[LKratos_大师兄]

引用 13 楼 nian_cj 的回复:

[quote=引用 12 楼 LKratos_大师兄 的回复:] [quote=引用 10 楼 nian_cj 的回复:] [quote=引用 8 楼 LKratos_大师兄 的回复:] 楼主你怎么解决的？我也遇到这个问题，返回300w+的数据，近70兆，前端经常崩溃。真不知道那些回复说搞分页的，回复都不带脑子，趋势图怎么分页，分页这么基础的东西，谁都会想到的。最低限度，多维度查询的一天的一个走势图，无法预先加载数据。如果要搞预处理，把所有维度的条件，组合起来，这样每天查询上一天的数据，但是2的n次方种维度的数据存起来，真的行不通

都这么大了，直接生成一个json或者js文件呗。 或者考虑拆分一下，按小时去查，然后前端自己拼接数据，修改交互逻辑，不要一次显示全部。如果存在多条线，还可以每次单查一条线的。说到底，就是看数据能不能拆分。。。[/quote]老铁，你再想一下，我就要看一天的趋势图，这是最低的要求，一天24小时，你存文件的话，24小时范围内的时间组合查询是多少？还有你全部组合查询都生成了，客户端一定需要到这些全部数据么？如果不显示全部？又怎么叫一天的走势图呢？好好的深入想想[/quote] 你没有懂我的意思，并不是说不显示一天的，而是做成分批加载，先加载一部分让用户看着，然后逐步加载后面的，不至于让页面空白很久，当然具体还是要看页面设计和交互要求，这是不得不取舍的。至于说文件，是为了让接口不至于崩，毕竟接口返回这么大的数据很不稳定，而如果你返回一个文件地址，然后再去下载文件，至少接口本身不会出问题。不会长时间的挂在那里。[/quote] 你说的这个思路，之前我和前端看过，echars类似全球的坐标渲染，看着他们的坐标是存成静态的数据，分批去加载这部分静态数据...这个思路没毛病。我不是很清楚我们的数据是动态的，多维度的实时查询，如何分批？一个接口一个响应这个思路应该没问题吧，现在接口要求1秒内响应，数据分批分块，感觉原理就是分页差不多吧，望赐教。。。目前我做的是数据亚索，但是感觉也不是好的解决方案，要是数据量再增，本身数据量太大，再压缩也还是不能快速响应的需求

[码鲁鲁]

等到[b][/b][color=#FF9900][/color]

[LKratos_大师兄]

引用 10 楼 nian_cj 的回复:

[quote=引用 8 楼 LKratos_大师兄 的回复:] 楼主你怎么解决的？我也遇到这个问题，返回300w+的数据，近70兆，前端经常崩溃。真不知道那些回复说搞分页的，回复都不带脑子，趋势图怎么分页，分页这么基础的东西，谁都会想到的。最低限度，多维度查询的一天的一个走势图，无法预先加载数据。如果要搞预处理，把所有维度的条件，组合起来，这样每天查询上一天的数据，但是2的n次方种维度的数据存起来，真的行不通

都这么大了，直接生成一个json或者js文件呗。 或者考虑拆分一下，按小时去查，然后前端自己拼接数据，修改交互逻辑，不要一次显示全部。如果存在多条线，还可以每次单查一条线的。说到底，就是看数据能不能拆分。。。[/quote老铁，你再想一下，我就要看一天的趋势图，这是最低的要求，一天24小时，你存文件的话，24小时范围内的时间组合查询是多少？还有你全部组合查询都生成了，客户端一定需要到这些全部数据么？如果不显示全部？又怎么叫一天的走势图呢？好好的深入想想

[_念_]

引用 12 楼 LKratos_大师兄 的回复:

[quote=引用 10 楼 nian_cj 的回复:] [quote=引用 8 楼 LKratos_大师兄 的回复:] 楼主你怎么解决的？我也遇到这个问题，返回300w+的数据，近70兆，前端经常崩溃。真不知道那些回复说搞分页的，回复都不带脑子，趋势图怎么分页，分页这么基础的东西，谁都会想到的。最低限度，多维度查询的一天的一个走势图，无法预先加载数据。如果要搞预处理，把所有维度的条件，组合起来，这样每天查询上一天的数据，但是2的n次方种维度的数据存起来，真的行不通

都这么大了，直接生成一个json或者js文件呗。 或者考虑拆分一下，按小时去查，然后前端自己拼接数据，修改交互逻辑，不要一次显示全部。如果存在多条线，还可以每次单查一条线的。说到底，就是看数据能不能拆分。。。[/quote]老铁，你再想一下，我就要看一天的趋势图，这是最低的要求，一天24小时，你存文件的话，24小时范围内的时间组合查询是多少？还有你全部组合查询都生成了，客户端一定需要到这些全部数据么？如果不显示全部？又怎么叫一天的走势图呢？好好的深入想想[/quote] 你没有懂我的意思，并不是说不显示一天的，而是做成分批加载，先加载一部分让用户看着，然后逐步加载后面的，不至于让页面空白很久，当然具体还是要看页面设计和交互要求，这是不得不取舍的。至于说文件，是为了让接口不至于崩，毕竟接口返回这么大的数据很不稳定，而如果你返回一个文件地址，然后再去下载文件，至少接口本身不会出问题。不会长时间的挂在那里。

[_念_]

引用 14 楼 LKratos_大师兄 的回复:

[quote=引用 13 楼 nian_cj 的回复:] [quote=引用 12 楼 LKratos_大师兄 的回复:] [quote=引用 10 楼 nian_cj 的回复:] [quote=引用 8 楼 LKratos_大师兄 的回复:] 楼主你怎么解决的？我也遇到这个问题，返回300w+的数据，近70兆，前端经常崩溃。真不知道那些回复说搞分页的，回复都不带脑子，趋势图怎么分页，分页这么基础的东西，谁都会想到的。最低限度，多维度查询的一天的一个走势图，无法预先加载数据。如果要搞预处理，把所有维度的条件，组合起来，这样每天查询上一天的数据，但是2的n次方种维度的数据存起来，真的行不通

都这么大了，直接生成一个json或者js文件呗。 或者考虑拆分一下，按小时去查，然后前端自己拼接数据，修改交互逻辑，不要一次显示全部。如果存在多条线，还可以每次单查一条线的。说到底，就是看数据能不能拆分。。。[/quote]老铁，你再想一下，我就要看一天的趋势图，这是最低的要求，一天24小时，你存文件的话，24小时范围内的时间组合查询是多少？还有你全部组合查询都生成了，客户端一定需要到这些全部数据么？如果不显示全部？又怎么叫一天的走势图呢？好好的深入想想[/quote] 你没有懂我的意思，并不是说不显示一天的，而是做成分批加载，先加载一部分让用户看着，然后逐步加载后面的，不至于让页面空白很久，当然具体还是要看页面设计和交互要求，这是不得不取舍的。至于说文件，是为了让接口不至于崩，毕竟接口返回这么大的数据很不稳定，而如果你返回一个文件地址，然后再去下载文件，至少接口本身不会出问题。不会长时间的挂在那里。[/quote] 你说的这个思路，之前我和前端看过，echars类似全球的坐标渲染，看着他们的坐标是存成静态的数据，分批去加载这部分静态数据...这个思路没毛病。我不是很清楚我们的数据是动态的，多维度的实时查询，如何分批？一个接口一个响应这个思路应该没问题吧，现在接口要求1秒内响应，数据分批分块，感觉原理就是分页差不多吧，望赐教。。。目前我做的是数据亚索，但是感觉也不是好的解决方案，要是数据量再增，本身数据量太大，再压缩也还是不能快速响应的需求[/quote] 我在业务中也没有遇到过这么大数据的问题，只能做一些假设和意见，提供大家讨论。 第一种静态文件的方式，我觉得不管你是什么数据展示，都会有维度的概念，不管是坐标系，还是地图，是否可以考虑根据维度去拆分。拆分成多个过后，更新的时候，只更新对应的几个文件，前端只获取更新过的那几个，如果是所有都涉及到，这种方式就不太好了。 第二个数据分块，其实就是分页，这种其实和第一个没什么区别，只是前后端交互的形式上不同，这种对数据变动可能比较好处理一点，可以想办法使用增量更新，旧的已经加载的数据和字段，不要再返回，只返回变动过的字段，由前端进行合并。在第一次加载的时候，是否考虑减少字段，一些不必要的或者关注点不高的可以数据，不要一次性加载出来，拆分成几个接口，每个接口返回不同的数据，然后由前端去合并，第一个接口尽量的精简，保证用户能第一时间看到有东西，然后再去拿一些次要的数据合并。

[Spirit书生]

有个问题，就是比如高德地图，视图是自动缩放到当前位置，需要在地图上打标记，但是接口数据非常多加载慢，如果说分批加载的话，不能够保证先加载的数据一定在可视区范围内，对于用户来说还是看不到数据，咋办？很头疼

[大然然]

我感觉楼主问的问题是他一个页面里有N 个业务模块，（就当是N个div），每个Div里加载的东西不一样，后台接口也不一样，造成接口很多，进入这个页面后要调用很多接口，而且每个接口返回的数据很大， 不知道我理解的对不 ？