You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2005/05/03 00:59:01 UTC
Re: Initial test of APR on Solaris
Bill Barker wrote:
> I was surprised that it worked at 150. I guess my crappy XP box was too
> slow to give real throughput :).
>
> The OOM message came from ThreadPool, which doesn't log stack traces.
> I'll need to hack ThreadPool to see where it's getting thrown from. The
> box is pretty old and small (which is why it's mostly a test-bed these
> days :), but the memory usage reported by 'top' wasn't that high. It's
> probably some other resource, since Sun throws OOM for everything. I'll
> see if I can find out Monday.
Right, I see the error now. The issue seems to be that the APRized HTTP
connector is apparently using a little more memory than the regular
connector (something like 10% more). Increasing mx fixes it without
further issues (on Windows). The regular HTTP produces the same
stackless OOM with only a few more concurrent requests (350 starts
causing some trouble for me) if using the standard JVM memory settings.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Initial test of APR on Solaris
Posted by Peter Lin <wo...@gmail.com>.
On 5/3/05, Bill Barker <wb...@wilshire.com> wrote:
>
> ----- Original Message -----
> From: "Remy Maucherat" <re...@apache.org>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Tuesday, May 03, 2005 1:43 AM
> Subject: Re: Initial test of APR on Solaris
>
> >Bill Barker wrote:
> >> Yeah, that works for me as well. My problem now is that the APRized HTTP
> >> Connector dies about 70% of the way through a test when I use the
> >> HTTPClient
> >> option in JMeter. A thread-dump shows all of the Workers waiting, and
> >> the
> >> Poller polling, but nothing is happening. It's a bit happier when I
> >
> >There's not much wrong with that situation, since it's a bit hard to tell
> >what the client is doing. Maybe it's the 62 sized poller causing trouble if
> >running on Windows (you should get a message about that), in which case
> >you'd need to build APR from scratch. Is the Acceptor thread still
> >accepting and giving that to the workers ?
>
> Only JMeter is running on Windows, and yes, the Acceptor is still accepting.
> I'm guessing it's a JMeter problem, since it's just too consistant.
I'll try to verify whether this is really an issue with jmeter or
something else.
peter
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Initial test of APR on Solaris
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> I can get the test to finish if I synchronize around the 'Poll.poll'
> statement in the Poller. However, doing this sends the perfomance right
> through the floor :(. I'm guessing it's a problem with doing an add and/or
Yes, it's probably too extreme syncing (100 ms locking) ;)
> remove (most likely remove, since it hangs when test threads are finishing)
> at the same time that it's in the middle of a poll.
Actually, nobody calls the Poller.remove method anymore (poll will
remove returned sockets automatically), so it must be a sync issue with
add. I left the remove method in case Mladen changes his mind.
I did some profiling yesterday, but didn't see anything interesting so far.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Initial test of APR on Solaris
Posted by Mladen Turk <mt...@apache.org>.
Bill Barker wrote:
>
> I can get the test to finish if I synchronize around the 'Poll.poll'
> statement in the Poller. However, doing this sends the perfomance right
> through the floor :(. I'm guessing it's a problem with doing an add and/or
> remove (most likely remove, since it hangs when test threads are finishing)
> at the same time that it's in the middle of a poll.
>
Yes, you are correct with that.
Most APR poll implementations are not thread safe.
Think we'll need to add some sort of queue so that Poll.add,
Poll.remove are done in the same thread as Poll.poll.
If you had a faster box this probably would not be observed :).
The problem is that we are syncing .add and .remove, but the
.poll call if not thread safe can cause a problems.
I'll play with that to see how it can be done in the most
efficient way.
Regards,
Mladen
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Initial test of APR on Solaris
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Bill Barker" <wb...@wilshire.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Tuesday, May 03, 2005 11:30 AM
Subject: Re: Initial test of APR on Solaris
>
> ----- Original Message -----
> From: "Mladen Turk" <mt...@apache.org>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Tuesday, May 03, 2005 9:57 AM
> Subject: Re: Initial test of APR on Solaris
>
>
> > Remy Maucherat wrote:
> > > Bill Barker wrote:
> > >
> > >>> It's hard to tell what is going wrong. Is there logging showing
> > >>> attempted requests and failure codes ?
> > >>
> > >>
> > >> Interestingly, the non-HTTPClient option never seems to get above ~62
> > >> concurrency.
> > >
> > > This looks suspicious to me, as it's the same constant size as the
> > > poller on Windows. Maybe Mladen will have ideas.
> > >
> >
> > Well, I never tried the code on Solaris, so really can not tell.
> > The number looks pretty much like on windows where non-patched
> > apr supports only 63 pollable sockets.
> >
>
> It has to be something with the 1.4 JVM on my XP box, since from the docs
> it's using j.n.URLConnection. What I see is a low thread-count on the
Java
> Connector, which means that there aren't very many connections active.
With
> the HTTPClient, the thread count happily goes up to the number of threads
on
> the test.
>
> > I hope I'll have my hands on some Solaris box pretty soon, so I'll
> > see what is the problem.
> >
I can get the test to finish if I synchronize around the 'Poll.poll'
statement in the Poller. However, doing this sends the perfomance right
through the floor :(. I'm guessing it's a problem with doing an add and/or
remove (most likely remove, since it hangs when test threads are finishing)
at the same time that it's in the middle of a poll.
>
> My test box is Solaris7 (the shiny new ones are in production, so I can't
> use them for testing :). It would be interesting if somebody could try it
> out on a version that isn't a museum piece ;-).
>
> > Regards,
> > Mladen.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
>
>
>
> This message is intended only for the use of the person(s) listed above as
the intended recipient(s), and may contain information that is PRIVILEGED
and CONFIDENTIAL. If you are not an intended recipient, you may not read,
copy, or distribute this message or any attachment. If you received this
communication in error, please notify us immediately by e-mail and then
delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
>
>
>
----------------------------------------------------------------------------
----
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
Re: Initial test of APR on Solaris
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Mladen Turk" <mt...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Tuesday, May 03, 2005 9:57 AM
Subject: Re: Initial test of APR on Solaris
> Remy Maucherat wrote:
> > Bill Barker wrote:
> >
> >>> It's hard to tell what is going wrong. Is there logging showing
> >>> attempted requests and failure codes ?
> >>
> >>
> >> Interestingly, the non-HTTPClient option never seems to get above ~62
> >> concurrency.
> >
> > This looks suspicious to me, as it's the same constant size as the
> > poller on Windows. Maybe Mladen will have ideas.
> >
>
> Well, I never tried the code on Solaris, so really can not tell.
> The number looks pretty much like on windows where non-patched
> apr supports only 63 pollable sockets.
>
It has to be something with the 1.4 JVM on my XP box, since from the docs
it's using j.n.URLConnection. What I see is a low thread-count on the Java
Connector, which means that there aren't very many connections active. With
the HTTPClient, the thread count happily goes up to the number of threads on
the test.
> I hope I'll have my hands on some Solaris box pretty soon, so I'll
> see what is the problem.
>
My test box is Solaris7 (the shiny new ones are in production, so I can't
use them for testing :). It would be interesting if somebody could try it
out on a version that isn't a museum piece ;-).
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
Re: Initial test of APR on Solaris
Posted by Mladen Turk <mt...@apache.org>.
Remy Maucherat wrote:
> Bill Barker wrote:
>
>>> It's hard to tell what is going wrong. Is there logging showing
>>> attempted requests and failure codes ?
>>
>>
>> Interestingly, the non-HTTPClient option never seems to get above ~62
>> concurrency.
>
> This looks suspicious to me, as it's the same constant size as the
> poller on Windows. Maybe Mladen will have ideas.
>
Well, I never tried the code on Solaris, so really can not tell.
The number looks pretty much like on windows where non-patched
apr supports only 63 pollable sockets.
I hope I'll have my hands on some Solaris box pretty soon, so I'll
see what is the problem.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Initial test of APR on Solaris
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
>> It's hard to tell what is going wrong. Is there logging showing
>> attempted requests and failure codes ?
>
> Interestingly, the non-HTTPClient option never seems to get above ~62
> concurrency.
This looks suspicious to me, as it's the same constant size as the
poller on Windows. Maybe Mladen will have ideas.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Initial test of APR on Solaris
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Tuesday, May 03, 2005 1:43 AM
Subject: Re: Initial test of APR on Solaris
>Bill Barker wrote:
>> Yeah, that works for me as well. My problem now is that the APRized HTTP
>> Connector dies about 70% of the way through a test when I use the
>> HTTPClient
>> option in JMeter. A thread-dump shows all of the Workers waiting, and
>> the
>> Poller polling, but nothing is happening. It's a bit happier when I
>
>There's not much wrong with that situation, since it's a bit hard to tell
>what the client is doing. Maybe it's the 62 sized poller causing trouble if
>running on Windows (you should get a message about that), in which case
>you'd need to build APR from scratch. Is the Acceptor thread still
>accepting and giving that to the workers ?
Only JMeter is running on Windows, and yes, the Acceptor is still accepting.
I'm guessing it's a JMeter problem, since it's just too consistant.
>
>> restrict maxThreads, but it still doesn't finish. The Java HTTP
>> Connector
>> finishes the test fine.
>>
>> Not using the HTTPClient option works Ok, but the actual concurrency
>> level
>> is much lower.
>
>It's hard to tell what is going wrong. Is there logging showing attempted
>requests and failure codes ?
>
Interestingly, the non-HTTPClient option never seems to get above ~62
concurrency.
>Rémy
>
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
Re: Initial test of APR on Solaris
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> Yeah, that works for me as well. My problem now is that the APRized HTTP
> Connector dies about 70% of the way through a test when I use the HTTPClient
> option in JMeter. A thread-dump shows all of the Workers waiting, and the
> Poller polling, but nothing is happening. It's a bit happier when I
There's not much wrong with that situation, since it's a bit hard to
tell what the client is doing. Maybe it's the 62 sized poller causing
trouble if running on Windows (you should get a message about that), in
which case you'd need to build APR from scratch. Is the Acceptor thread
still accepting and giving that to the workers ?
> restrict maxThreads, but it still doesn't finish. The Java HTTP Connector
> finishes the test fine.
>
> Not using the HTTPClient option works Ok, but the actual concurrency level
> is much lower.
It's hard to tell what is going wrong. Is there logging showing
attempted requests and failure codes ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Initial test of APR on Solaris
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Monday, May 02, 2005 3:59 PM
Subject: Re: Initial test of APR on Solaris
>Bill Barker wrote:
>> I was surprised that it worked at 150. I guess my crappy XP box was too
>> slow to give real throughput :).
>>
>> The OOM message came from ThreadPool, which doesn't log stack traces.
>> I'll need to hack ThreadPool to see where it's getting thrown from. The
>> box is pretty old and small (which is why it's mostly a test-bed these
>> days :), but the memory usage reported by 'top' wasn't that high. It's
>> probably some other resource, since Sun throws OOM for everything. I'll
>> see if I can find out Monday.
>
>Right, I see the error now. The issue seems to be that the APRized HTTP
>connector is apparently using a little more memory than the regular
>connector (something like 10% more). Increasing mx fixes it without
>further issues (on Windows). The regular HTTP produces the same
>stackless OOM with only a few more concurrent requests (350 starts
>causing some trouble for me) if using the standard JVM memory settings.
>
Yeah, that works for me as well. My problem now is that the APRized HTTP
Connector dies about 70% of the way through a test when I use the HTTPClient
option in JMeter. A thread-dump shows all of the Workers waiting, and the
Poller polling, but nothing is happening. It's a bit happier when I
restrict maxThreads, but it still doesn't finish. The Java HTTP Connector
finishes the test fine.
Not using the HTTPClient option works Ok, but the actual concurrency level
is much lower.
>Rémy
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.