后端请求数据计算量过大，导致给用户的返回结果过于漫长【一次调优的过程】

【项目背景描述】

有一个表格，描述的是Snapshot-1和Snapshot-2之间的对比，数据对比的结果是由后端算出来的，前端只要负责渲染就可以。
后端返回的数据本质是一个“森林”，每棵“树”都是三层，分别是：type/ class name/ object name。由于每棵树的计算量比较大，孩子节点也比较多，所以在前端渲染的时候，使用懒加载做了优化，即只有当用户展开某层的时候才会call到后端请求数据。所以，页面第一次渲染的时候，显示的是森林里所有树的第一层。
除了页面的数据展示，Diff表格还支持csv download，由于csv需要拿到全量的对比数据，也就是整片森林，所以当用户点击CSV下载的时候，会先call后端拿到全量数据，再csv format，最后输出。

【出现问题】
有用户反馈说：CSV下载等了好久都在loading，问怎么回事？

【排查过程】
1.前述环境

• 我们有本地开发环境（对应自己本地的数据库，可以操作后端代码and前端代码）
• 用户出现问题的是prod环境（本地的前端是无法call到prod环境的DB的）

2.找到瓶颈

• 打开用户的报告，确实数据量很大，点击csv download，感觉下载一个diff文件，大概需要30s左右的时间。也就是说代码逻辑没有问题，就是慢。
• 打开控制台，看数据返回时间。其实时间不是很长，只有7s，因此，时间的瓶颈不在这里。

• 接下来，就是看api callback里面的处理逻辑有什么可以优化的地方了。但是，如何拿到用户的数据呢？由于本地开发环境是没有办法连上prod的数据库的。
• 【解决方案】：可以在开发者模式下，拿到api返回的数据，并将其保存成json，在前端代码里import进来进行处理。
• 但是，由于返回的结果过于庞大，response无法load，“复制粘贴”的计划失败。

• 【解决方案】：右击url，找到Copy as cURL，并在命令的结尾加上“>> 1.txt”，可以将response结果直接输出到文件，而不是命令行，方便复制。

• 万事俱备，开始查看瓶颈。在csv format中的每个函数后面，console.log一个时间戳，便于查看究竟哪里比较耗时。最终发现，sort函数占用了大量的时间，因为有2层for循环。重新查看代码，其实call回来的api在后端处理的时候，其实已经是排好顺序的，因此，前端无需“多此一举”。
• 综上所述，删除前端sort函数即可。（省略后续测试步骤......）

【知识点回顾】

curl 是常用的命令行工具，用来请求 Web 服务器。它的名字就是客户端（client）的 URL 工具的意思。有很多不同的命令行参数，方便开发者在cmd里请求api。