You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/08/09 18:23:53 UTC
Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon
Load Tests)
Vadim Gritsenko wrote:
>
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Thursday, August 09, 2001 11:23 AM
> > To: cocoon-dev@xml.apache.org
> > Subject: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
> >
> >
> > Berin Loritsch wrote:
> > >
> > > My initial JMeter load tests show no error messages and plenty of reason to smile.
> > > I simulated 20 users each hitting the server every 300ms. When the JVM was in
> > > a garbage collection cycle, the longest response time was 842ms. During normal
> > > opperation, responses were between 0ms and 20ms (55% at 0, 40% at 10, 5% at 20)
> > > with occasional spikes around 100ms.
> > >
> > > I am going to up the JMeter load test to allow for 100 simultaneous users just to
> > > try and break it.
> >
> > I ran it with 100 simultaneous users--and the longest processing times were still
> > less than 1.6 seconds (my magic "it takes too long on the server" time).
> >
> > I wasn't satisfied, so I went with 200 simultaneous users. My longest processing
> > time was 3.135 seconds with one Resin Server through Apache, on a 750 MHz Athlon
> > and 256 MB RAM.
> >
>
> I assume this results are for static resource (/welcome?), how about dynamic resources?
> (simple sql or esql)?
I'll let you know in a bit. in the mean time, run some tests of your own and give some
feedback.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon
Load Tests)
Posted by Berin Loritsch <bl...@apache.org>.
Vadim Gritsenko wrote:
>
> Hm, with JDK1.3.1 I have got some interesting info; may be it can help you to find the problem.
> And may be not. :-/
I wonder if there are issues getting the builtin logicsheets from the jar under extreme load...
Checking the logs, I am seeing the same EXCEPTION_ACCESS_VIOLATION message--though I don't get
a stacktrace.
>
> ------------------------------
> An unexpected exception has been detected in native code outside the VM.
> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6d3c76aa
> Function name=ZIP_Open
> Library=C:\Java\jdk1.3.1\jre\bin\zip.dll
>
> Current Java thread:
> at java.util.zip.ZipFile.getEntry(Native Method)
> at java.util.zip.ZipFile.getEntry(ZipFile.java:146)
> at com.caucho.vfs.Jar.getJarEntry(Jar.java:346)
> at com.caucho.vfs.Jar.getSafeJarEntry(Jar.java:325)
> at com.caucho.vfs.Jar.isFile(Jar.java:142)
> at com.caucho.vfs.Jar.canRead(Jar.java:207)
> at com.caucho.vfs.JarPath.canRead(JarPath.java:145)
> at com.caucho.util.DirectoryClassLoader.getPath(DirectoryClassLoader.java:213)
> at com.caucho.util.DynamicClassLoader.getResourceAsStream(DynamicClassLoader.java:566)
> at org.apache.xml.dtm.DTMManager.findFactory(DTMManager.java:474)
> at org.apache.xml.dtm.DTMManager.newInstance(DTMManager.java:175)
> at org.apache.xpath.XPathContext.reset(XPathContext.java:337)
> at org.apache.xalan.transformer.TransformerImpl.reset(TransformerImpl.java:469)
> at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1197)
> at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3094)
> at org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:467)
> at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:52)
> at org.apache.cocoon.generation.ServerPagesGenerator.endDocument(ServerPagesGenerator.java:253)
> at www.docs.samples.xsp.simple_xsp.generate(simple_xsp.java:406)
> at org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGenerator.java:183)
> at org.apache.cocoon.components.pipeline.CachingEventPipeline.process(CachingEventPipeline.java:219)
> at org.apache.cocoon.components.pipeline.CachingStreamPipeline.process(CachingStreamPipeline.java:363)
> at www.sitemap_xmap.wildcardMatchN41A(sitemap_xmap.java:5557)
> at www.sitemap_xmap.process(sitemap_xmap.java:2453)
> at www.sitemap_xmap.process(sitemap_xmap.java:2094)
> at org.apache.cocoon.sitemap.Handler.process(Handler.java:160)
> at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:103)
> at org.apache.cocoon.Cocoon.process(Cocoon.java:423)
> at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:518)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:103)
> at com.caucho.server.http.FilterChainServlet.doFilter(FilterChainServlet.java:82)
> at com.caucho.server.http.Invocation.service(Invocation.java:272)
> at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:216)
> at com.caucho.server.http.HttpRequest.handleConnection(HttpRequest.java:158)
> at com.caucho.server.TcpConnection.run(TcpConnection.java:140)
> at java.lang.Thread.run(Thread.java:484)
> ----------------------------------------
>
> Vadim
>
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Thursday, August 09, 2001 2:37 PM
> > To: cocoon-dev@xml.apache.org
> > Subject: Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
> >
> >
> > Stuart Roebuck wrote:
> > >
> > > That sounds like a problem I'm just having too, I've got quite a bit of
> > > XSP in my test cases, and Tomcat is just dieing without any errors
> > > displayed at all. In fact I've looked in every log I can think of (tomcat,
> > > cocoon, system) and I can't see any evidence of anything going wrong!
> > >
> > > Stuart.
> > >
> > > On Thursday, August 9, 2001, at 07:11 pm, Vadim Gritsenko wrote:
> > >
> > > > I found a problem:
> > > >
> > > > Cocoon takes all available memory after ~ 500-600 accesses to
> > > > http://localhost:8080/cocoon/xsp/simple
> > > > and Resin crashes:
> > > > #
> > > > # An EXCEPTION_ACCESS_VIOLATION exception has been detected in native
> > > > code outside the VM.
> > > > # Program counter=0x50397707
> > > > #
> > > >
> > > > Clearly, something is wrong with XSP... Some resources are not released.
> > > > cocoon.log file does not have any errors.
> > > >
> > > > Berin,
> > > > could you verify this behaviour?
> >
> > Ok, I verified it. Let me do some more checking--the issues in this
> > case lie on the Cocoon side of things. I _think_ I have an idea
> > what it is--but no guarantees.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo yourCocoon Load Tests)
Posted by Vadim Gritsenko <vg...@hns.com>.
Donald,
You are right about Resin: it have a problem with Zip files...
Under Tomcat (4.0b5) I have got another interesting exception:
2001-08-09 15:59:25 StandardWrapperValve[Cocoon2]: Servlet.service() for servlet Cocoon2 threw exception
java.lang.NullPointerException
at org.apache.cocoon.components.source.URLSource.getInfos(URLSource.java:100)
at org.apache.cocoon.components.source.URLSource.getLastModified(URLSource.java:115)
at org.apache.cocoon.Cocoon.modifiedSince(Cocoon.java:320)
at org.apache.cocoon.servlet.CocoonServlet.getCocoon(CocoonServlet.java:719)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:461)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:254)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:194)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:255)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:225)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2252)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:875)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:952)
at java.lang.Thread.run(Thread.java:484)
This is from tomcat.log, cocoon.log is empty. URL is /cocoon/xsp/simple, 50 threads, gaussian timer on 100ms.
I have got 17 exceptions per 1900 processed requests.
Is it possible that URLSource object is used by more then one thread?
Vadim
> -----Original Message-----
> From: Donald Ball [mailto:balld@webslingerZ.com]
> Sent: Thursday, August 09, 2001 3:14 PM
> To: cocoon-dev@xml.apache.org
> Subject: RE: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo yourCocoon Load Tests)
>
>
> On Thu, 9 Aug 2001, Vadim Gritsenko wrote:
>
> > Hm, with JDK1.3.1 I have got some interesting info; may be it can help you to find the problem.
> > And may be not. :-/
> >
> > ------------------------------
> > An unexpected exception has been detected in native code outside the VM.
> > Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6d3c76aa
> > Function name=ZIP_Open
> > Library=C:\Java\jdk1.3.1\jre\bin\zip.dll
> >
> > Current Java thread:
> > at java.util.zip.ZipFile.getEntry(Native Method)
> > at java.util.zip.ZipFile.getEntry(ZipFile.java:146)
> > at com.caucho.vfs.Jar.getJarEntry(Jar.java:346)
> > at com.caucho.vfs.Jar.getSafeJarEntry(Jar.java:325)
> > at com.caucho.vfs.Jar.isFile(Jar.java:142)
> > at com.caucho.vfs.Jar.canRead(Jar.java:207)
>
> i think you've probably found a synchronization bug in resin, actually.
> there was a little thread about this on resin-interest a few days ago. do
> you get the same results in tomcat? you might want to post this stacktrace
> to resin-interest.
>
> - donald
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your
Cocoon Load Tests)
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 9 Aug 2001, Vadim Gritsenko wrote:
> Hm, with JDK1.3.1 I have got some interesting info; may be it can help you to find the problem.
> And may be not. :-/
>
> ------------------------------
> An unexpected exception has been detected in native code outside the VM.
> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6d3c76aa
> Function name=ZIP_Open
> Library=C:\Java\jdk1.3.1\jre\bin\zip.dll
>
> Current Java thread:
> at java.util.zip.ZipFile.getEntry(Native Method)
> at java.util.zip.ZipFile.getEntry(ZipFile.java:146)
> at com.caucho.vfs.Jar.getJarEntry(Jar.java:346)
> at com.caucho.vfs.Jar.getSafeJarEntry(Jar.java:325)
> at com.caucho.vfs.Jar.isFile(Jar.java:142)
> at com.caucho.vfs.Jar.canRead(Jar.java:207)
i think you've probably found a synchronization bug in resin, actually.
there was a little thread about this on resin-interest a few days ago. do
you get the same results in tomcat? you might want to post this stacktrace
to resin-interest.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
Posted by Vadim Gritsenko <vg...@hns.com>.
Hm, with JDK1.3.1 I have got some interesting info; may be it can help you to find the problem.
And may be not. :-/
------------------------------
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6d3c76aa
Function name=ZIP_Open
Library=C:\Java\jdk1.3.1\jre\bin\zip.dll
Current Java thread:
at java.util.zip.ZipFile.getEntry(Native Method)
at java.util.zip.ZipFile.getEntry(ZipFile.java:146)
at com.caucho.vfs.Jar.getJarEntry(Jar.java:346)
at com.caucho.vfs.Jar.getSafeJarEntry(Jar.java:325)
at com.caucho.vfs.Jar.isFile(Jar.java:142)
at com.caucho.vfs.Jar.canRead(Jar.java:207)
at com.caucho.vfs.JarPath.canRead(JarPath.java:145)
at com.caucho.util.DirectoryClassLoader.getPath(DirectoryClassLoader.java:213)
at com.caucho.util.DynamicClassLoader.getResourceAsStream(DynamicClassLoader.java:566)
at org.apache.xml.dtm.DTMManager.findFactory(DTMManager.java:474)
at org.apache.xml.dtm.DTMManager.newInstance(DTMManager.java:175)
at org.apache.xpath.XPathContext.reset(XPathContext.java:337)
at org.apache.xalan.transformer.TransformerImpl.reset(TransformerImpl.java:469)
at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1197)
at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3094)
at org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:467)
at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:52)
at org.apache.cocoon.generation.ServerPagesGenerator.endDocument(ServerPagesGenerator.java:253)
at www.docs.samples.xsp.simple_xsp.generate(simple_xsp.java:406)
at org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGenerator.java:183)
at org.apache.cocoon.components.pipeline.CachingEventPipeline.process(CachingEventPipeline.java:219)
at org.apache.cocoon.components.pipeline.CachingStreamPipeline.process(CachingStreamPipeline.java:363)
at www.sitemap_xmap.wildcardMatchN41A(sitemap_xmap.java:5557)
at www.sitemap_xmap.process(sitemap_xmap.java:2453)
at www.sitemap_xmap.process(sitemap_xmap.java:2094)
at org.apache.cocoon.sitemap.Handler.process(Handler.java:160)
at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:103)
at org.apache.cocoon.Cocoon.process(Cocoon.java:423)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:518)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:103)
at com.caucho.server.http.FilterChainServlet.doFilter(FilterChainServlet.java:82)
at com.caucho.server.http.Invocation.service(Invocation.java:272)
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:216)
at com.caucho.server.http.HttpRequest.handleConnection(HttpRequest.java:158)
at com.caucho.server.TcpConnection.run(TcpConnection.java:140)
at java.lang.Thread.run(Thread.java:484)
----------------------------------------
Vadim
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, August 09, 2001 2:37 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
>
>
> Stuart Roebuck wrote:
> >
> > That sounds like a problem I'm just having too, I've got quite a bit of
> > XSP in my test cases, and Tomcat is just dieing without any errors
> > displayed at all. In fact I've looked in every log I can think of (tomcat,
> > cocoon, system) and I can't see any evidence of anything going wrong!
> >
> > Stuart.
> >
> > On Thursday, August 9, 2001, at 07:11 pm, Vadim Gritsenko wrote:
> >
> > > I found a problem:
> > >
> > > Cocoon takes all available memory after ~ 500-600 accesses to
> > > http://localhost:8080/cocoon/xsp/simple
> > > and Resin crashes:
> > > #
> > > # An EXCEPTION_ACCESS_VIOLATION exception has been detected in native
> > > code outside the VM.
> > > # Program counter=0x50397707
> > > #
> > >
> > > Clearly, something is wrong with XSP... Some resources are not released.
> > > cocoon.log file does not have any errors.
> > >
> > > Berin,
> > > could you verify this behaviour?
>
> Ok, I verified it. Let me do some more checking--the issues in this
> case lie on the Cocoon side of things. I _think_ I have an idea
> what it is--but no guarantees.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon
Load Tests)
Posted by Berin Loritsch <bl...@apache.org>.
Stuart Roebuck wrote:
>
> That sounds like a problem I'm just having too, I've got quite a bit of
> XSP in my test cases, and Tomcat is just dieing without any errors
> displayed at all. In fact I've looked in every log I can think of (tomcat,
> cocoon, system) and I can't see any evidence of anything going wrong!
>
> Stuart.
>
> On Thursday, August 9, 2001, at 07:11 pm, Vadim Gritsenko wrote:
>
> > I found a problem:
> >
> > Cocoon takes all available memory after ~ 500-600 accesses to
> > http://localhost:8080/cocoon/xsp/simple
> > and Resin crashes:
> > #
> > # An EXCEPTION_ACCESS_VIOLATION exception has been detected in native
> > code outside the VM.
> > # Program counter=0x50397707
> > #
> >
> > Clearly, something is wrong with XSP... Some resources are not released.
> > cocoon.log file does not have any errors.
> >
> > Berin,
> > could you verify this behaviour?
Ok, I verified it. Let me do some more checking--the issues in this
case lie on the Cocoon side of things. I _think_ I have an idea
what it is--but no guarantees.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
Posted by Stuart Roebuck <st...@adolos.co.uk>.
That sounds like a problem I'm just having too, I've got quite a bit of
XSP in my test cases, and Tomcat is just dieing without any errors
displayed at all. In fact I've looked in every log I can think of (tomcat,
cocoon, system) and I can't see any evidence of anything going wrong!
Stuart.
On Thursday, August 9, 2001, at 07:11 pm, Vadim Gritsenko wrote:
> I found a problem:
>
> Cocoon takes all available memory after ~ 500-600 accesses to
> http://localhost:8080/cocoon/xsp/simple
> and Resin crashes:
> #
> # An EXCEPTION_ACCESS_VIOLATION exception has been detected in native
> code outside the VM.
> # Program counter=0x50397707
> #
>
> Clearly, something is wrong with XSP... Some resources are not released.
> cocoon.log file does not have any errors.
>
> Berin,
> could you verify this behaviour?
>
> Vadim
>
>> -----Original Message-----
>> From: Berin Loritsch [mailto:bloritsch@apache.org]
>> Sent: Thursday, August 09, 2001 12:24 PM
>> To: cocoon-dev@xml.apache.org
>> Subject: Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your
>> Cocoon Load Tests)
>>
>>
>> Vadim Gritsenko wrote:
>>>
>>>> -----Original Message-----
>>>> From: Berin Loritsch [mailto:bloritsch@apache.org]
>>>> Sent: Thursday, August 09, 2001 11:23 AM
>>>> To: cocoon-dev@xml.apache.org
>>>> Subject: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your
>>>> Cocoon Load Tests)
>>>>
>>>>
>>>> Berin Loritsch wrote:
>>>>>
>>>>> My initial JMeter load tests show no error messages and plenty of
>>>>> reason to smile.
>>>>> I simulated 20 users each hitting the server every 300ms. When the
>>>>> JVM was in
>>>>> a garbage collection cycle, the longest response time was 842ms.
>>>>> During normal
>>>>> opperation, responses were between 0ms and 20ms (55% at 0, 40% at 10,
>>>>> 5% at 20)
>>>>> with occasional spikes around 100ms.
>>>>>
>>>>> I am going to up the JMeter load test to allow for 100 simultaneous
>>>>> users just to
>>>>> try and break it.
>>>>
>>>> I ran it with 100 simultaneous users--and the longest processing
>>>> times were still
>>>> less than 1.6 seconds (my magic "it takes too long on the server"
>>>> time).
>>>>
>>>> I wasn't satisfied, so I went with 200 simultaneous users. My
>>>> longest processing
>>>> time was 3.135 seconds with one Resin Server through Apache, on a 750
>>>> MHz Athlon
>>>> and 256 MB RAM.
>>>>
>>>
>>> I assume this results are for static resource (/welcome?), how about
>>> dynamic resources?
>>> (simple sql or esql)?
>>
>> I'll let you know in a bit. in the mean time, run some tests of your
>> own and give some
>> feedback.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>> For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
-------------------------------------------------------------------------
Stuart Roebuck stuart.roebuck@adolos.com
Lead Developer Java, XML, MacOS X, XP, etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
Posted by Vadim Gritsenko <vg...@hns.com>.
I found a problem:
Cocoon takes all available memory after ~ 500-600 accesses to http://localhost:8080/cocoon/xsp/simple
and Resin crashes:
#
# An EXCEPTION_ACCESS_VIOLATION exception has been detected in native code outside the VM.
# Program counter=0x50397707
#
Clearly, something is wrong with XSP... Some resources are not released.
cocoon.log file does not have any errors.
Berin,
could you verify this behaviour?
Vadim
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, August 09, 2001 12:24 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
>
>
> Vadim Gritsenko wrote:
> >
> > > -----Original Message-----
> > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > > Sent: Thursday, August 09, 2001 11:23 AM
> > > To: cocoon-dev@xml.apache.org
> > > Subject: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
> > >
> > >
> > > Berin Loritsch wrote:
> > > >
> > > > My initial JMeter load tests show no error messages and plenty of reason to smile.
> > > > I simulated 20 users each hitting the server every 300ms. When the JVM was in
> > > > a garbage collection cycle, the longest response time was 842ms. During normal
> > > > opperation, responses were between 0ms and 20ms (55% at 0, 40% at 10, 5% at 20)
> > > > with occasional spikes around 100ms.
> > > >
> > > > I am going to up the JMeter load test to allow for 100 simultaneous users just to
> > > > try and break it.
> > >
> > > I ran it with 100 simultaneous users--and the longest processing times were still
> > > less than 1.6 seconds (my magic "it takes too long on the server" time).
> > >
> > > I wasn't satisfied, so I went with 200 simultaneous users. My longest processing
> > > time was 3.135 seconds with one Resin Server through Apache, on a 750 MHz Athlon
> > > and 256 MB RAM.
> > >
> >
> > I assume this results are for static resource (/welcome?), how about dynamic resources?
> > (simple sql or esql)?
>
> I'll let you know in a bit. in the mean time, run some tests of your own and give some
> feedback.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org