Thanks very much, I'll take a detailed look later.
On 18/09/2009, Jakub Białek <[email protected]> wrote: > Hi, > > I added my listeners and several other enhancements in Bugzilla (id 47865). > > Best regards, > Jakub > > > 2009/9/14 sebb <[email protected]>: > > > On 14/09/2009, Jakub Białek <[email protected]> wrote: > >> Hi, > >> > >> My custom listener merges functionality from Aggregate Sampler (I need > >> something similar to line 90, 99 and 99.9%) with speed of the Summary > >> Listener and it works even faster than Summary Listener. It based on > >> Aggregate Sampler. This listener is designed to work with huge number > >> of samples (over millions, I've reached 550M) without loosing > >> performance and with high throughput. > >> I can contribute it but there is two problems: > >> 1. I've never contribute to open source project so I don't know all > >> process how to do it > > > > Quite simple, just create a Bugzilla enhancement request, and attach > > the files to it. > > Make sure any new files have the Apache License header (e.g. see > > Summary Listener). > > Also we don't use @author lines in code, though contributions can be > > attributed in other ways. > > > > JMeter Bugzilla is at: https://issues.apache.org/bugzilla/ > > > >> 2. My listener requires at least java 5, that one of the reasons way > >> it is faster than Summary Listener and currently jmeter still supports > >> java 1.4. > > > > The next release of JMeter will require Java 1.5. > > > >> Best regards, > >> Jakub > >> > >> W dniu 12 września 2009 14:20 użytkownik sebb <[email protected]> napisał: > >> > >> > On 12/09/2009, Jakub Białek <[email protected]> wrote: > >> >> The conclusions that I made based on my tests. Maybe characteristic of > >> >> tests that I've made is totally different from common jmeter usage > >> >> case so I describe my tests: > >> >> - long running tests: 12h-48h, the goal is to check how application > >> >> behaviour on extremely high and long time load > >> >> - no any delays between requests > >> > > >> > Real users will have delays between requests. > >> > Removing the delays will increase the transaction rate at the server, > >> > so one JMeter thread can generate the same load as lots of users. > >> > > >> > Of course, if you are running JMeter flat-out as you are here, then > >> > you will need more instances and more hosts. > >> > > >> > The number of JMeter instances and hosts that are needed depends very > >> > much on what is being tested. JMeter can work perfectly well with 200 > >> > (or more) threads on a single host. But equally, for some test > >> > scenarios, you may need to spread the load across multiple hosts (and > >> > therefore multiple copies of JMeter). > >> > > >> >> - no synchronization between jmeter worker threads > >> >> - physical delay (calculated by ping command) between jmeter client > >> >> and tested application below 0.2 ms > >> >> - only one custom listener optimized to collect millions of requests > >> >> (samples) and calculate avg, line 90%, line 99%, line 99.9%, > >> >> throughput , min and max > >> > > >> > I'd be interested to know how the listener works. > >> > The current Aggregate Sampler uses memory proportional to the number > >> > of samples, so causes problems with long-running tests (that's why the > >> > Summary Listener was added) > >> > > >> > Would you be willing to contribute the customem listener to JMeter? > >> > > >> >> - in a peak application can by used by 10 000 unique users > >> >> - average application throughput at a level 5 000 req/sec > >> >> - average response (request) time below 20 ms > >> >> - line 90% below 50 ms > >> >> > >> >> > >> >> > >> >> W dniu 12 września 2009 00:50 użytkownik sebb <[email protected]> > napisał: > >> >> > >> >> > On 11/09/2009, Jakub Białek <[email protected]> wrote: > >> >> > >> >> >> Obviously JMeter supports much more than 30 threads. But if you use > >> >> >> JMeter to simulate e.g. 200 concurrent users to check load and > >> >> >> response time of your application then you can use e.g.: > >> >> >> - 1 jmeter instance with 200 threads or > >> >> >> - 2 jmeter instances with 100 threads each or > >> >> >> - 4 jmeter instances with 50 threads each or > >> >> >> - 8 jmeter instances with 25 threads each > >> >> >> ...... > >> >> >> The last solution is the best if you want simulate real load > that can > >> >> >> be generated by 200 real users. The first solution is the worst. > I'll > >> >> >> explain it below. > >> >> >> Let's assume that you have 1 core CPU. Some facts: > >> >> >> - at the moment on your cpu can run only one process/thread to > >> >> >> simulate multitasking OS gives small amount of time to each > >> >> >> process/thread and changes the process/thread context > >> >> >> - changing/switching process cost several cpu cycles because cpu > >> >> >> registers have to be filled with corresponding data > >> >> >> - changing/switching thread is cheaper > >> >> >> - not only jmeter runs on your machine also many other > >> >> >> application/process bounded to the OS, so jmeter is often > dispossess > >> >> >> and waiting for cpu cycles > >> >> >> - not only workers threads of jmeter runs, also other java > threads > >> >> >> e.g. GCThread, all those threads compete for cpu > >> >> >> - when one thread/process is running others are sleeping/waiting > >> >> >> - process/thread can by disposed at any time of execution > >> >> > > >> >> > These are all true, but: > >> >> > > >> >> >> Conclusion: > >> >> >> - 200 jmeter threads don't mean 200 concurrent users, load > generated > >> >> >> by those jmeter instances will be much less than this by 200 > >> >> >> concurrent real users > >> >> > > >> >> > That's not a valid conclusion unless JMeter is running out of CPU. > >> >> > >> >> > >> >> On my 8 core machine jmeter instance never have taken more than 150% > >> >> (from 800% available) cpu, usually it has been below 100%, no matter > >> >> how many worker threads I've using. Even if the generated load is > much > >> >> below the maximum. So in my test is true that 2 instances with 30 > >> >> threads generate more throughput/load than 1 instance with 60 > threads. > >> >> I think that the problem is that in jmeter code is many synchronized > >> >> keyword: synchronized methods, blocks and collections in objects from > >> >> test plan (used concurrently by all worker threads), so more threads > >> >> mean more time spent on synchronization and waiting to get a lock. > >> >> > >> >> > >> >> > > >> >> > In general, a single JMeter thread can generate *more* load than a > >> >> > single user, because it can send requests much faster than a human. > >> >> > >> >> > >> >> Yes it's true if you based on only several users/threads and you think > >> >> about throughput. But you have to agree that almost always it easer > >> >> for application/server to handle request by request (even with no > >> >> delay between request) than handle at one moment 100 requests from > >> >> different users and you cannot generate such concurrency by 100 > worker > >> >> threads in one jmeter (ok you can if you run jmeter instance on > >> >> niagara platform that supports 128/256 concurrent threads ;)). > >> >> One jmeter instance usually can send request faster than a user but > >> >> 100 users can send 100 requests in the same moment of time (e.g. > >> >> 10:00:00:000-10:00:00:001), do you agree? > >> >> > >> >> > >> >> > >> >> > > >> >> >> - more jmeter threads more time spent on switching context, less > time > >> >> >> used by jmeter worker threads > >> >> >> - any worker thread can be disposed (and wait when rest 199 > threads > >> >> >> will take their cpu time) after receiving answer from server but > >> >> >> before calculate time that call to server took so this time will > be > >> >> >> incorrect > >> >> >> > >> >> >> So if your goal is to simulate as good as possible load > generated by > >> >> >> many users then use so much jmeter instances (computers) as you > can > >> >> >> with as less as possible threads on each jmeter instance. > Otherwise > >> >> >> your results can be far from reality and you can be surprised > why your > >> >> >> application can't handle with those users even though jmeter > stress > >> >> >> tests passed. > >> >> > > >> >> > Again, I disagree with this. > >> >> > >> >> > >> >> If you agree with fact that process/thread can by disposed at any time > >> >> of execution why do you don't agree that if you use many threads > >> >> calculated response time can be incorrect (it will contain not only > >> >> response time but also time that tread will waiting to get access to > >> >> cpu)? > >> >> > >> >> > >> >> > > >> >> >> If someone is interested in comparison how performance of my > >> >> >> application changes depending on jmeter configuration (number of > >> >> >> threads and number of instances) I can do that test. I have 10 > servers > >> >> >> with 2 CPU each and each CPU with 4 core. Those servers can be > used as > >> >> >> a JMeter clients. > >> >> >> > >> >> >> > >> >> >> Best regards, > >> >> >> Jakub > >> >> >> > >> >> >> > >> >> >> W dniu 11 września 2009 15:54 użytkownik sebb <[email protected]> > napisał: > >> >> >> > >> >> >> > On 11/09/2009, Jakub Białek <[email protected]> wrote: > >> >> >> >> How about tomcat is it on linux or windows machine? Make sure > that OS > >> >> >> >> doesn't limit the max number of inbound connection. > >> >> >> >> > >> >> >> >> Jakub > >> >> >> >> > >> >> >> >> BTW. I think that 200 thread on 1 jmeter instance are to > many if you > >> >> >> >> don't have cpus that support 64 threads simultaneously ;) . > I usually > >> >> >> >> use no more than 50 on 8 core system. > >> >> >> >> > >> >> >> > > >> >> >> > A single JMeter instance can support many more than 50 threads, > >> >> >> > depending on the test plan. > >> >> >> > > >> >> >> >> > >> >> >> >> 2009/9/11 Mytho Logic <[email protected]>: > >> >> >> >> > Hi, > >> >> >> >> > > >> >> >> >> > I tried with 550 threads in tomcat for 500 concurrent > users. But not > >> >> >> >> > succeed. > >> >> >> >> > > >> >> >> >> > Jmeter Client:- > >> >> >> >> > System: Windows XP Professional Verison 2002 SP2 > >> >> >> >> > Computer: Intel(R) Core(TM)2 CPU 6300 @ 1.86 Ghz 1.86 GHz, > 1.97 GB of RAM > >> >> >> >> > > >> >> >> >> > Jmeter Server:- > >> >> >> >> > System: Windows XP Professional x64 Edition Verison 2003 > SP2 > >> >> >> >> > Computer: Intel(R) Xeon(R) CPU 5130 @ 2.00 Ghz 2.00 GHz, > 8.00 GB of RAM > >> >> >> >> > > >> >> >> >> > Thanks > >> >> >> >> > Maumita > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > 2009/9/11 Jakub Białek <[email protected]> > >> >> >> >> > > >> >> >> >> >> If you have 500 (truly) concurrent users then you need at > least 500 > >> >> >> >> >> threads in tomcat, try with 550 thread. > >> >> >> >> >> > >> >> >> >> >> You run jmeter on windows or linux os? > >> >> >> >> >> > >> >> >> >> >> Best regards, > >> >> >> >> >> Jakub > >> >> >> >> >> > >> >> >> >> >> 2009/9/11 Mytho Logic <[email protected]>: > >> >> >> >> >> > Hi, > >> >> >> >> >> > > >> >> >> >> >> > I changed the maxthreads limit in tomcat server.xml to > 400 and tried the > >> >> >> >> >> > same testplan again..but few sample requests gets > failed and throws > >> >> >> >> >> > exception. > >> >> >> >> >> > what should I do to solve the problem. > >> >> >> >> >> > > >> >> >> >> >> > Exception:- > >> >> >> >> >> > > >> >> >> >> >> > java.net.ConnectException: Connection refused: connect > >> >> >> >> >> > at java.net.PlainSocketImpl.socketConnect(Native > Method) > >> >> >> >> >> > at > java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) > >> >> >> >> >> > at > java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) > >> >> >> >> >> > at > java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) > >> >> >> >> >> > at java.net.Socket.connect(Socket.java:519) > >> >> >> >> >> > at java.net.Socket.connect(Socket.java:469) > >> >> >> >> >> > at > sun.net.NetworkClient.doConnect(NetworkClient.java:157) > >> >> >> >> >> > at > sun.net.www.http.HttpClient.openServer(HttpClient.java:382) > >> >> >> >> >> > at > sun.net.www.http.HttpClient.openServer(HttpClient.java:494) > >> >> >> >> >> > at > sun.net.www.http.HttpClient.<init>(HttpClient.java:231) > >> >> >> >> >> > at > sun.net.www.http.HttpClient.New(HttpClient.java:304) > >> >> >> >> >> > at > sun.net.www.http.HttpClient.New(HttpClient.java:316) > >> >> >> >> >> > at > >> >> >> >> >> > > >> >> >> >> >> > sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:817) > >> >> >> >> >> > at > >> >> >> >> >> > > >> >> >> >> >> > sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:769) > >> >> >> >> >> > at > >> >> >> >> >> > > >> >> >> >> >> > sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:694) > >> >> >> >> >> > at > >> >> >> >> >> > > >> >> >> >> >> > org.apache.jmeter.protocol.http.sampler.HTTPSampler.sample(HTTPSampler.java:431) > >> >> >> >> >> > at > >> >> >> >> >> > > >> >> >> >> >> > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1021) > >> >> >> >> >> > at > >> >> >> >> >> > > >> >> >> >> >> > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1007) > >> >> >> >> >> > at > org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:290) > >> >> >> >> >> > at java.lang.Thread.run(Thread.java:595) > >> >> >> >> >> > > >> >> >> >> >> > Thanks > >> >> >> >> >> > Maumita > >> >> >> >> >> > > >> >> >> >> >> > > >> >> >> >> >> > On Fri, Sep 11, 2009 at 3:07 PM, sebb > <[email protected]> wrote: > >> >> >> >> >> > > >> >> >> >> >> >> On 11/09/2009, Mytho Logic > <[email protected]> wrote: > >> >> >> >> >> >> > Hi, > >> >> >> >> >> >> > > >> >> >> >> >> >> > In tomcat server.xml, I changed the maxtheads limit > to 300 and kept > >> >> >> >> >> >> > JAVA_OPTS=-Xms512m -Xmx1024m > >> >> >> >> >> >> > > >> >> >> >> >> >> > But not succeed.I am getting same > "java.net.ConnectException: > >> >> >> >> >> Connection > >> >> >> >> >> >> > refused: connect" exception. Am I missing anything > to change in > >> >> >> >> >> >> server.xml > >> >> >> >> >> >> > file. > >> >> >> >> >> >> > The machine on which tomcat server is running has 2 > GB RAM. > >> >> >> >> >> >> > > >> >> >> >> >> >> > Please help on this. > >> >> >> >> >> >> > >> >> >> >> >> >> This appears to be a Tomcat configuaration issue. > >> >> >> >> >> >> > >> >> >> >> >> >> Read the Tomcat documentation carefully, and if that > does not answer > >> >> >> >> >> >> your query, then post a question on the Tomcat user > list. > >> >> >> >> >> >> > >> >> >> >> >> >> > Thanks > >> >> >> >> >> >> > Maumita > >> >> >> >> >> >> > > >> >> >> >> >> >> > > >> >> >> >> >> >> > On Fri, Sep 11, 2009 at 10:15 AM, Deepak Shetty > <[email protected]> > >> >> >> >> >> >> wrote: > >> >> >> >> >> >> > > >> >> >> >> >> >> > > Hi > >> >> >> >> >> >> > > > http://tomcat.apache.org/tomcat-5.5-doc/config/http.html > >> >> >> >> >> >> > > There are three thread related properties in > server.xml . You seem > >> >> >> >> >> to > >> >> >> >> >> >> have > >> >> >> >> >> >> > > run into maxThreads limit > >> >> >> >> >> >> > > Note that if your server cant handle the load > that is a server/OS > >> >> >> >> >> >> problem , > >> >> >> >> >> >> > > you are more likely to get help on a tomcat > forum. Jmeter is > >> >> >> >> >> >> generating the > >> >> >> >> >> >> > > load correctly. > >> >> >> >> >> >> > > regards > >> >> >> >> >> >> > > deepak > >> >> >> >> >> >> > > > >> >> >> >> >> >> > > On Thu, Sep 10, 2009 at 9:38 PM, Mytho Logic < > >> >> >> >> >> >> [email protected] > >> >> >> >> >> >> > > >wrote: > >> >> >> >> >> >> > > > >> >> >> >> >> >> > > > Hi, > >> >> >> >> >> >> > > > > >> >> >> >> >> >> > > > I am using jmeter version 2.3.2. > >> >> >> >> >> >> > > > To test my application for 200 concurrent users > I have used > >> >> >> >> >> >> distibuted > >> >> >> >> >> >> > > > testing set up. > >> >> >> >> >> >> > > > It works fine for 200 users. > >> >> >> >> >> >> > > > The test plan was - > >> >> >> >> >> >> > > > 1. 200 concurrent users will first hit the home > page > >> >> >> >> >> >> > > > 2. After that 200 concurrent users will hit the > products page > >> >> >> >> >> >> > > > 3. After that 200 concurrent users will hit the > product Detail > >> >> >> >> >> page > >> >> >> >> >> >> > > > > >> >> >> >> >> >> > > > For concurrent user setup I have used > 'Synchronizing Timer' above > >> >> >> >> >> >> the > >> >> >> >> >> >> > > > thread > >> >> >> >> >> >> > > > groups and mentioned 200. > >> >> >> >> >> >> > > > It works fine and I got the result. > >> >> >> >> >> >> > > > > >> >> >> >> >> >> > > > Setup:- > >> >> >> >> >> >> > > > > >> >> >> >> >> >> > > > Tomcat server, Jmeter client and Jmeter server > all are in 3 > >> >> >> >> >> >> different > >> >> >> >> >> >> > > > machine. > >> >> >> >> >> >> > > > > >> >> >> >> >> >> > > > Tomcat Server > >> >> >> >> >> >> > > > ------------- > >> >> >> >> >> >> > > > JAVA_OPTS=-Xms1024m -Xmx1024m > >> >> >> >> >> >> > > > > >> >> >> >> >> >> > > > Jmeter Client > >> >> >> >> >> >> > > > ------------- > >> >> >> >> >> >> > > > HEAP=-Xms512m -Xmx1024m > >> >> >> >> >> >> > > > > >> >> >> >> >> >> > > > Jmeter Server > >> >> >> >> >> >> > > > ------------- > >> >> >> >> >> >> > > > HEAP=-Xms512m -Xmx4096m > >> >> >> >> >> >> > > > > >> >> >> >> >> >> > > > Using the same configuration and same > setup,when i tried for 220 > >> >> >> >> >> >> > > concurrent > >> >> >> >> >> >> > > > users for few few sample requests I got > >> >> >> >> >> >> > > > "java.net.ConnectException: Connection refused: > connect: > >> >> >> >> >> exception. > >> >> >> >> >> >> > > > Sometime I succeded for 220 concurrent users > without any > >> >> >> >> >> errors.But > >> >> >> >> >> >> next > >> >> >> >> >> >> > > > time whne I again run the test plan for > >> >> >> >> >> >> > > > 220 concurrent users I got exception. > >> >> >> >> >> >> > > > > >> >> >> >> >> >> > > > What is the reason behind this exception and > how can I solve > >> >> >> >> >> this? > >> >> >> >> >> >> > > > I need to load my application upto 500 > concurrent users. Please > >> >> >> >> >> >> suggesst > >> >> >> >> >> >> > > > how > >> >> >> >> >> >> > > > can I do this? > >> >> >> >> >> >> > > > > >> >> >> >> >> >> > > > This is an urgent requirement. > >> >> >> >> >> >> > > > > >> >> >> >> >> >> > > > Thanks > >> >> >> >> >> >> > > > Maumita > >> >> >> >> >> >> > > > > >> >> >> >> >> >> > > > >> >> >> >> >> >> > > >> >> >> >> >> >> > >> >> >> >> >> >> > --------------------------------------------------------------------- > >> >> >> >> >> >> 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] > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > >> >> >> >> > --------------------------------------------------------------------- > >> >> >> >> 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] > >> >> >> > > >> >> >> > > >> >> >> > >> >> >> > --------------------------------------------------------------------- > >> >> >> 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] > >> >> > > >> >> > > >> >> > >> >> --------------------------------------------------------------------- > >> >> 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] > >> > > >> > > >> > >> --------------------------------------------------------------------- > >> 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] > > > > > > --------------------------------------------------------------------- > 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]
