forked from whx123/JavaHome
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
27 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
**问题一:** | ||
|
||
我现在用了一个静态线程池,用于整个请求共享。设置的参数是核心线程10个,最大线程147个,阻塞队列2048,策略是超过就丢弃并且抛异常。 | ||
当qps在1000的时候,由于一个请求我需要分成三次去请求不同的接口,就相当于有3000个调用接口的请求。 但是请求用的是实时接口,如果该接口响应很慢比如10秒钟,那么这147个线程就全部挂起了,没有空余的线程去处理新的业务了。整个系统的响应就非常慢了。 | ||
|
||
群上回复答案: | ||
> - 响应很慢的接口走异步,把返回的数据丢到queue里面。 | ||
> - 应该是10秒的接口得改 | ||
> - 接口慢了的话,看下能不能用redis | ||
> - 合并请求,减少网络传输时间 | ||
> - 优化接口肯定需要,从源头解决 | ||
我觉得,先理解好线程池原理吧,就是,来个请求就拿个核心线程去处理,如果核心线程用完了,就放队列,队列满了,就拿非核心线程去处理,处理不过来之后,就根据策略去处理,线程干完活又会被拉取干别的~然后呢,就算每秒以前个请求过来,最多也是线程池供应不过来,然后抛弃一部分请求,跟响应慢不是一个因果关系。 | ||
|
||
![](https://imgkr2.cn-bj.ufileos.com/5f138381-05f3-4aa2-a344-98e8b970a920.png?UCloudPublicKey=TOKEN_8d8b72be-579a-4e83-bfd0-5f6ce1546f13&Signature=yJuf5adRW5I%252BSl3%252FWX1oyVr9%252Ffo%253D&Expires=1603008626) | ||
|
||
|
||
其实,如果每个请求30毫秒处理完,可能你的线程池也够用了。但是呢,如果你一个请求,接口处理10s,也就是说10秒,它没干完活,没法接别的活,肯定系统就处理不过来那么多请求啦,所以最后结果就是,一部分请求就会抛弃,因为线程池抛弃策略抛弃啦。回过头,你的系统响应慢,就是你的接口耗时问题呀,你需要优化它。 | ||
|
||
可以看下我这两篇文章。线程池和如何接口性能优化的~ | ||
|
||
|
||
|
||
关于线程池和接口性能优化的,可以看下我之前这两篇文章哈 | ||
- [面试必备:Java线程池解析](https://mp.weixin.qq.com/s?__biz=MzIwOTE2MzU4NA==&mid=2247483728&idx=1&sn=0221dfd5eb7862c0aa749a7038b39307&chksm=9779457fa00ecc69d3bb554ccc1daa8aa204b16b15587759cf1f148bda51907f6f57418e150f&token=1319249232&lang=zh_CN#rd) | ||
|
||
- [记一次接口性能优化实践总结:优化接口性能的八个建议](https://mp.weixin.qq.com/s?__biz=MzIwOTE2MzU4NA==&mid=2247484426&idx=1&sn=7265be5a5c37e71e65a2e42c999d3f72&chksm=97794025a00ec93379ad537353dd58f9149f801e100786a2b9c8cf37257e6d863d7ce4b87a5e&token=1319249232&lang=zh_CN#rd) |