V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  luxinfl  ›  全部回复第 1 页 / 共 16 页
回复总数  320
1  2  3  4  5  6  7  8  9  10 ... 16  
@yidinghe 9 键键盘太小,容易多点
@golangLover 发过类似的,仅仅是使用方法
@fdgdbr
@chengyulong
@sagaxu
我是觉得这种异步方式会不会很耗时。因为有的接口服务方返回的很快,就几毫秒。但是我服务打的 http 调用时间,差了八九倍。
@cxshun 现在采用的就是多个 CF 的写法,然后一起 join ,等待所有接口调用完毕才走到下一步。提供方的接口性能确实也不好。我也怀疑是不是网络时延太高,h 都是 http 调用
@admol
@tairan2006
@newskillsget
两个都是用了自定义的线程池,并行流用的自定义 ForkJoinPool ,CF 用的普通的池子
@ZeroDu 我现在新接口用的 CompletableFutrue ,自定义线程城市,用了 join 方法,但是发现还是没啥效果
@dqzcwxb 我有自定义线程池
30 天前
回复了 luxinfl 创建的主题 程序员 一个聚合接口,如何才能优化时延
@billly 现在改用 CompletableFuture 试试会不会好,实际用起来,感觉并发流不太好。
@dqzcwxb 主要是有多个 io 调用,而且 parallel 并发调用写起来方便。。没太搞明白 CompletableFuture 怎么写才能并发调用。要写多个 supplyAsync 调用麽
@dqzcwxb 这个以前用得少,没注意过。。而且我发现用 jmeter 压测,ForkJoinPool 的性能并不是太好的样子。。和线程数有很大关系
@Jooooooooo 意思是就好像没有并行一样
@aureole999 还有这种说法么
30 天前
回复了 luxinfl 创建的主题 程序员 一个聚合接口,如何才能优化时延
@hingbong 项目里面真的好多 paralleStream 都没有自定义线程池。每个 parallel 都自定义一个是不是不太好
@Vegetable 奇怪的是,每个并发流时间都不高,但是最终却很高,怀疑是用了共享线程池的缘故
@WispZhan @aeiou520 @urzz 我用的 CompletableFuture 然后自定义线程池,但是用了 get()方法,感觉就和 Future 差不多的样子
32 天前
回复了 luxinfl 创建的主题 程序员 一个聚合接口,如何才能优化时延
@urzz 如果定义那个 ForkJoinPool 有啥问题么
32 天前
回复了 luxinfl 创建的主题 程序员 一个聚合接口,如何才能优化时延
主要是测试压测有个时延要求,p95 要到 50ms ,但是这个服务需要调用多个外部接口。没什么优化经验。。用了 parallelStream ,增大的连接池的 defaultMaxPerRoute 。效果不是太好,就在想是不是 parallelStream 有什么缺陷
32 天前
回复了 luxinfl 创建的主题 程序员 一个聚合接口,如何才能优化时延
@pushyzheng 有点太复杂了,不太适合吧。我应用场景就是并发调用接口

@Jooooooooo 实现不太一样吧,有时候还会碰到从连接池获取连接超时。。
@Aruforce 我尝试过,但打印的格式不是自定义的,说明日志组件还是没有初始化完成吧
@wz497345846 这个只是配置文件会优先读到吧
@suenlai 我去查一下,我今天才刚知道有这么个 log
@suenlai 那就是没法搞到指定文件?只能靠修改 shell 脚本来打印了么。有没有可能在监听器里面实现
@CallMeReznov 日志分割不是有固定大小设置麽,说实话不是很懂
@Vegetable 这意思是不是即使新建了个同名文件,也不行? linux 不是很懂。
1  2  3  4  5  6  7  8  9  10 ... 16  
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2275 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 18ms · UTC 08:49 · PVG 16:49 · LAX 00:49 · JFK 03:49
♥ Do have faith in what you're doing.