快捷搜索:

JAVA导入文件超时问题

前言

业务的临时需求,需要开发一个订单EXCEL导入的功能,从开发到上生产差不多是5天。在SIT环境上,导入400条数据大概是1分钟,于是和客户沟通的是100条数据随便导,但在UAT环境却发现100条数据导入超时的情况。由于数据的导入涉及多库多表的存储,所以对几个核心的feign接口都打上了日志,重新发了版UAT,发现在对主数据做校验的接口上,在SIT和UAT上耗时相差甚远。于是检查了数据库发现,SIT的主数据量在1万多条,UAT是18万条!这件事对我影响还蛮大的,让我在之后思考的时候会从更多的维度去做考虑。

解决问题的思路

由于时间比较赶,客户马上就需要在生产上使用该功能,于是我打算从配置出发,先解决问题,在优化代码。先看前端的请求。 1分钟就超时了。所以我打算先调长前后端的交互时间,保证数据的正常导入。先看下配置中心网关的配置。 将ribbon的超时时间和hystrix的熔断时间都调长,这里的单位是毫秒。然后重启网关。 前端仍然显示超时,但后端仍在运行,并且所有的数据都保存到了数据库中。认真看了下请求的response,发现里面有一段日志 If you are the system administrator of this resource then you should check the error log for details. Faithfully yours, nginx 于是我去检查了下nginx的错误日志,发现里面有一段 upstream timed out (110: Connection timed out) 百度了一下发现,nginx的server里缺少了一段配置 large_client_header_buffers 4 16k; # 读取大型客户端请求头的缓冲区的最大数量和大小 client_max_body_size 300m; #设置nginx能处理的最大请求主体大小。 client_body_buffer_size 128k; #请求主体的缓冲区大小。 proxy_connect_timeout 600; proxy_read_timeout 600; proxy_send_timeout 600; proxy_buffer_size 64k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k;

如果 proxy_connect_timeout、proxy_read_timeout、proxy_send_timeout不做配置,则默认是60S,到此前端超时导入失败的原因就解决了。

根据业务数据定制代码

回过头来看看代码是如何优化的。导入耗时主要是在对主数据的校验,验证name是否存在,然后拿回code进行赋值。我看了下业务导入的数据发现,基本是按同一家公司的数据进行导入的,于是在对主数据校验之前,我加了一个判断 如果和前一个的数据相同,则直接赋值,不再调用feign接口进行校验,也减少了微服务之间交互的次数。至此,导入功能成功满足客户需求,按时生产上线。

经验分享 程序员 微信小程序 职场和发展