Resin3.1 优化
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Resin3.1 优化 [转贴]
2008-12-12 10:39
使用resin已经有四、五年了，但以前都是做一些小系统，resin的压力并不大，近段时间做一个大系统，日平均ip上10万，resin的压力非常的大，除了对程序做优化以外，resin 的优化也小不了。
一、优化配置
修改conf/resin.conf 文章中的ＪＶＭ参数
修改最大thread-max为2500
二、利用resin-admin监控resin运行情况。
第一行是Thread pool情况，如果发现Peak大于thread max，就应该修改
conf/resin.conf 中的thread-max，相应的增大thread-max。
第二行是Threads，如果长期出现在这里而又不是ＳＵＮ的方法，或者resin的方法的话，就要对这些方法进行测试、优化。
以下内容都是自己不断实验总结的，而非resin官方的建议，可能不适合你的情况，我的经验仅做为参考。）
最近发现有人用黑客类工具恶意点击网站，或发送大量垃圾包，具体是什么不清楚，但是很明显是故意的，造成80端口无法正常访问，或访问速度极慢。
用netstat -an >>c:\temp\aaa.txt 命令查看了当时情况，发现某几个ip的连接数量巨大，是不正常的。
不管是访问量大，还是有黑客骚扰，我想还是试试看把resin优化一下。
首先要在访问量巨大的时候进行观察。
先将resin.conf文件中的thread-min，thread-max，thread-keepalive三个参数设置的比较大，分别写上，1000，3000，1000，当然这是根据你的机器情况和可能同时访问的数量决定的，如果你的网站访问量很大的，应该再适当放大。然后观察任务管理器中的java线程变化情况，看看到底是线程达到多大的时候，java进程当掉的。我的是在379左右当掉。
然后将thread-min，thread-max，thread-keepalive分别写为150，400，300；，也就是将当掉的时候的最大值稍微放大点，作为thread-max的值，因为该系统一般不会超过这个值。然后其他两个参数根据情况设置一下。
这只是我的估计值，根据机器性能和访问量不同，应该有所不同。
然后将accept-buffer-size值设置的较大，我设置到10000以上，这样可以让java能使用到更多的内存资源。
这样的设置基本上能够满足resin的正常运行，当掉resin服务的情况大大减少，本设置适合于中小型网站。
Resin Threads
Resin will automatically allocate and free threads as the load requires. Since the threads are pooled, Resin can reuse old threads without the performance penalty of creating and destroying the threads. When the load drops, Resin will slowly decrease the number of threads in the pool until is matches the load.
Most users can set thread-max to something large (200 or greater) and then forget about the threading. Some ISPs dedicate a JVM per user and have many JVMs on the same machine. In that case, it may make sense to reduce the thread-max to throttle the requests.
Since each servlet request gets its own thread, thread-max determines the maximum number of concurrent users. So if you have a peak of 100 users with slow modems downloading a large file, you'll need a thread-max of at least 100. The number of concurrent users is unrelated to the number of active sessions. Unless the user is actively downloading, he doesn't need a thread (except for "keepalives").
Keepalives
Keepalives make HTTP and srun requests more efficient. Connecting to a TCP server is relatively expensive. The client and server need to send several packets back and forth to establish the connection before the