每秒300次请求的服务端，线程池的池中线程最大个数设置多少个比较合理 本帖最后由 Kanepan 于 2010-06-04 14:27:11 编辑 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 如果此时线程池中的数量小于corePoolSize，即使线程池中的线程都处于空闲状态，也要创建新的线程来处理被添加的任务。 如果此时线程池中的数量等于 corePoolSize，但是缓冲队列 workQueue未满，那么任务被放入缓冲队列。 如果此时线程池中的数量大于corePoolSize，缓冲队列workQueue满，并且线程池中的数量小于maximumPoolSize，建新的线程来处理被添加的任务。 如果此时线程池中的数量大于corePoolSize，缓冲队列workQueue满，并且线程池中的数量等于maximumPoolSize，那么通过 handler所指定的策略来处理此任务。 你的服务端是什么？Socket 的？每秒 300 个是指一天中的 86400 秒基本上都是这个数，还是突发性的？ 这是个经验问题。可以做个测是，找到比较一个合适的值。线程数量不是越多越好，太多， cpu在线程间切换就会消耗比较多的资源，太少，又不能及时响应用户请求。 你自己也会说到会占用操作内存和数据库连接池。自己可以列个公式来计算一下。这也是为什么会有stress test的原因了。这个不是靠脑袋拍就能决定的还是需要自己去balance的 线程池的大小并不是越大效率越高，一般比较高的是 cpu数+1个对于负载过大的话，你可以做集群，在客户端分发请求。 每秒300个，太多了点，要是能改,最好在一次循环里面处理多个任务.线程开太多也不是好事.具体开多少个线程，要考虑业务处理时间，只能自己测试看了，java有几个性能测试工具，可以看到CPu占用率及线程是否有挂死现象 恩 是Socket的，从早上10点到下午5点这段时间是高峰期。 你真的确定有这么大的量？[/Quote]有长连接也有短连接。 1500个左右的长连接 15秒断一次， 另外20秒内 4000多个短连接。 这么算应该有 每秒300吧 根据我的经验，每秒300个线程访问，一般的服务器都承受不了的（假定你使用的是市场上常见的普通服务器，不是大型、巨型计算机），关键不在于CPU的计算能力，而在于缓存的容量和内存缓冲区的大小和访问速度的限制，还有硬盘访问的耗时。所以，我的建议和楼上一样，如果条件允许，最好能开几个服务器（2~3）并行工作，这样可以有效地提高效率，成本比升级到大型、巨型计算机小得多。 应该是每秒处理大约300个链接吧 ？如果这样理解，那就会好一些了。因为，在这一秒钟的300个链接中，并不是所有300个链接都有数据在传输。如果链接中，没有数据传输，服务端就没有太多的CPU处理时间了。首先应该考虑的是，数据库方面的优化，尽量做到小数据量的查询，基本不出现大数据量的插入、更新操作。将插入、更新操作，尽量做成定时调度程序，后台辅助完成。其次，要分析业务处理过程，的瓶颈在哪里。在耗费CPU时间相对较低的情况下（也就是说，一个业务处理过程，大部分时间都是CPU在等别的条件具备了，才进行处理。），如果业务处理过程，可以拆分成并发的处理过程，这样才建议使用线程池。第三，一般来讲，线程池，是所有用户共享的。并不是某个用户点击触发服务端进行业务处理的时候，才开始创建的线程池，否则的话，多个用户同时触发，就会创建多个线程池，这样很危险。如果是所有用户共享使用线程池进行某个业务环节的并发处理的话，根据该环节的并发量，可以适当将线程池的峰值调高一些。我觉得问题的关键，还是要弄清楚，针对于某个业务处理过程，所占用的处理时间和CPU时间。当然，这也仅仅是我的愚见吧。期待楼下 哦。我想，链接的多少，并不是问题的关键。关键是缩短数据的处理过程。你想啊，迅雷等支持BT协议的软件，一个线程要搞定几百上千个链接，也没见得CPU的使用率有多高，或者硬盘狂转不已，致使电脑看上去像僵死的状态。这说明，那么多的链接，大部分都空闲着，否则，的话，不是CPU使用率超高，就是，硬盘狂转吧。（当然，4M一下的宽带用户，是不会出现硬盘狂转的情况滴。呵呵） 现在每秒300的并发量，在CPU8核内存4G的服务器，基本上能撑住。但是容易受到一些应用的影响，因为这服务器不单单跑了JAVA服务端，还跑了其他的应用。 一个慢查询，一个文件传输等.. 就容易导致服务器负载高.. 现在看来 问题是不是能归结为，整体架构上的缺陷了？ 可以看一下netstat -anp | grep :<服务端端口号>看一下有多少个客户端与之相连，ESTABLISHED 状态有多少个，TIME_WAIT 状态的有多少个。 可能我对并发量理解有误.. 服务端监听了两个端口 早上量还没起来端口1： 30 ESTABLISHED 1 LISTEN 97 TIME_WAIT 端口2： 3119 ESTABLISHED 1 LISTEN 272 TIME_WAIT 监听端口是用来监听客户端是否有连接来了，当有连接来的时候，操作系统会分配一个随机的端口与客户端的端口建立 TCP 连接并进行通信。有一个客户端连接（已连上暂未断开），那在服务端用 netstat 查看 ESTABLISHED 的话也对应着一行数据。 如果同时有 1000 个连接在工作的话，那用：netstat -anp | grep :<端口> | grep ESTABLISHED | wc -l能看到统计出来的行数是 1000 又统计了次 ： 端口1： 有长连接 也有短连接 3856 ESTABLISHED 5 FIN_WAIT1 1 LISTEN 190 TIME_WAIT 端口2： 只有短连接 36 ESTABLISHED 1 LISTEN 163 TIME_WAIT 一个关于for的问题 关于面向对象的简单问题 不用任何IDE 如何让程序找到第三方的类？ 如何把一个Java程序打包成可执行文件？ 如何把数据库中的值读取到数组中来？ 请教高手指点！！！！ 玩转JEditorPane的高手进来帮下忙...... [２００分]关于throws和throw和try{}catch(){}的区别和联系，书本上也说的迷迷糊糊，他们中的三种不知什么时候该使用！详细如下： 怎样使JScrollPane自动滚动 有大佬能详细讲解下这个java代码吗 请问高手，困扰的问题。 如何设置JScrollPane 上下滚动 但是左右不滚动啊
这也是为什么会有stress test的原因了。
这个不是靠脑袋拍就能决定的还是需要自己去balance的
具体开多少个线程，要考虑业务处理时间，
只能自己测试看了，
java有几个性能测试工具，可以看到CPu占用率及线程是否有挂死现象
恩 是Socket的，从早上10点到下午5点这段时间是高峰期。
[/Quote]有长连接也有短连接。 1500个左右的长连接 15秒断一次， 另外20秒内 4000多个短连接。
这么算应该有 每秒300吧
如果这样理解，那就会好一些了。因为，在这一秒钟的300个链接中，并不是所有300个链接都有数据在传输。
如果链接中，没有数据传输，服务端就没有太多的CPU处理时间了。
首先应该考虑的是，数据库方面的优化，尽量做到小数据量的查询，基本不出现大数据量的插入、更新操作。
将插入、更新操作，尽量做成定时调度程序，后台辅助完成。
其次，要分析业务处理过程，的瓶颈在哪里。在耗费CPU时间相对较低的情况下（也就是说，一个业务处理过程，大部分时间都是CPU在等别的条件具备了，才进行处理。），如果业务处理过程，可以拆分成并发的处理过程，这样才建议使用线程池。
第三，一般来讲，线程池，是所有用户共享的。并不是某个用户点击触发服务端进行业务处理的时候，才开始创建的线程池，否则的话，多个用户同时触发，就会创建多个线程池，这样很危险。如果是所有用户共享使用线程池进行某个业务环节的并发处理的话，根据该环节的并发量，可以适当将线程池的峰值调高一些。我觉得问题的关键，还是要弄清楚，针对于某个业务处理过程，所占用的处理时间和CPU时间。当然，这也仅仅是我的愚见吧。
期待楼下
你想啊，迅雷等支持BT协议的软件，一个线程要搞定几百上千个链接，也没见得CPU的使用率有多高，或者硬盘狂转不已，致使电脑看上去像僵死的状态。
这说明，那么多的链接，大部分都空闲着，否则，的话，不是CPU使用率超高，就是，硬盘狂转吧。
（当然，4M一下的宽带用户，是不会出现硬盘狂转的情况滴。呵呵）
现在看来 问题是不是能归结为，整体架构上的缺陷了？
端口1：
30 ESTABLISHED
1 LISTEN
97 TIME_WAIT
端口2：
3119 ESTABLISHED
1 LISTEN
272 TIME_WAIT
端口1： 有长连接 也有短连接
3856 ESTABLISHED
5 FIN_WAIT1
1 LISTEN
190 TIME_WAIT 端口2： 只有短连接
36 ESTABLISHED
1 LISTEN
163 TIME_WAIT