我有一个休息服务(春季启动),我的一个控制器做了以下事情:以下列格式获取请求体为json:
{
"type" : "TRERDFDFE43274",
"products" : [
{
"code" : "das",
"reason" : "dasd"
}...
]
}
我的控制器
@RequestMapping(value = "owner/session",
method = RequestMethod.POST,
produces = "application/json;charset=UTF-8")
@ResponseBody
public ResponseEntity<List<ErrorReason>> errorReasons(@Validated @RequestBody Items items) {
final List<Products> prod = items.getProducts();
final List<ErrorReason> reasons = new ArrayList<>();
for(final Products p : prod){
final ErrorReason r = new ErrorReason();
r.setReason(p.getReason);
reasons.add(r);
}
return ResponseEntity.ok(reasons);
}
正如您所看到的DTO类名为Items,内部项目我有一个产品列表 在生产中,产品列表的大小是430,000。控制器花费大约4分钟来做出响应。 我的第一个选择是使用fork join pool的重构代码:
final List<Products> prod = items.getProducts();
final List<ErrorReason> reasons = new ArrayList<>();
final ForkJoinPool pool = new ForkJoinPool(10);
pool.submit(()->{
prod.parallelstream().foreach((p)->{
final ErrorReason r = new ErrorReason();
r.setReason(p.getReason);
reasons.add(r);
})
}).get();
return ResponseEntity.ok(reasons);
现在需要2分钟才能做出回应,还有其他方法可以加快响应时间吗?
答案 0 :(得分:0)
如果您对代码进行了分析(当您遇到性能问题时应始终这样做),您会注意到除了创建ErrorReason
对象(您尝试使用ForkJoinPool
),很多时候都会将ErrorReason
个对象转换为JSON,即返回文本。
提高性能的一种可靠方法是忘记完全创建ErrorReason
个对象,然后直接将原始JSON写入响应主体。
它不会很漂亮,但是再次将430,000个对象写入响应也不是很漂亮。由于您不再进行不必要的text->object->text
转换,因此可以保证性能大幅提升。