You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Henri Gomez <hg...@apache.org> on 2004/07/28 16:23:31 UTC
[Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters
in tomcat-dev]
It seems we didn't got this CC in tc-dev :
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters
in tomcat-dev]
Posted by Brian Pane <br...@apache.org>.
Remy Maucherat wrote:
> Filip Hanik - Dev wrote:
>
>> The Java VM does this through file handling, we would have to find
>> out where it issues this call and if we can get around it. The
>> Tomcat developers are not calling stat anywhere in the code, but the
>> underlying JVM code does, we just don't know where
>>
>>
> Ok. Well, I think there's no such thing, as the test was about a
> servlet. There's also a cache, so it won't go to the HD too often, but
> of course, I don't know how it really works. Also something to
> remember is that the HelloWorld example servlet is a very bad
> throughtput test: it has a very expensive i18n operation (it retrieves
> a resource bundle on each request), which Apache doesn't do. So it
> would be better to either test with a static file, or write a new
> servlet with the same output (minus i18n).
I was testing the delivery of a static file, not a servlet, when I found
the stat calls.
The stats don't happen with servlets in general; it's just the default
static-file handler
service that has this overhead (in Tomcat 5.0.25 and 5.0.27; I haven't
tried any
other versions).
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters
in tomcat-dev]
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev wrote:
>The Java VM does this through file handling, we would have to find out where it issues this call and if we can get around it. The
>Tomcat developers are not calling stat anywhere in the code, but the underlying JVM code does, we just don't know where
>
>
Ok. Well, I think there's no such thing, as the test was about a
servlet. There's also a cache, so it won't go to the HD too often, but
of course, I don't know how it really works. Also something to remember
is that the HelloWorld example servlet is a very bad throughtput test:
it has a very expensive i18n operation (it retrieves a resource bundle
on each request), which Apache doesn't do. So it would be better to
either test with a static file, or write a new servlet with the same
output (minus i18n).
It would be good to test with HEAD (the test was done with 3.3) to see
if the stat issue occurs.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters
in tomcat-dev]
Posted by Kurt Miller <tr...@apache.org>.
From: "Bill Barker" <wb...@wilshire.com>
> From: "Filip Hanik - Dev" <de...@hanik.com>
> > The Java VM does this through file handling, we would have
> > to find out where it issues this call and if we can get around it. The
> > Tomcat developers are not calling stat anywhere in the code, but
> > the underlying JVM code does, we just don't know where
>
> My guess would be File.getCanonicalPath() in FileDirContext.
>
I can confirm from the SCSL 1.4 jdk source that File.getCanonicalPath()
eventually calls realpath(3) in the jdk src. On OpenBSD (and probably all
unixes) realpath(3) causes an lstat on each dir in the path.
-Kurt
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
Posted by Filip Hanik - Dev <de...@hanik.com>.
>There's a cache for that, so canonicalization will happen only once in a
>while. I don't understand how it can possibly be a performance issue.
maybe I am reading the code wrong, but the method file() in FileDirContext creates a new file object each time, so there is no
caching there.
So I guess the caching is on a higher level?
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters
in tomcat-dev]
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
>My guess would be File.getCanonicalPath() in FileDirContext.
>
>
There's a cache for that, so canonicalization will happen only once in a
while. I don't understand how it can possibly be a performance issue.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Filip Hanik - Dev" <de...@hanik.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, July 28, 2004 9:13 AM
Subject: Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD
commiters in tomcat-dev]
> The Java VM does this through file handling, we would have to find out
where it issues this call and if we can get around it. The
> Tomcat developers are not calling stat anywhere in the code, but the
underlying JVM code does, we just don't know where
>
My guess would be File.getCanonicalPath() in FileDirContext.
> Filip
>
> ----- Original Message -----
> From: "David Rees" <dr...@greenhydrant.com>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Wednesday, July 28, 2004 11:08 AM
> Subject: Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD
commiters in tomcat-dev]
>
>
> Remy Maucherat wrote, On 7/28/2004 7:54 AM:
> >>
> >> One thing I noticed when looking at Tomcat 5.0.x is that its default,
> >> static-file-delivering servlet does a stat(2) of each path prefix
leading
> >> up to the file. A standard installation of Apache 2.x, with
> >> FollowSymlinks
> >> enabled, doesn't do these stat calls, for obvious performance reasons.
> >>
> >> Is the stat'ing of all the directories leading up to the requested file
> >> in Tomcat intentional (it *is* valuable in some environments for
> >> security purposes), or is it just a side-effect of the implementation?
> >
> > I really have no idea what this stuff means.
>
> stat is a Unix system call which retrives the status information of a
> file or directory.
>
> Each stat call can potentially hit the disk, so this can be a very
> expensive system call to make if you have deep directory trees and could
> explain some of the performance differences between Apache and Tomcat.
>
> -Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
Posted by Filip Hanik - Dev <de...@hanik.com>.
The Java VM does this through file handling, we would have to find out where it issues this call and if we can get around it. The
Tomcat developers are not calling stat anywhere in the code, but the underlying JVM code does, we just don't know where
Filip
----- Original Message -----
From: "David Rees" <dr...@greenhydrant.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, July 28, 2004 11:08 AM
Subject: Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters in tomcat-dev]
Remy Maucherat wrote, On 7/28/2004 7:54 AM:
>>
>> One thing I noticed when looking at Tomcat 5.0.x is that its default,
>> static-file-delivering servlet does a stat(2) of each path prefix leading
>> up to the file. A standard installation of Apache 2.x, with
>> FollowSymlinks
>> enabled, doesn't do these stat calls, for obvious performance reasons.
>>
>> Is the stat'ing of all the directories leading up to the requested file
>> in Tomcat intentional (it *is* valuable in some environments for
>> security purposes), or is it just a side-effect of the implementation?
>
> I really have no idea what this stuff means.
stat is a Unix system call which retrives the status information of a
file or directory.
Each stat call can potentially hit the disk, so this can be a very
expensive system call to make if you have deep directory trees and could
explain some of the performance differences between Apache and Tomcat.
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters
in tomcat-dev]
Posted by David Rees <dr...@greenhydrant.com>.
Remy Maucherat wrote, On 7/28/2004 7:54 AM:
>>
>> One thing I noticed when looking at Tomcat 5.0.x is that its default,
>> static-file-delivering servlet does a stat(2) of each path prefix leading
>> up to the file. A standard installation of Apache 2.x, with
>> FollowSymlinks
>> enabled, doesn't do these stat calls, for obvious performance reasons.
>>
>> Is the stat'ing of all the directories leading up to the requested file
>> in Tomcat intentional (it *is* valuable in some environments for
>> security purposes), or is it just a side-effect of the implementation?
>
> I really have no idea what this stuff means.
stat is a Unix system call which retrives the status information of a
file or directory.
Each stat call can potentially hit the disk, so this can be a very
expensive system call to make if you have deep directory trees and could
explain some of the performance differences between Apache and Tomcat.
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [Fwd: Re: Some benchs results : WAS: Invitation to HTTPD commiters
in tomcat-dev]
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
> It seems we didn't got this CC in tc-dev :
>
> Henri Gomez wrote:
>
>> I made some benchs on my Linux Fedora Core 2
>> on a P4 2.8ghz / 1Gb RAM :
>
>
>
>> Apache 2 alone 1202 req/s
>> TC/Coyote 883 req/s
>
>
>
> One thing I noticed when looking at Tomcat 5.0.x is that its default,
> static-file-delivering servlet does a stat(2) of each path prefix leading
> up to the file. A standard installation of Apache 2.x, with
> FollowSymlinks
> enabled, doesn't do these stat calls, for obvious performance reasons.
>
> Is the stat'ing of all the directories leading up to the requested file
> in Tomcat intentional (it *is* valuable in some environments for
> security purposes), or is it just a side-effect of the implementation?
I really have no idea what this stuff means.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org