tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suvendu Sekhar Mondal <suv3...@gmail.com>
Subject Re: Queries regarding tuning Apache Tomcat to serve high traffic
Date Thu, 13 Jun 2019 17:44:34 GMT
On Wed, Jun 12, 2019, 7:18 PM Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Vinu,
>
> On 6/12/19 04:53, Vinu Vibhu Sobhana wrote:
> > Hai Team,
> >
> > I have been requested by Project Manager to host a web application
> > in Tomcat 8.5 and tune the server to cater high traffic. So, I
> > have hosted the web application on an allotted VPS server with
> > specification (8 vCPU, 16GB RAM and 200 HD), with Tomcat 8.5.42
> > installed.  The web application has been successfully hosted also.
> >
> > Now, with respect to tuning part, I have to clear some points
> > before making it on-line
> >
> > 1. How can I tune this server to cater high traffic.
>
> Tomcat is tuned fairly well out of the box.
>
> > 2. What all are the parameters that I need to considered while
> > tuning
>
> There really aren't that many things you can change. Mostly, you can:
>
> 1. Add more threads to the thread pool
> 2. Allow more connections
> 3. Adjust timeouts to evict clients who aren't responding quickly enough
>
> > 3. Any open-source tools to generate high traffic and test the
> > currently configured server
>
> Apache JMeter is pretty much the standard, here. Remember that you
> want to make sure that your test is valid by generating load from
> multiple servers and not just one host which might limit itself.
>
> Our testing[1] indicates that you can fill the network before Tomcat
> begins to struggle with moving bytes around.
>
> Your application is far more likely to be a bottleneck than anything
> Tomcat related.


> > 4. Any references / biogs that I can refer regarding this topic 5.
> > Any suggestions from your end.
>
> It sounds like you have a single server running your application. I
> would recommend more than one for fault-tolerance and
> high-availability. Users are happier with a slower, available service
> than a fast one that isn't reachable. :)

> Note: A brief about the the web application. Its a small
> > recruitment portal web application that lets 1. Clients to register
> > their details 2. Allot a time-frame to have an on-line exam 3.
> > Performs on-line exams for the selected candidates (another
> > schedule) 4. Publish their results 5. Expected traffic rate 1000
> > hits/sec approx.
>
> That doesn't give us much information. What really matters is the
> amount of information going over the network. Tomcat mostly just
> pushes bytes over the network for you and dispatches everything to
> your application.
>
> So unless you are having a specific problem, there really is nothing
> to do with Tomcat to make it "faster". It's already pretty much as
> fast as it can be.
>

+1

There is no "silver bullet" to tune and scale one app. In my 10 years of
(little)work experience I have seen that mostly apps are the bottleneck,
not the web containers. How much one app can scale is hugely depends on how
much time it is taking to perform a single unit of work. If it is in few
millisecond range, probably you are in good shape. IMO, anything taking
more than a second or two in business logic processing, is a candidate for
tuning. Sometimes it's really tough to tune legacy app. In those cases I
follow "first parallelize, then optimize" rule. Create more JVM
instances(redundant app deployment), do parallel processing, reach
scalability target and at the very same time work to optimize the code.
This redundancy will make your app more fault tolerant and resilient. But
again after some level, you will hit some other bottleneck. So, tune your
app as much as you can and hopefully everything will start flying. :)


> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl0BApoACgkQHPApP6U8
> pFgq3xAApCqyUS3DUVwF2PNwhNStms7Y8gbW9A53PInqeu9c7vyM6JN2e8DexccG
> N9ZTZXv8EEYFXSJJasad3S7d57pVON/TgCK/+XNcFLMSajn/6vhNJF6j6WoqRLmo
> rbkSFylG6rKytn1vd8fgw7/o3yeahUbyDHVwn3hY3ZTHXYVO9tM2zgnHe65FB7pO
> M/N9a52NXeObvt9KrssMVHjH7cDBTh6gOAOKq7nVD8qi7S6nU4SLBJn7bhqNRwJc
> vTQfJgq1jEKe2c3O2ynbWckzXzRCqq/rmFWAU8srsdVbBxikzz/W2kIjsWxwQf5s
> sIbzh3ZB03XE0ko+Dnr16DmZMK7uWW+J2IAoQr+XOJnIkz6t7DuV3q/8q0+Q9gnf
> fXya+xK5PJsOoKxxPyqOVw/C6ZdGoPwJDDVlpJR8RrfdozL+zycRC8uIXoHOvr7H
> PoDDwnfzR410d5mXt0vBSXbndJZl/Bjv68bfUfHi5RvJr4GYJtgVqHl71cLD6aSy
> WGacv4rBe+B5LWexDso/Ajb3aE/DB7at+EpB4ZThKlla4Et0K5EVOZ71YAuSfbIO
> /IvSXpZcwa5b1YIZ0Fdrnv5QpBdY0SyuRB8ImhUcqQi46VoYdyao1UbjN72aYPX5
> YpaDnK+EDMLrxOBwdURJUMEUWJUWjrlSvVsZ4DmxqDUBWN4HFDU=
> =q2wh
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message