`
wataxi
  • 浏览: 207085 次
  • 性别: Icon_minigender_1
  • 来自: 广州
社区版块
存档分类
最新评论

(转)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 first data can go through. HTTP/1.1 introduced a protocol to keep the connection open for more requests. The srun protocol between Resin and the web server plugin also uses keepalives. By keeping the connection open for following requests, Resin can improve performance.
resin.conf for thread-keepalive
<resin ...>
  <thread-pool>
    <thread-max>250</thread-max>
  </thread-pool>

  <server>
    <keepalive-max>500</keepalive-max>
    <keepalive-timeout>120s</keepalive-timeout>
    ...
Timeouts

Requests and keepalive connections can only be idle for a limited time before Resin closes them. Each connection has a read timeout, request-timeout. If the client doesn't send a request within the timeout, Resin will close the TCP socket. The timeout prevents idle clients from hogging Resin resources.
...
<thread-pool>
  <thread-max>250</thread-max>
</thread-pool>

<server>

   <http port="8080" read-timeout="30s" write-timeout="30s"/>

...
...
<thread-max>250</thread-max>

<server>

   <cluster>
     <client-live-time>20s</client-live-time>

     <srun id="a" port="6802" read-timeout="30s"/>
   </cluster>

...
In general, the read-timeout and keepalives are less important for Resin standalone configurations than Apache/IIS/srun configurations. Very heavy traffic sites may want to reduce the timeout for Resin standalone.
Since read-timeout will close srun connections, its setting needs to take into consideration the client-live-time setting for mod_caucho or isapi_srun. client-live-time is the time the plugin will keep a connection open. read-timeout must always be larger than client-live-time, otherwise the plugin will try to reuse a closed socket.
Plugin keepalives (mod_caucho/isapi_srun)

The web server plugin, mod_caucho, needs configuration for its keepalive handling because requests are handled differently in the web server. Until the web server sends a request to Resin, it can't tell if Resin has closed the other end of the socket. If the JVM has restarted or if closed the socket because of read-timeout, mod_caucho will not know about the closed socket. So mod_caucho needs to know how long to consider a connection reusable before closing it. client-live-time tells the plugin how long it should consider a socket usable.
Because the plugin isn't signalled when Resin closes the socket, the socket will remain half-closed until the next web server request. A netstat will show that as a bunch of sockets in the FIN_WAIT_2 state. With Apache, there doesn't appear to be a good way around this. If these become a problem, you can increase read-timeout and client-live-time so the JVM won't close the keepalive connections as fast.
unix> netstat
...
localhost.32823      localhost.6802       32768      0 32768      0 CLOSE_WAIT
localhost.6802       localhost.32823      32768      0 32768      0 FIN_WAIT_2
localhost.32824      localhost.6802       32768      0 32768      0 CLOSE_WAIT
localhost.6802       localhost.32824      32768      0 32768      0 FIN_WAIT_2
...
TCP limits (TIME_WAIT)

A client and a server that open a large number of TCP connections can run into operating system/TCP limits. If mod_caucho isn't configured properly, it can use too many connections to Resin. When the limit is reached, mod_caucho will report "can't connect" errors until a timeout is reached. Load testing or benchmarking can run into the same limits, causing apparent connection failures even though the Resin process is running fine.
The TCP limit is the TIME_WAIT timeout. When the TCP socket closes, the side starting the close puts the socket into the TIME_WAIT state. A netstat will short the sockets in the TIME_WAIT state. The following shows an example of the TIME_WAIT sockets generated while benchmarking. Each client connection has a unique ephemeral port and the server always uses its public port:
Typical Benchmarking Netstat
unix> netstat
...
tcp   0   0 localhost:25033  localhost:8080  TIME_WAIT  
tcp   0   0 localhost:25032  localhost:8080  TIME_WAIT  
tcp   0   0 localhost:25031  localhost:8080  TIME_WAIT  
tcp   0   0 localhost:25030  localhost:8080  TIME_WAIT  
tcp   0   0 localhost:25029  localhost:8080  TIME_WAIT  
tcp   0   0 localhost:25028  localhost:8080  TIME_WAIT
...
The socket will remain in the TIME_WAIT state for a system-dependent time, generally 120 seconds, but usually configurable. Since there are less than 32k ephemeral socket available to the client, the client will eventually run out and start seeing connection failures. On some operating systems, including RedHat Linux, the default limit is only 4k sockets. The full 32k sockets with a 120 second timeout limits the number of connections to about 250 connections per second.
If mod_caucho or isapi_srun are misconfigured, they can use too many connections and run into the TIME_WAIT limits. Using keepalives effectively avoids this problem. Since keepalive connections are reused, they won't go into the TIME_WAIT state until they're finally closed. A site can maximize the keepalives by setting thread-keepalive large and setting live-time and request-timeout to large values. thread-keepalive limits the maximum number of keepalive connections. live-time and request-timeout will configure how long the connection will be reused.
Configuration for a medium-loaded Apache
...
<thread-pool>
  <thread-max>250</thread-max>
</thread-pool>

<server>
  <keepalive-max>250</keepalive-max>
  <keepalive-timeout>120s</keepalive-timeout>

  <cluster>
    <client-live-time>120s</client-live-time>

    <srun id="a" port="6802" read-timeout="120s"/>
  </cluster>
...
read-timeout must always be larger than client-live-time. In addition, keepalive-max should be larger than the maximum number of Apache processes.
Apache 1.3 issues

Using Apache as a web server on Unix introduces a number of issues because Apache uses a process model instead of a threading model. The Apache processes don't share the keepalive srun connections. Each process has its own connection to Resin. In contrast, IIS uses a threaded model so it can share Resin connections between the threads. The Apache process model means Apache needs more connections to Resin than a threaded model would.
In other words, the keepalive and TIME_WAIT issues mentioned above are particularly important for Apache web servers. It's a good idea to use netstat to check that a loaded Apache web server isn't running out of keepalive connections and running into TIME_WAIT problems.


先将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优化:

The allocation of memory for the JVM is specified using -X options when starting Resin

(the exact options may depend upon the JVM that you are using, the examples here are for the Sun JVM).

JVM option passed to Resin Meaning
-Xms initial java heap size
-Xmx maximum java heap size
-Xmn the size of the heap for the young generation

Resin startup with heap memory options unix> bin/httpd.sh -Xmn100M -Xms500M -Xmx500M win> bin/httpd.exe -Xmn100M -Xms500M -Xmx500M install win service> bin/httpd.exe -Xmn100M -Xms500M -Xmx500M -install

原文:http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp


JVM 优化:

java -Xms<size>
set initial Java heap size. default:Xms32m
java -Xmx<size>
set maximum Java heap size. default:Xmx128m

set it like that:

java -Xms=32m -Xmx=256m
If the problem persist, increase Xmx more than 256 ( 512m for example )

-J-mx<num>
分享到:
评论

相关推荐

    resin2优化-命令配置优化服务器

    《Resin2优化:命令配置与服务器调优详解》 Resin是一款高性能、轻量级的Java应用服务器,尤其在处理Web应用方面表现出色。在实际应用中,为了确保Resin能够高效稳定地运行,对服务器进行优化是必不可少的步骤。...

    resin3 和 resin4

    1. **高性能的Servlet容器**:Resin3优化了Servlet的处理机制,确保了高并发场景下的高效运行。 2. **JSP支持**:对JSP的出色支持使得开发者能够快速构建动态Web页面,提升了开发效率。 3. **内存管理**:Resin3采用...

    resin服务器有3部分,resin1,resin-webapp,resin-lib,由于大小限制分开传

    Resin服务器是一款高性能的Java应用服务器,由Caucho Technology公司开发。它的设计目标是提供高效、稳定且易于管理的平台来运行...了解并掌握这些知识点,将有助于您更好地部署、管理和优化基于Resin的Java应用程序。

    resin-1 resin服务器有三部分

    【标题】:“resin-1 resin服务器的组件详解” 【正文】: Resin服务器是一款高效、轻量级的Java应用服务器,尤其适用于处理...理解这些组件的作用,有助于更好地管理和优化Resin服务器,从而提升应用的性能和稳定性。

    泛微OA安装resin服务

    可直接双击运行,如安装失败,请右击,以系统管理员身份运行。

    Resin泛解析 - 三级域名应用方案

    4. 线程优化经验 为了解决线程问题,可以在resin.conf文件中设置thread-min、thread-max和thread-keepalive参数。这些参数可以根据实际情况进行调整,以确保Resin的稳定运行。 5. Resin.conf配置参数说明 Resin....

    resin4.0 服务器 (for windows版本)

    Resin 4.0 服务器是一款高性能的...同时,定期更新Resin到最新版本,可以确保获得最新的安全补丁和性能优化。总的来说,Resin 4.0服务器是Java Web应用的理想选择,尤其适合那些追求高性能、高并发和易管理性的企业。

    Resin源码解读1

    Resin,作为一个高性能的Java应用服务器,其源码解析对于我们深入理解Web服务器的运行机制和优化技术具有重要的价值。本文将从日志分析、运行时调试、网络模型以及线程池模型四个方面进行深入探讨。 一、日志分析 ...

    resin安装包

    为了提升性能和保障安全性,建议对Resin进行一些必要的优化,例如调整线程池大小、启用SSL、限制访问权限等。具体配置项可以在`resin.xml`中找到。 9. **停止与重启Resin** 当需要停止或重启Resin时,同样在bin...

    resin的eclipse插件,支持resin 3.1

    总结来说,Resin的Eclipse插件是Java开发者在使用Eclipse开发基于Resin 3.1的应用时的重要辅助工具,它提供了一整套集成了Resin服务器管理、应用部署、日志查看等功能,极大地优化了开发流程。通过阅读提供的博文...

    绿色版resin服务器

    此外,Resin的性能优化是其一大亮点。它采用了多线程模型,能够有效地利用多核处理器,提高并发处理能力。内存管理也经过优化,降低了垃圾回收对性能的影响。这些特性使得Resin在处理高负载场景时表现优异。 然而,...

    resin4.0配置文件介绍

    ### Resin 4.0 配置文件介绍与解析 #### 一、Resin 4.0 启动概述 **Resin 4.0** 是一款高性能的应用服务器,适用于部署 Java 应用程序。本章节主要介绍了 Resin 的启动过程、启动前的准备条件以及在不同操作系统上...

    resin服务器resin-pro-3.1.8

    - **性能优化**:这个版本进行了大量的性能优化,包括更高效的内存管理和更快的请求处理。 - **安全性增强**:3.1.8版可能包含安全更新,修复了潜在的安全漏洞,提升了服务器的安全性。 - **管理工具**:提供了...

    resin-3.1.9-src

    通过对Resin 3.1.9源代码的分析,开发者可以深入理解J2EE规范的底层实现,掌握服务器内部的工作原理,这对于优化应用性能、排查问题以及自定义扩展有着极大的帮助。同时,Resin的高效性能和轻量级特性也为其他开源...

    resin-4.0.23

    Resin 是一款高性能的Java应用服务器,由Caucho Technology公司开发。Resin 4.0.23 版本是这个系列中的一个重要版本,它...无论是对于初学者还是经验丰富的开发者,掌握Resin的使用都能极大地提升工作效率和应用性能。

    resin-3.1.10

    10. **日志和监控**:Resin提供了丰富的日志记录和监控工具,帮助开发者调试和优化应用。 在升级到更现代的版本之前,使用Resin 3.1.10的老系统可能会遇到一些挑战,比如对新Java和Web技术的支持不足、安全性可能...

    resin-3.0.24.zip

    2. 高性能:Resin以其高性能而闻名,它优化了JSP和Servlet的处理,提供了更快的响应速度。这得益于其内置的HTTP缓存和连接池管理,以及对多线程和并发处理的支持。 3. Java EE支持:虽然Resin主要作为Web服务器,但...

    resin-3.0.28.rar

    - **性能优化**:Resin 3.0.28以其高效的线程管理和内存管理而著称,能够处理高并发请求,确保低延迟和快速响应。 - **Web应用部署**:支持热部署,允许开发者在不中断服务的情况下更新应用程序。 - **负载均衡和...

    resin_3.1中文配置手册.doc

    Resin 3.1中文配置手册是一份详细指导文档,旨在帮助用户理解和配置Resin服务器。Resin是一款高性能、轻量级的Java应用服务器,它支持Servlet、JSP、EJB以及Quercus(PHP的Java实现)等多种技术。这份手册涵盖了从...

Global site tag (gtag.js) - Google Analytics