如何让 java servlet 更高效地输出大量数据？
我有一个 java servlet，可以从 JSON 对象中提取信息。 JSON 对象由索引数据（弹性搜索）的搜索结果组成。如果结果很少，这种方法效果很好，但是当结果很多时，速度会显着减慢。如果结果数量超过 50,000 个，浏览器有时会崩溃。我该怎么做才能更有效地浏览大量结果，以免浏览器崩溃。
这是我的代码：
//Result Count
int i = 1;
for (SearchHit sh : response.getHits().hits()) {
out.println("Result " + i + " <br>");
out.println(" " + sh.getSource().get("@message").toString() + " <br>");
HashMap hm = (HashMap) sh.getSource().get("@fields");
Iterator it = hm.entrySet().iterator();
while (it.hasNext()) {
Map.Entry pairs = (Map.Entry)it.next();
out.println(" " + pairs.getKey() + " = " + pairs.getValue().toString().replace("[", "").replace("]", "") + " <br>");
}
i++;
out.println(" <br>");
}
I have a java servlet that pulls information out of a JSON object. The JSON object consists of search results from indexed data (elastic search). This works well if there are few results, but when there are many it significantly slows down. If the number of results is over 50,000 this will sometime crash the browser. What could I do to make going through a large number of results more efficient so that it doesn't crash the browser.
Here is my code:
//Result Count
int i = 1;
for (SearchHit sh : response.getHits().hits()) {
out.println("Result " + i + " <br>");
out.println(" " + sh.getSource().get("@message").toString() + " <br>");
HashMap hm = (HashMap) sh.getSource().get("@fields");
Iterator it = hm.entrySet().iterator();
while (it.hasNext()) {
Map.Entry pairs = (Map.Entry)it.next();
out.println(" " + pairs.getKey() + " = " + pairs.getValue().toString().replace("[", "").replace("]", "") + " <br>");
}
i++;
out.println(" <br>");
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从您的问题中不清楚真正的瓶颈在哪里：
它可能是您的 JSP 能够从 JSON 对象提取数据的速率。
它可能是 JSP 格式化数据并写入数据的速率。
它可能是网络传输速率。
它可能是浏览器能够读取和呈现响应的速率。
解决方案将取决于瓶颈的实际位置，因此您需要通过分析服务器端并监视浏览器中发生的情况来解决这个问题。解决方案可能涉及更改您生成的 HTML，使其更小或渲染速度更快，或者更改生成 HTML 的方式；例如简化 JSON。 （在您的情况下，后者可能不是一个选项，因为您是从外部服务获取 JSON。）
解决此问题的另一种方法是重构 UI，这样您就不会尝试在一个页面中发送 50,000 个结果。要么做一些服务器端工作来减少/提取结果，使用某种结果集分页，要么在用户浏览器中做一些聪明（且高效）的事情来动态呈现结果。 （最后一个选项涉及将结果作为 JSON 发送到浏览器，并且需要大量浏览器端编码来呈现数据、浏览器独立性问题等！）
Web UI 期望用户费力地浏览包含以下内容的页面 ： 50,000 个结果（IMO）几乎无法使用。
It is not clear from your question where the real bottleneck is:
It could be the rate at which your JSP is able to pull data from the JSON object.
It could be the rate at which the JSP can format the data and write it.
It could be the network transfer rate.
It could be the rate at which the browser is able to read and render the response.
The solution will depend on where the bottleneck actually is, so you need to figure this out by profiling your server-side and monitoring what is happening in the browser. The solution could involve changing the HTML you are generating so that it is smaller or it renders faster, or changing the way you are generating it; e.g. simplifying the JSON. (In your case, the latter may not be an option since you are getting the JSON from an external service.)
The other way to address this is to restructure the UI so that you don't try to send 50,000 results in one page. Either do some server-side work to reduce / distil the results, use some kind of result set paging, or do some clever (and efficient) stuff in the user's browser to present the results dynamically. (The last option would involve sending the results to the browser as JSON, and would entail a lot of browser-side coding to render the data, brower independence issues, etc!)
A web UI that expects the user to wade through a page containing 50,000 results is (IMO) pretty much unusable.
如果您通过 HTTP Watch 或浏览器插件（例如 Chrome 的）在浏览器上放置监视，您会注意到浏览器在处理数据时可能会被锁定在某些活动中。
例如，当使用 HTML 表格来呈现数据时，浏览器会等待渲染表格所需的整组数据首先到达，然后才开始渲染整个表格。这是 HTML TABLE 与 HTML DIV 的争论之一。因此，您可能需要查看是否一直使用 TABLE 来呈现此类数据，并考虑切换到 DIV。
这里是使用 DIV 渲染网格的示例和指南像结构一样。
可能还有其他因素。因此，请监视浏览器活动并查看瓶颈所在。
If you place a watch on your browser, either through HTTP watch or a browser plugin (such as chrome's), you will notice that the browser may be locked in some activities while processing data.
For example, when using HTML tables to present data, the browser waits for the entire group of data required to render the table to first arrive before starting to render the whole table. This is one of the arguments HTML TABLE vs HTML DIV. Therefore, you may want to look at whether you have been using TABLE for rendering such data and consider the switch to DIV.
Here is an example and guide of using DIV to render grid like structures.
There may be also other factors. Therefore, place a watch on your browser activity and see what the bottleneck is.