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]
