>I need to log the time taken by each request when 100/200/300/400/500 >concurrent requests are made. Hope the logger can do that. Yes.
>when i have 5 users (threads) and 50 users (threads), the througput is >same 12/sec. Now how do I explain the user concurrency, load / >stress? See explanation on throughput curves. http://books.google.com/books?id=HTX8DyD0WzkC&pg=PA12&lpg=PA12&dq=throughput+curve&source=bl&ots=7qYRIZiPX9&sig=7UoxT-8gpbmqWwwUcu0aROe_QWA&hl=en&ei=1X6mSqLyHpDK_gbMgvC-CQ&sa=X&oi=book_result&ct=result&resnum=5#v=onepage&q=throughput%20curve&f=false You have reached your throughput 'plateau' and need to check response times as well.. >How to measure the load / stress on the server? Thats server specific, your O.S. will give you tools to do this. (e.g. perfmon on windows, vmstat on unix , other tools ). regards deepak On Tue, Sep 8, 2009 at 3:35 AM, Bruce Foster <[email protected]> wrote: > Thanks All, > > I will try the options and let you know. Got distracted with some > other work and will spend some time on the benchmarking next week. > > I need to log the time taken by each request when 100/200/300/400/500 > concurrent requests are made. Hope the logger can do that. > > I have some basic question being newbie; > > when i have 5 users (threads) and 50 users (threads), the througput is > same 12/sec. Now how do I explain the user concurrency, load / > stress? > > I need to find out if the system can handle 500 concurrent users. > > Throughput is the response time right which turns out to be around > 85ms (12/sec), since there are no change from 5 to 50, how do I test > for 500 concurrent users ( or 300 or 200)? > > How to measure the load / stress on the server? > > Thanks a lot > > Bruce > > > > > > > > Thanks > Bruce > > > > On Sat, Sep 5, 2009 at 6:09 PM, sebb<[email protected]> wrote: > > On 05/09/2009, Bruce Foster <[email protected]> wrote: > >> Hi Deepak and others, > >> > >> Thanks for quick response and help. > >> > >> Yes, the listener Save_Responses_to_a_file did the trick for me. Just > >> ran a test with 1000 request to see the response and got all the > >> images saved in directory. Well, the purpose was to check the response > >> and not the performance (response time). After making sure that the > >> image are correct, I ran the actual test to get the performance > >> results. > >> > >> Well, I'm using the random function and it worked well to generate > >> random bound box request. Also, I adapted the osgeo test method of > >> using pre generated csv file. > >> > >> got a good result of 12 user per second in one method for total > >> random, and 20 users per second for 800x600px random bbox request. > >> need further more to test. > >> > >> now i have to find out how to log the 10000 request time. jmeter gives > >> only summary/average. > > > > In the GUI, that depends on the Listener - e.g. the Table View > > Listener shows response times. But don't use this for a performance > > test as it will use lots of memory. > > > > Just save the responses to a file, and you have all the details there, > > depending on what you have configured. Probably easiest to use CSV > > output. > > > >> Cheers > >> > >> bruce. > >> > >> > >> > >> > >> > >> On Thu, Sep 3, 2009 at 7:16 PM, sebb<[email protected]> wrote: > >> > On 03/09/2009, Adrian Speteanu <[email protected]> wrote: > >> >> true, you can use either method for what you said you need, but in > >> >> this case, saving the file on the test machine will significantly > >> >> increase the stress on the test environment (quality image files > mean > >> >> lots of space and that means disk usage). > >> >> > >> >> if you run the test with fewer requests and see that you get the > >> >> responses you expect, then you will also get these responses in a > load > >> >> / stress test even if you don't save the files locally. > >> > > >> > Not necessarily; the server may degrade under load. > >> > > >> > For checking responses such as images, consider using > >> > > >> > > http://jakarta.apache.org/jmeter/usermanual/component_reference.html#MD5Hex_Assertion > >> > > >> > Or you can use the HTTP sampler option "Save response as MD5 hash?" > >> > and check that. > >> > > >> >> this is > >> >> recommended. > >> >> > >> >> > >> >> On Tue, Sep 1, 2009 at 2:04 AM, Deepak Shetty<[email protected]> > wrote: > >> >> > Hi > >> >> > you can add > >> >> > > http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Save_Responses_to_a_file > >> >> > OR you can add a BeanShell Post Assertion that can read the > bytes and save > >> >> > it to whatever you want or run comparisons > >> >> > OR > >> >> > > http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Sample_Result_Save_Configuration > >> >> > (Check Save Response Data) - I wouldnt do this though because > some binary > >> >> > can cause the xml to break > >> >> > > >> >> > > >> >> > regards > >> >> > deepak > >> >> > > >> >> > On Mon, Aug 31, 2009 at 3:57 PM, Bruce Foster < > [email protected]> wrote: > >> >> > > >> >> >> Hi List, > >> >> >> > >> >> >> I'm totally new to jmeter and also benchmarking. > >> >> >> > >> >> >> I'm testing a WMS (web map service) service performance of three > >> >> >> server softwares. Basically, they are GET request of images from > a > >> >> >> server. > >> >> >> > >> >> >> Is there a way to SAVE the requested images? I have the mandate > to > >> >> >> make sure that the response from the servers are exactly the > same > >> >> >> image (in resolution, quality) that we request for. > >> >> >> > >> >> >> When I did a test, I put a network monitor. I could see 70mb of > data > >> >> >> is transfered. Now, where to look for that, does jmeter save > them in > >> >> >> cache? > >> >> >> > >> >> >> Note, I'm doing everything on a vmware machine running on my > notebook. > >> >> >> > >> >> >> > >> >> >> Thanks > >> >> >> Bruce > >> >> >> > >> >> >> > --------------------------------------------------------------------- > >> >> >> 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] > >
