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]
