• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Tunning tomcat .

 
Ranch Hand
Posts: 226
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello poeple,
I know this is a kinda religious question, but what are the "generic" tunes for tomcat that work generally on all the applications?
I think that increasing the heap memory from the default value is a good idea, so is the case of the No of threads (coz I have many concurrent users, but the many receive the same data that does not require a lot of business logic)..
Any suggestions for performance ? and security? I mean what are the first easy steps that must be done to change THE DEFAULT TOMCAT configurration?
Help is appreciated.
Thanks in advance
 
Ranch Hand
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
remove these apps:
examples
docs
webdav
admin

That last one, is a 'personal choice'. I never use the admin app, but I ocassionaly use the manager. If you find you use neither , or both, adjust accordingly.

Increased heap size may not be a bad idea, but then again... there *is* such a thing as 'too much of a good thing'.

The other thing I have for you.. do you have a way to effectively test each of your tweaks? Is there a load test script ? You should have one, you should have a 'goal' in mind, and you should tweak one thing at a time, test, test, test, and then *stop* when you reach your goal.

There's also your own code to consider. Has that been profiled ?
 
Tonny Tssagovic
Ranch Hand
Posts: 226
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the reply Mike

Originally posted by Mike Curwen:

do you have a way to effectively test each of your tweaks? Is there a load test script ?


Well I don't know what u mean by effective testing, for now I just think that I will change a parameter (for example no of threads) and test and change and test and .... I really don't know if this is the way, but it seems really a boring and repetitive task (things that really should be automated :roll: ) especially if I have to change say 3 parameters say 3 times, one at a time it is gonna be really boring .-- isn't there a better way?
I have a load test made using JMeter, but I really don't know if it really imitates the real users behaviour (how can I guess for a new app ), for example let's assume I know that there might be 10000 clients accessing my application once a minute (polling for new data) at a certain event... but how can I guess the time that these users will be added up .. what is the probability of them all joining at the same second :roll: or joining 1000 / minut ?? This is especially confusing when taking in consideration that the application is new
 
Mike Curwen
Ranch Hand
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yes, tuning is boring and repetitive. But it's also worthwhile.

As for 'is there a better way than changing one setting at a time'? Not really. There is definitely a faster way. But not 'better'.

If you change 3 things, and you get 60% increase in response, which of the three things accounts for how much of the increase? Perhaps you only needed to change 2 things. Perhaps 1 of the 3 actually results in a 10% drop. You could have had 70%, if only you had taken it slowly.

Ok, that's all very simplistic, but you get the idea?

If you want, you can change a whole bunch of "likely suspects" (ie: heap, threads, gc settings). Then use this as your new baseline. Load test that, and get a response rate. Then change the threads up or down, and test after each change. You get the feeling for how "changing threads" affects response.

As for a brand new app.. you're right, there's nothing historical to go on. You'll have to go with the 'most likely' load and usage scenario. If it's just you, and the app is not "important", then you can take a best guess. Err on the side of over-estimating the load, and you'll have the wiggle room later. On the other hand, if this is a big project, and "important", then that's a different story.

If it's a "must have" app, that simply *cannot* go down, and it simply *cannot* have more than 2 second response time, then you ought to have some help from those people doing the insisting. They should be answering questions like: Under how much load? At what times of the day? Will they buy additional hardware to support their demands? Can the response time be variant, but within acceptable ranges? Additionaly, you'll want to know how many scenarios there are.

I'll give you an example. Where I used to work, we did a news/community portal site. We needed certain response times, under 3 distinct loads.
"normal" load was what our logs showed us was a typical day. There was a peak at 9am for morning weather and news headlines. Then between 11:30 and 1:00 there was another peak, mostly for news. Then another large peak around 4:30 for news and entertainment, movie listings and weather. All other times during the day, the load was about 'x'.
"heavy" days. Basically, take the site load, and increase by half, and double the peaks. So now our 'ambient' load is 1.5x, and our peaks are twice as high as they were. These days were usually on Fridays and Mondays. We speculated that Monday was a "yuck, I hate being at work, lets surf" and Friday was "It's almost the weekend, lets surf". We also noted that the entertainment/movie listing got hit quite a bit more on the Friday afternoon peak. (no duh).
"disaster" is the last day we looked at. I don't mean to be crude, but we basically took our traffic log for 9/11. These are the days when "something happens" and everyone and I mean *everyone* is on the internet, trying to find stuff out. We loaded the site with between 10x and 15x, for 6 hours with no breaks. We loaded the front page and 2 news pages (simulating hitting the front url and clicking two links deep). Our ramp up was 30 minutes; we went from 'normal' to 'disaster' load in 30 minutes. (this was probably being generous). Now on that exact day, because we were not ready for this kind of day, we had to bring down the dynamic system and put up static pages (much like other sites did). So our sponsors were understanding that this type of day was an 'edge case', and we were allowed to let the response time slip. But they still wanted to know the performance profile.

Note in some descriptions above I talk about 'ramp up'. This is like your question regarding "how many at the same time?". It's *extremely unlikely* your site will be hit with *all* its users at once. So again, either get this information from the sponsor, or take your best guess. Maybe even test 3 or 4 different ramp-up scenarios.

If you're the developer, and some business type insists on a certain response time, then you have to pin them down on the load scenarios. Because that becomes your testing target. You use your jmeter tests, and simulate those scenarios. Think about how at certain times, certain areas of the site are used more, or less. Viewing the home page - how many people do it? (or do they bookmark the page they want, and later, come back through the bookmark?). At what times, and for how long, and under what load, do people use the most database? (ie: the more dynamic pages, as opposed to the more static ones). Do you use any sort of caching (db results, partial page results, full page results), and be sure to exercise it in your tests. And don't short-cut these tests, if they're *that* important. Load tests can occur over hours. Our "normal" and "heavy" load test for the above site, took 12 hours to complete. We were trying to simulate the *real* site usage. We knew that the server would behave differently over many hours (some stressful, some not), rather than over a few stressful hours. For example, jvm garbage collection will behave differently. So that's just one reason why you can't simulate a long haul with short hauls and higher numbers.

If you fall well within the performance targets of your expected usage scenarios, then your work is done. You cross your fingers and hope the production load profile is close to the tested load profile.
 
Tonny Tssagovic
Ranch Hand
Posts: 226
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for ur time Mike
 
reply
    Bookmark Topic Watch Topic
  • New Topic