Rick Knowles <[EMAIL PROTECTED]> wrote:
>
> They were in the process of switching to Catalina when I spoke to them.
>
> Moral of the story is well done guys :).
And... KUDOS to Craig :) :) :)
Pier
--
Pier Fu
I know some guys at probably the biggest dot com in Japan (fill in the
blanks), who tried out servlet engines looking for the elusive
"next-generation" engine.
They said they tried Weblogic, JRun and another one I can't remember as well
as tomcat. they found that with the same code, they were able
[EMAIL PROTECTED] wrote:
>
> > I need to choose for my company the "next generation" servlet-engine.
> > For now we are using JRUN. I am doing benchmark to choose the next one.
> > choices for me are : JRUN, RESIN... not Tomcat as it is considered not
> > stable
> > and slow compare to the two
Andy
-Original Message-
From: GOMEZ Henri
To: [EMAIL PROTECTED]
Sent: 3/3/01 6:54 PM
Subject: RE: Some benchmarks
>> I need to choose for my company the "next generation" servlet-engine.
>> For now we are using JRUN. I am doing benchmark to choose
>the next
>> I need to choose for my company the "next generation" servlet-engine.
>> For now we are using JRUN. I am doing benchmark to choose
>the next one.
>> choices for me are : JRUN, RESIN... not Tomcat as it is
>considered not
>> stable
>> and slow compare to the two others...
When you say that T
> I need to choose for my company the "next generation" servlet-engine.
> For now we are using JRUN. I am doing benchmark to choose the next one.
> choices for me are : JRUN, RESIN... not Tomcat as it is considered not
> stable
> and slow compare to the two others...
What version of tomcat did y
I need to choose for my company the "next generation" servlet-engine.
For now we are using JRUN. I am doing benchmark to choose the next one.
choices for me are : JRUN, RESIN... not Tomcat as it is considered not
stable
and slow compare to the two others...
my tests are done with LoadRunner and
Hi, Costin.
[EMAIL PROTECTED] wrote:
> Could you try again to run the test with 3.3 ( the next nightly build
> ) and Ajp13 ?
>
>> 3.3.m1 Ajp13 (952/488)
>
>
> I did few changes and at least on my machine is now 30..50% better,
> but it would be great if you could check.
Here it is (stil
> Hi all.
>
> Here are the results of some measurements made with ab on Tomcat
> versions 3.2.1, 3.3.m1 and 4.0.b1 with different JDKs.
Hi,
Could you try again to run the test with 3.3 ( the next nightly build
) and Ajp13 ?
> 3.3.m1 Ajp13 (952/488)
I did few changes and at least on my ma
Nick,
> Why in the WORLD should anyone be serving static html from tomcat through
> the connector from Apache? Working to improve performance of this kind of
> behavior, in my mind, is a total sillyness. A waste of your time. They
> should instead configure Apache to serve html itself and only
Costin,
Why in the WORLD should anyone be serving static html from tomcat through
the connector from Apache? Working to improve performance of this kind of
behavior, in my mind, is a total sillyness. A waste of your time. They
should instead configure Apache to serve html itself and only pass
> At c=10:
> 3.3.m1 Ajp12 (956/338)
> 3.3.m1 Ajp13 (966/390)
>
> At c=100:
> 3.3.m1 Ajp12 (920/343)
> 3.3.m1 Ajp13 (929/393)
Not good
I guess we can focus on ajp13 and do few changes, fixing both doesn't
make sense.
Mea culpa, I did a lot of tests/optimizations on stand
GOMEZ Henri wrote:
>
> It wasn't clear that Apache handled direclty the /test.html or forward
> that to tomcat. Could you do so something like test to
> /examples/test.html ?
> Something passed via ajp12/13 to tomcat and handled by tomcat ?
Here it is. Targets are /test.html and /examples/te
>GOMEZ Henri wrote:
>
>> Could you play the static test only, on the same box,
>against Apache only ?
>>
>>> 3.2.1 Ajp12 (940/407)
>>> 3.3.m1 Ajp12 (960/421)
>>> 3.3.m1 Ajp13 (952/488)
>>
>
>You already have the results of Apache standalone: 940 - 960
>req/s. The
>test target
GOMEZ Henri wrote:
> Could you play the static test only, on the same box, against Apache only ?
>
>> 3.2.1 Ajp12 (940/407)
>> 3.3.m1 Ajp12 (960/421)
>> 3.3.m1 Ajp13 (952/488)
>
You already have the results of Apache standalone: 940 - 960 req/s. The
test target in the Ajp12 an
I'll try to replay the tests but with Apache 2.0-alpha11 to see
how Apache react. I like to see why Apache 2.0 + mod_jk + ajp12/13
is still slower that direct http connector.
Could you play the static test only, on the same box, against Apache only ?
Just to see what could be the result :
>Tom
[EMAIL PROTECTED] wrote:
> > When ajp14 is developed, the spec should really contain a standard response
> > for an "unknown packet", so new packet types (or messages) can be added to
> > the protocol without breaking backward compatability. If we had this in
> > ajp13, we could add some very nic
> We're still shaking weird little bugs out of the ajp13 implementation(s),
> and people are relying on it for production use. I don't think we should
> muck around with the protocol itself.
>
> When ajp14 is developed, the spec should really contain a standard response
> for an "unknown packet"
> Now the only performance issue on my list is mod_jk ( the java side still
> need work to improve a bit the performance ). But fixing the bugs and
> making tomcat easier to use is far more important - and the connector
> module can be released independently, as a standalone module ( i.e. after
>
> >
> > Suggestions for improving the tests are welcome.
>
> Please test Resin and Orion too, next we will beat'em..
As I said, setting goals and stopping when you reach them is very
important ( and hard ).
Beeing faster than Resin or Orion was not my goal - running at a speed
comparable with
>As I said, setting goals and stopping when you reach them is very
>important ( and hard ).
>
>Beeing faster than Resin or Orion was not my goal - running at a speed
>comparable with Apache standalone and mod_perl was, and I think we are
>there.
Are we fastest now the ApacheJServ 1.1.2 ?
>Now th
> As I said, setting goals and stopping when you reach them is very
> important ( and hard ).
>
Yep, but is good to know where we are actually...
Saludos ,
Ignacio J. Ortega
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For a
price, though...
Steve
> -Original Message-
> From: Alex Fernández [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 21, 2001 2:31 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Some benchmarks
>
>
> Costin:
>
> Is there any way to find out how many objects
> Costin:
>
> Is there any way to find out how many objects are created in the JVM?
>
> I remember seeing something similar on a pre-release version of MacOS X: it
> sampled the number of objects of the different core classes that were
> allocated at any moment.
>
> Otherwise, how do you find o
Hola a todos, Rolf:
>
> Tomcat version(IBM-JDK | Sun-JDK | Blackdown-JDK )
> 3.2.1 standalone (668/994 | 491/783 | 463/749)
> 3.3.m1 standalone (759/1294 | 556/1158 | 544/1107)
Whow yeah believe sometimes is good.., Thanks Costin..( the man
behind every ab request :)
> 4.0.b1 stan
Costin:
Is there any way to find out how many objects are created in the JVM?
I remember seeing something similar on a pre-release version of MacOS X: it
sampled the number of objects of the different core classes that were
allocated at any moment.
Otherwise, how do you find out how many object
Matthew Dornquast wrote:
> Put a "-server" in the command line for running tomcat when using the sun
> jdk.
Costin Manolache wrote:
> Yes, I would be very interested in the results with a simple JSP.
Thanks, Matthew and Costin. I take note for the next batch of tests.
Rolf.
--- Alex Fernández <[EMAIL PROTECTED]> wrote:
> I think the benchmarks are very interesting. Unfortunately, the
> results from HelloWorld don't seem too revealing.
Depends what you want to measure - HelloWorld shows one number, the
container overhead. For any servlet that does something more you
> Suggestions for improving the tests are welcome.
Ah! I think I have the solution to the poor showing for the Sun SDK 1.3
I ran into this same doing my own tests with Synchronization & object
creation/GC on Linux, Solaris using Sun + IBM JDKs.
Sun decided to ship their SDK with the JIT defaul
Hola, Alex.
Alex Fernández wrote:
> Why don't you run those same tests with other example pages included in the
> distribution. (At least the ones included in *some* distribution, probably
> they're different across releases.) They should be more complex, and exploit
> most features of servlets.
I think the benchmarks are very interesting. Unfortunately, the results from
HelloWorld don't seem too revealing.
Why don't you run those same tests with other example pages included in the
distribution. (At least the ones included in *some* distribution, probably
they're different across release
31 matches
Mail list logo
