Re: mod_jk not changes IP of hostname when occurs changing of IP on DNS
Tiago Braga wrote: Hi, I would like be automatic. 1) read this page carefully : http://tomcat.apache.org/lists.html Particularly : Important, item 6. 2) try to understand the answers which you have already been given. Do not waste other people's time. We understand that you would like this to be automatic, but the point is, it isn't automatic and it cannot be, for the reasons given before. You can automate it yourself, using the scheme that Mladen indicated, but it has to be outside of httpd itself. Create a watchdog program, which detects when the IP changes, and have it trigger a httpd graceful restart. Or, much better, find another infrastructure where the IP address of the Tomcat servers does not change. -- Ok, one more try to explain : The only way to make this automatic within mod_jk, would be to have mod_jk do a DNS lookup *at every request* to verify if the IP address of the worker Tomcat has changed. That would cause an enormous performance hit, which would probably make your application (and any other application) unworkable. (And also, the people running that DNS server would probably complain) In other words, the infrastructure which you have chosen (or which you are forced to use) does not match well with the configuration that you are trying to use. You can persist trying to eat soup using a fork, but it is likely to be frustrating in the end. Thanks. On Fri, Sep 20, 2013 at 12:29 PM, Mladen Turk mt...@apache.org wrote: On 09/19/2013 06:41 PM, Tiago Braga wrote: In apache, the module mod_jk not changes IP of hostname when occurs changing of IP on DNS. Do a graceful restart of httpd when address changes. Unfortunately like some said, we can either do a DNS lookup every time which would be a performance disaster or cache it and reuse (like we do). So graceful restart will cache a new DNS address. Anyhow, I'd suggest you use fixed IP addresses for your backend servers anyhow. Regards -- ^TM --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: I want to redirect the https traffic of apache to tomcat. Such that we can configure SSL certificate on each tomcat instance.
venkateswara Rao Akkireddy wrote: Hi All Hope every one is doing good! Aim: I want to redirect the https traffic of apache to tomcat. Such that we can configure SSL certificate on each tomcat instance. Please Help me on this ASAP This is the kind of thing that you should probably avoid, on a help list that is staffed by volunteers. *1) **Configuration in /etc/httpd/conf/httpd.conf* Listen 174.132.121.115:80 http://174.132.121.115/ Listen 174.132.121.115:443 JkWorkersFile conf/workers.properties JkLogFile logs/mod_jk.log JkShmFile /var/log/httpd/mod_jk.shm JkWatchdogInterval 30 JkLogLevel info JkLogLevel debug JkExtractSSL On JkHTTPSIndicator HTTPS VirtualHost 174.132.121.115:80 http://174.132.121.115/ ServerAdmin ramara...@mmgs.com ServerName 174.132.121.115 JkMount / loadbalancer JkMount /* loadbalancer JkMount /status jkstatus /VirtualHost VirtualHost 174.132.121.115:443 ServerName 174.132.121.115 JkMount / loadbalancerssl JkMount /* loadbalancerssl SetEnv JkHTTPSIndicator On JkMount /status jkstatus JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories /VirtualHost *2) **Configuration in /etc/httpd/conf/workers.properties* worker.list=loadbalancer,jkstatus,loadbalancerssl #Configuration to Show Status of Load balancer worker.jkstatus.type=status #Trippro BE Load Balancer Nodes worker.tpbe1.type=ajp13 worker.tpbe1.host=174.132.121.115 worker.tpbe1.port=8023 worker.tpbe1.lbfactor=1 worker.tpbe1.socket_timeout=210 worker.tpbe2.type=ajp13 worker.tpbe2.host=174.132.121.115 worker.tpbe2.port=8028 worker.tpbe2.lbfactor=1 worker.tpbe2.socket_timeout=210 worker.tpbe1ssl.type=ajp13 worker.tpbe1ssl.host=174.132.121.115 worker.tpbe1ssl.port=8022 worker.tpbe1ssl.lbfactor=1 worker.tpbe1ssl.socket_timeout=210 worker.tpbe2ssl.type=ajp13 worker.tpbe2ssl.host=174.132.121.115 worker.tpbe2ssl.port=8027 worker.tpbe2ssl.lbfactor=1 worker.tpbe2ssl.socket_timeout=210 3) Tomcat Configuration a) TBE1 Tomcat Instance Server.xml config !-- Define an AJP 1.3 Connector on port 8023 for http traffic-- Connector port=8023 address=174.132.121.115 protocol=AJP/1.3 redirectPort=8022 / !-- Define an AJP 1.3 Connector on port 8024 for https traffic-- Connector port=8022 protocol=AJP/1.3 maxThreads=500 scheme=https secure=true SSLEnabled=true connectionTimeout=6 proxyPort=443 keystoreFile=/opt/certificates/star-trippro/trippro.keystore keystorePass=Tr!pPro clientAuth=false sslProtocol=TLS/ Engine name=Catalina defaultHost=TPBE1 jvmRoute=tpbe1 b) TBE2 Tomcat Instance Server.xml config !-- Define an AJP 1.3 Connector on port 8028 for http traffic-- Connector port=8028 address=174.132.121.115 protocol=AJP/1.3 redirectPort=8027 / !-- Define an AJP 1.3 Connector on port 8024 for https traffic-- Connector port=8027 address=174.132.121.115 protocol=AJP/1.3 maxThreads=500 scheme=https secure=true SSLEnabled=true connectionTimeout=6 proxyPort=443 keystoreFile=/opt/certificates/star-trippro/trippro.keystore keystorePass=Tr!pPro clientAuth=false sslProtocol=TLS/ Engine name=Catalina defaultHost=TPBE2 jvmRoute=tpbe2 One thing that you should know : the AJP protocol does not support SSL/HTTPS. In other words, the communication between mod_jk and Tomcat is not encrypted. It is NOT SSL or HTTPS, it is AJP, and there is no AJPS. What AJP /can/ do, is to transport some information from httpd to Tomcat, about the original browser-to-httpd HTTPS communication. That is the point of the Jk HTTPS and SSL options, but nothing else. Graphically : (browser) -- HTTPS -- (httpd + mod_jk) -- AJP -- (Tomcat + AJP Connector) (1) (2) (1) can be encrypted (2) cannot be encrypted (*), but can transport HTTPS headers information from (1) (*) except if you set up some kind of SSL tunnel there, but that would be outside of httpd and Tomcat. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: MaxClients and maxThreads
Daniel Mikusa wrote: On Sep 20, 2013, at 9:27 AM, mohan.radhakrish...@polarisft.com wrote: Is this a hard limit ? No. So if there are 4 cores there can only be 800 concurrent clients. None of our banks is calculating this like this and some have Apache and JBoss on the same machine which further limits the threads. Appreciate any help. Hi, I am following the instructions in https://access.redhat.com/site/articles/15786 to tune MaxClients in httpd.conf and maxThreads in JBoss Tomcat. The recommended value of maxThreads is 200 per CPU, so here we assume the server is a single core machine. If it had been quad core we could push that value to 800 or more depending on RAM and other machine specs. The total threads is an aggregate value. If Apache and JBOSS are on the same server, and that server has four cores, then you would halve the maxThreads and MaxClients to 400 each. Don't base your performance tuning on values you found in an article online. The author of this article has no idea what kind of hardware you are running, what your application is doing or what your needs are for the application. By these metrics, I should setup 800 threads on a quad core system, but if my application is only supporting 10 users that's way too many. Examine your needs, set the values you think will work and then load test to see how things perform. Adjust the settings further based on your load testing results. Dan I have this question. Does this mean that maxThreads and MaxClients should both be equal to each other ? My configuration is this. Machine 1 - JBoss and Apache(2 cores) Machine 2 - JBoss(2 cores) So even though Machine 2 can use about 400 threads(200 x 2 ) it is limited by MaxClients in Machine 1 which should be only 200. Is that correct ? It is a bottleneck. To add to what Daniel is saying, here is a little graphic representation, for one single client browser : (browser) -- HTTP -- (httpd + mod_jk) -- AJP -- (tomcat) -- (webapp) (1) | |- (local resources) (2) When the browser sends a request to httpd, one httpd child/thread is allocated to process that request and return a response to the client. That child/thread is busy with this one request, from the time the request is received to the time when the response has been sent. 2 cases are possible : a) the request is for something that can be served directly by httpd, without need to involve Tomcat. That is the (2) above. For example, in some configurations, static HTML pages, images, stylesheets etc. are served directly by httpd, and only requests for webapps are forwarded to Tomcat. b) the request is for something that has to be processed and served by Tomcat (the (1) above). In that case, httpd + mod_jk will forward the request to Tomcat, and wait for Tomcat's response. When Tomcat responds, httpd + mod_jk will return that response to the browser client. While Tomcat is processing that request, you have one Tomcat thread busy processing that request, and one httpd child/thread waiting for Tomcat to respond. So let's say that at the level of httpd, there are 1000 browser requests coming in every minute. The number of httpd children/threads needed to handle this, depends on how long it takes httpd, on average, to process each request. If it takes on average 1 second to process a request, then each httpd child/thread can on average process 60 requests per minute, and to handle 1000 requests per minute, you need 1000/60 = 16.66 children/threads in httpd. Now estimate (or better, measure) how many of these requests are being forwarded to Tomcat, and how long Tomcat needs on average to process such a request and send a response. With the same kind of calculation, this will tell you how many threads you need in Tomcat. Now to be on the safe side, double these numbers (if your servers support that), and try it out, /with your application/, measure what happens, and rectify the configuration accordingly. The main point is : nobody except yourself knows exactly how your application works, how many requests are really served by httpd and tomcat, or how long it takes to process one request. So nobody can tell you in advance how many threads/children you need in httpd or Tomcat, to serve your volume of requests. The best that the Apache httpd developers, and the Tomcat developers can do, is to provide some best guess defaults, for some configuration that will, in their considerate opinion, be adequate for serving some average needs and not be very unbalanced. And that's what they do, and that is why you should generally start with this default configuration. And then, if you can see and *measure* that there is something wrong, start amending this configuration item by item carefully, and measure again after each change to see if it improves or worsens the situation. There is no one size fits all. (If there
Re: MaxClients and maxThreads
To add to what Daniel is saying, here is a little graphic representation, for one single client browser : (browser) -- HTTP -- (httpd + mod_jk) -- AJP -- (tomcat) -- (webapp) (1) | |- (local resources) (2) When the browser sends a request to httpd, one httpd child/thread is allocated to process that request and return a response to the client. That child/thread is busy with this one request, from the time the request is received to the time when the response has been sent. 2 cases are possible : a) the request is for something that can be served directly by httpd, without need to involve Tomcat. That is the (2) above. For example, in some configurations, static HTML pages, images, stylesheets etc. are served directly by httpd, and only requests for webapps are forwarded to Tomcat. b) the request is for something that has to be processed and served by Tomcat (the (1) above). In that case, httpd + mod_jk will forward the request to Tomcat, and wait for Tomcat's response. When Tomcat responds, httpd + mod_jk will return that response to the browser client. While Tomcat is processing that request, you have one Tomcat thread busy processing that request, and one httpd child/thread waiting for Tomcat to respond. So let's say that at the level of httpd, there are 1000 browser requests coming in every minute. The number of httpd children/threads needed to handle this, depends on how long it takes httpd, on average, to process each request. If it takes on average 1 second to process a request, then each httpd child/thread can on average process 60 requests per minute, and to handle 1000 requests per minute, you need 1000/60 = 16.66 children/threads in httpd. Now estimate (or better, measure) how many of these requests are being forwarded to Tomcat, and how long Tomcat needs on average to process such a request and send a response. With the same kind of calculation, this will tell you how many threads you need in Tomcat. Now to be on the safe side, double these numbers (if your servers support that), and try it out, /with your application/, measure what happens, and rectify the configuration accordingly. The main point is : nobody except yourself knows exactly how your application works, how many requests are really served by httpd and tomcat, or how long it takes to process one request. So nobody can tell you in advance how many threads/children you need in httpd or Tomcat, to serve your volume of requests. The best that the Apache httpd developers, and the Tomcat developers can do, is to provide some best guess defaults, for some configuration that will, in their considerate opinion, be adequate for serving some average needs and not be very unbalanced. And that's what they do, and that is why you should generally start with this default configuration. And then, if you can see and *measure* that there is something wrong, start amending this configuration item by item carefully, and measure again after each change to see if it improves or worsens the situation. There is no one size fits all. (If there was, then the developers would just set it as the default, and they would not need to provide any adjustable parameters). This type of question seems to come up once every 3 months on the mailing list. Given that this is a beautiful explanation, perhaps we could add this as a new section to the tomcat documentation - a new Performance Tuning section? Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
