I am about to setup Tomcat under a new Linux 2.6 kernel with 2 Athlon MP
processors. Since scheduling, threading, and SMP have been much improved
in the new kernel I wonder if it will add to performance.

I don't have anything to test the new setup with, but if anyone has good
ideas (and by good, I mean "easy"), as I haven't done any profiling, etc.

Oscar
http://daydream.stanford.edu/tomcat/install_web_services.html

On Mon, 15 Dec 2003, Sean Dockery wrote:

> Thanks, Tim, for the even handed response.
> 
> I'm not looking for a business case to choose one or the other, however; it
> is certain that our customers will be deploying our application on both
> Linux and Windows (and even Solaris).  I'm just looking to find out whether
> or not OS service (TCP/IP stacks, threads, file I/O, etc...) implementation
> differences between Linux and Windows have a significant impact on
> performance and thus should be weighed accordingly.
> 
> I received a response in email from Peter Lin in which he details his
> experience (which was very helpful; thank you, Peter).  I've read Peter's
> article about performance tuning and a few other white papers as well, but I
> haven't really seen anything in the past that focused on OS differences and
> how those differences might affect the recommended approach to profiling and
> tuning.
> 
> My conclusions from my readings so far:  Slow java code (i.e.: algorithms)
> will be slow on any platform; change the implementation to make it faster.
> Configurable behaviour dependent upon OS services (TCP/IP stacks, threads,
> file I/O, etc...) should be tuned for the platform on which the application
> will live.
> 
> PS:  I was sad to learn that the Tomcat Performance Handbook publishing date
> would be postponed.  I would be thrilled if either you or Peter could tell
> me that the book will see a printer's press anytime soon.
> 
> PPS:  Is there a wiki for this stuff anywhere?
> 
> "Tim Funk" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > [I hate saying this since its rather very much like flambait but...]
> >
> > If its worth anything, I haven't had enough load on any of our apps to
> know
> > whether Linux or Windows is better. Instead, look at:
> > *** - Maintenance - If your a windows shop - stay windows ***
> > - Debugging - I think troubleshooting is easier on *nix systems (YMMV)
> > - Comfort - If your comfortable with unix concepts - linux might be easier
> > than windows
> >
> > -Tim
> >
> > Sean Dockery wrote:
> >
> > > I am planning to profile a web application on Windows XP (my development
> > > platform).  I am curious as to whether or not different components in
> Tomcat
> > > and the JVM will behave differently (in a relative comparison) on Linux
> > > (production platform) than Windows.
> > >
> > > For example, I have had a person tell me that threads under Linux are
> more
> > > performant than threads under Windows--leading to the corollary that web
> > > applications under Linux are more performant than web applications under
> > > Windows on the same hardware.  My guess is that this claim is based upon
> the
> > > supposition that thread/context switches under Linux are faster than
> under
> > > Windows.  I find the claim rather dubious because I've never seen data
> to
> > > support the claim, but doubt is not certainty.
> > >
> > > Is there any evidence that this claim and other component performance
> > > differences between the Windows and Linux platform exist and are
> significant
> > > enough to throw my performance measurements out the "window".  :-)
> > >
> > > My concern is that I'll profile the application under Windows and tune
> it,
> > > but then find that my gains aren't as significant or maybe even
> worthless
> > > under Linux.
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to