1
pushyzheng 2021-10-26 22:20:18 +08:00
Reactor 挺适合这种场景的
|
2
Jooooooooo 2021-10-26 22:21:39 +08:00
并行调用耗时就是最慢的那个接口, 这个角度没啥可优化的点了.
|
3
luxinfl OP |
4
luxinfl OP 主要是测试压测有个时延要求,p95 要到 50ms ,但是这个服务需要调用多个外部接口。没什么优化经验。。用了 parallelStream ,增大的连接池的 defaultMaxPerRoute 。效果不是太好,就在想是不是 parallelStream 有什么缺陷
|
5
urzz 2021-10-26 22:45:46 +08:00
建议不要用 parallelStream ,ForkJoinPool 是全局共用的。。
|
7
urzz 2021-10-27 01:13:56 +08:00
你如果可以保证没有别人用 parallelStream ,那可以。要不然这种在 parallel 中进行 io 调用的,是可能会导致阻塞的
这种情况下,可以尝试自己定义线程池,然后用 CompletableFuture.supplyAsync ,配合 CompletableFuture.allOf(...).join() 等待线程结束获取结果。建议改完后压一波试试 |
8
w7938940 2021-10-27 01:31:51 +08:00
Fibers + Channel
|
9
VHacker1989 2021-10-27 08:20:41 +08:00 via Android
分布式
|
10
aeiou520 2021-10-27 08:58:23 +08:00
CompletableFuture?
|
11
siweipancc 2021-10-27 09:01:45 +08:00 via iPhone
多线程加阻塞同步器,怕并发太大可以塞信号量
|
13
Aliberter 2021-10-27 09:53:22 +08:00
自定义线程池+CountDownLatch ,说到底总耗时还是取决于最慢的那个接口的响应时间。
|
14
wolfie 2021-10-27 09:54:26 +08:00
可以自定义 ForkJoinPool
forkJoinPool.execute(e -> { someList.parallelStream() }) |
15
hingbong 2021-10-27 10:20:16 +08:00
用 parallelStream 都会自定义 ForkJoinPool 吧,问题不大
|
16
Vegetable 2021-10-27 10:22:59 +08:00
先做好日志确认一下,确认是否「总用时~=耗时最长的外部服务」,如果是的话,就没什么优化的空间了,如果不是再排查吧,按理说这么做没问题。
|
17
Chinsung 2021-10-27 11:09:07 +08:00
查数据就是并发+缓存,没啥别的办法。
|
18
8355 2021-10-27 14:26:48 +08:00
除非提前调用直接查 不然并行调用还是会以最慢的接口时间
如果因为网络或者机器位置的关系找运维给你加代理网关会好很多 |
19
xiang0818 2021-10-27 15:09:12 +08:00
这个没办法解决的,外部接口的调用时间在于别人服务器对你的响应时间。
|
20
night98 2021-10-27 18:30:19 +08:00
提前聚合
|
21
WispZhan 2021-10-27 19:10:53 +08:00
最直接的解 CompletableFuture ,这玩意写起来贼恶心。
比较优雅的解 Kotlin 协程 |
22
makdon 2021-10-27 19:25:10 +08:00
无解,就算你的六七个接口都没有互相依赖,全并行一起请求外部,
访问外部来回 rtt 也是要耗时的,外部接口再稍微慢一点你的 p95 就到不了 50ms 了 除非把机房搬外部接口提供方机房旁边,不然跨一下地域轻轻松松就过 50ms 了,不过你这个 case 还有 6 ,7 次外部接口,也不知道是不是同一个提供商,不是的话机房都搬不动了 随便搜了一下时延的经验值 腾讯云: 北京到上海:38ms 上海到广州:40ms 北京到广州:53ms |
23
az402 2021-10-28 09:06:36 +08:00
<groupId>com.jd.platform</groupId>
<artifactId>asyncTool</artifactId> <version>1.4.1-SNAPSHOT</version> 可以看一下这个,前段无意中发现的。 还没仔细看,貌似不错。 |
24
jorneyr 2021-10-28 11:27:02 +08:00
CompletionService 或者 CompletableFuture 挺好用的,还可以自己传入 ThreadPoolExecutor
|
25
snappyone 2021-10-28 13:35:19 +08:00
p95 要到 50ms , 你先确定下你依赖的那几个接口能到这个速度吗
|
26
luxinfl OP |
27
urzz 2021-10-28 23:35:58 +08:00
@luxinfl #26 原理是差不多的,都是异步同时请求接口,而不是串行。只不过这种方式可以将任务丢进线程池,而不是每次 new 线程跑。
不过这种方式是否能满足你需求也是母鸡的。。毕竟这种聚合接口的耗时要看你依赖接口的 |
28
billly 2021-10-29 09:25:42 +08:00
之前看过 linkedin/parseq ,看起来还行,没用过
|
29
luxinfl OP @billly 现在改用 CompletableFuture 试试会不会好,实际用起来,感觉并发流不太好。
|
30
KuroNekoFan 2021-10-29 10:31:04 +08:00
试试 nodejs(
|