Re: what type of Engine does JMETER Regex uses pls
jmeter uses apache oromatcher for the regexp. does that answer your question? peter On Fri, 16 Jul 2004 13:31:47 +1000, Krishna, Raj <[EMAIL PROTECTED]> wrote: > Hi , > > Does any one know what type of engine does the jmeter use like dfa or > nfa. > > Thanks for the help > > Raj > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re:what type of Engine does JMETER Regex uses pls
Hi , Does any one know what type of engine does the jmeter use like dfa or nfa. Thanks for the help Raj
RE: Hi any one pls help me
HI Frank, Thanks for the tool it helped me solving the problem. I owe u beer mate. Cheers, Raj -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, 16 July 2004 12:36 AM To: JMeter Users List Subject: Re: Hi any one pls help me Hi, maybe you want to try this in a Regular Expression Extractor: sid=(\S+) supposed the String is only one line. I use a little Win Prog for testing RegExpression maybe it wil help you too. http://weitz.de/regex-coach/ Kind Regards Frank |-+> | | Michael Stover | | | <[EMAIL PROTECTED]| | | org> | | || | | 15.07.2004 14:25 | | | Bitte antworten | | | an "JMeter Users | | | List"| | || |-+> >--- ---| | | | An: JMeter Users List <[EMAIL PROTECTED]> | | Kopie: | | Thema:Re: Hi any one pls help me | >--- ---| The problem is your regular expression. .* will grab the whole page. you'd be better off with something like sid="?([[^ ]*) But, I can only guess since I don't really know the nature of your sid values. -Mike On Wed, 2004-07-14 at 22:28, Krishna, Raj wrote: > Hi there, > > > > I am not able to capture and httprequest attribute value > > > > sid=1401bc9b1cca027f83343a68204d8c9cce9f1f93c3d0a0acf90e8e2a1fef4adc2760 > 2f2e64092a65e8bda1c329e3c8f4ddd4ebb994c0cca5686a5c555a73bff1ba6ad6f4a4c1 > b3d3fd936fbd5a7c200b > > > > I have used the Regular Expression Extractor but in vain. > > > > This is what I have used. > > > > Regular expression :sid=(.*) > > > > And I tired this > > > > Regular expression :sid=(*) > > > > I am not able to capture this long length of number and letters. Pls if > any one how to pls let me know. > > > > Cheers > > Raj > > > > > > > -- Michael Stover <[EMAIL PROTECTED]> Apache Software Foundation - 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]
Getting variable from frame other than working one
Hello all, We are testing web application. And we captured script with BadBoy. Our application has more than one frame. We need to get variable from frame, which is not working one. However when we using regular expression, looks like jemeter cannot see it at all, as it puts default value, where we just trying get there anything at all using (.*) I wonder if anyone knows, how we can access that code on another frame Thank you Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Continue functionality in Loop controller
Hi, I have a test case ( simplified ) which generally looks like : - Thread Group ( loop once ) - Once Only Controller ( login ) - Loop Controller ( loop many times ) HTTP Request 1 - Assertion HTTP Request 2 HTTP Request 3 - End Loop Controller - Once Only Controller ( logout ) Is there a way to skip HTTP request 2 and 3 based on the assertion on HTTP Request 1. The HTTP requests have dependency on previous requests. I can see one way of performing this, which is using regex to store the success/failure of the request into a variable and using that to control subsequent HTTP requests within a IF controller. The only issue with this is with any reasonably sized test plan it can make for a pretty ugly solution. I did look through the mail archives and found a related discussion : http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=1920 which in turn referred to a bug entry at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12144 which shows that it is Assigned. The date on the assignment is in 2002. I am assuming it is not going to get a fix. Any suggestions will be much appreciated. -Krishna _ Check out the latest news, polls and tools in the MSN 2004 Election Guide! http://special.msn.com/msn/election2004.armx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any other limitations of jmeter? How about scalability?
hehe I tend to think in terms of page views per X time. Usually, I look at the nightly logs. If I get 8million page views per day, I try to calculate the average. Then I look at the peak traffic to figure out the peak concurrent requests for that day/week/month. Based on that, I design my test plan so it simulates the desired number of concurrent requests. Once the test is done, I process the accesslogs to see if it actually produced the rate I was shooting for. I've never actually tried to figure X threads with timer == X threads w/o timers. for me the aggregate performance is more important. peter On Thu, 15 Jul 2004 14:07:08 -0400, Michael Stover <[EMAIL PROTECTED]> wrote: > I have often wondered if removing timers is an efficient way of > simulating more users than otherwise possible. Ie, if you remove > timers, 4 threads is equivalent to X threads delayed 2 seconds between > requests. In terms of load generated on the server. The elimination of > extra threads probably helps reduce some of the context switching and > memory use. > > Then again, no timers might increasing context switching, so who knows? > > -Mike > > > > On Thu, 2004-07-15 at 13:49, Peter Lin wrote: > > I should mention that in my case, I am brutal. I use ramp up, but I > > don't use timers. I tend to shoot for worse case scenario to expose > > flaws, weaknesses and memory leaks in the dev and staging environment. > > > > I usually try to shoot for better performance than the requirements. > > If my stress tests handle the worse case test, I usually feel > > confortable standing by the performance of the application. If it just > > barely meets the requirements, I usually state a lower number for > > sanity sake. > > > > I might be paranoid. > > > > peter > > > > > > On Thu, 15 Jul 2004 13:51:57 -0400, Michael Stover <[EMAIL PROTECTED]> wrote: > > > If you are on 3Ghz p4 with 1G, I would expect you can run more than 100 > > > users. I've run up to 500 with reasonable success (you can't trust the > > > absolute timings on it, but it doesn't chug badly or crash). > > > > > > However, it's all highly dependent on the test details. A test that > > > parses responses for embedded resources is going to kill JMeter's > > > performance a lot faster than one that doesn't. Regular expression > > > parsers, assertions also add significant processing time for JMeter. A > > > complex test might have 100 users as a max on that machine. A simple > > > test might allow up to 500 users. > > > > > > It also depends on how fast the server is - a faster server puts more > > > stress on JMeter because each thread spends less time blocked on IO and > > > more time preparing the next request. > > > > > > And, of course, timers. A test without timers is brutal for both > > > sides. A few timers increases dramatically the number of users that can > > > effectively be simulated. > > > > > > I think the biggest lingering limitation of JMeter is that the remote > > > testing feature was not adequately made, and does not in fact get you > > > anything in terms of scaling tests up. > > > > > > -Mike > > > > > > > > > > > > On Thu, 2004-07-15 at 13:05, joelsherriff wrote: > > > > Agree - my background is in writing commercial test tools - was team lead > > > > for Compuware on the web team for QALoad, before that with > > > > Rational/Pure/Performix (way way back when). So the big tests 1000+ users > > > > are what I'm used to dealing with. Right now I've been asked to evaluate > > > > jmeter against the commercial tools and scalability is always the killer - > > > > esp when you look at the tools that drive the server by driving instances of > > > > a browser (yuck!). I'm really liking jmeter - much better than I expected > > > > it to be. I expected to find lot's of holes and limitations (the arrogance > > > > of the old-timer) but really haven't seen any that aren't there for pretty > > > > good reason - like the proxy/ssl issue. > > > > > > > > To distill down something you said, and ignoring the network limitations > > > > (since that's such a variable): so in your experience you get about 100 > > > > threads per machine before it saturates it? Is it typically CPU bound or > > > > memory or...? > > > > > > > > J > > > > > > > > - Original Message - > > > > From: "Peter Lin" <[EMAIL PROTECTED]> > > > > To: "JMeter Users List" <[EMAIL PROTECTED]> > > > > Sent: Thursday, July 15, 2004 11:43 AM > > > > Subject: Re: Any other limitations of jmeter? How about scalability? > > > > > > > > > > > > > for general performance testing stuff, I have several performance > > > > > articles listed on the links page > > > > > http://wiki.apache.org/jakarta-jmeter/JMeterLinks. > > > > > > > > > > If I compare JMeter to other tools I've used, I would say it is > > > > > comparable. The tools I've used: > > > > > > > > > > 1. apache ab > > > > > 2. zdnet Webbench > > > > > 3. custom script perl > > > > > > > > > > The biggest challenge of stres
Re: Any other limitations of jmeter? How about scalability?
I have often wondered if removing timers is an efficient way of simulating more users than otherwise possible. Ie, if you remove timers, 4 threads is equivalent to X threads delayed 2 seconds between requests. In terms of load generated on the server. The elimination of extra threads probably helps reduce some of the context switching and memory use. Then again, no timers might increasing context switching, so who knows? -Mike On Thu, 2004-07-15 at 13:49, Peter Lin wrote: > I should mention that in my case, I am brutal. I use ramp up, but I > don't use timers. I tend to shoot for worse case scenario to expose > flaws, weaknesses and memory leaks in the dev and staging environment. > > I usually try to shoot for better performance than the requirements. > If my stress tests handle the worse case test, I usually feel > confortable standing by the performance of the application. If it just > barely meets the requirements, I usually state a lower number for > sanity sake. > > I might be paranoid. > > peter > > > On Thu, 15 Jul 2004 13:51:57 -0400, Michael Stover <[EMAIL PROTECTED]> wrote: > > If you are on 3Ghz p4 with 1G, I would expect you can run more than 100 > > users. I've run up to 500 with reasonable success (you can't trust the > > absolute timings on it, but it doesn't chug badly or crash). > > > > However, it's all highly dependent on the test details. A test that > > parses responses for embedded resources is going to kill JMeter's > > performance a lot faster than one that doesn't. Regular expression > > parsers, assertions also add significant processing time for JMeter. A > > complex test might have 100 users as a max on that machine. A simple > > test might allow up to 500 users. > > > > It also depends on how fast the server is - a faster server puts more > > stress on JMeter because each thread spends less time blocked on IO and > > more time preparing the next request. > > > > And, of course, timers. A test without timers is brutal for both > > sides. A few timers increases dramatically the number of users that can > > effectively be simulated. > > > > I think the biggest lingering limitation of JMeter is that the remote > > testing feature was not adequately made, and does not in fact get you > > anything in terms of scaling tests up. > > > > -Mike > > > > > > > > On Thu, 2004-07-15 at 13:05, joelsherriff wrote: > > > Agree - my background is in writing commercial test tools - was team lead > > > for Compuware on the web team for QALoad, before that with > > > Rational/Pure/Performix (way way back when). So the big tests 1000+ users > > > are what I'm used to dealing with. Right now I've been asked to evaluate > > > jmeter against the commercial tools and scalability is always the killer - > > > esp when you look at the tools that drive the server by driving instances of > > > a browser (yuck!). I'm really liking jmeter - much better than I expected > > > it to be. I expected to find lot's of holes and limitations (the arrogance > > > of the old-timer) but really haven't seen any that aren't there for pretty > > > good reason - like the proxy/ssl issue. > > > > > > To distill down something you said, and ignoring the network limitations > > > (since that's such a variable): so in your experience you get about 100 > > > threads per machine before it saturates it? Is it typically CPU bound or > > > memory or...? > > > > > > J > > > > > > - Original Message - > > > From: "Peter Lin" <[EMAIL PROTECTED]> > > > To: "JMeter Users List" <[EMAIL PROTECTED]> > > > Sent: Thursday, July 15, 2004 11:43 AM > > > Subject: Re: Any other limitations of jmeter? How about scalability? > > > > > > > > > > for general performance testing stuff, I have several performance > > > > articles listed on the links page > > > > http://wiki.apache.org/jakarta-jmeter/JMeterLinks. > > > > > > > > If I compare JMeter to other tools I've used, I would say it is > > > > comparable. The tools I've used: > > > > > > > > 1. apache ab > > > > 2. zdnet Webbench > > > > 3. custom script perl > > > > > > > > The biggest challenge of stress testing is this, "what are you > > > > testing?" Most of the time, the bottleneck for a website is the > > > > connection to the internet. I have a explanation of it in the > > > > articles. It doesn't really matter if your website can handle 80 > > > > concurrent requests reliably, if you're server is on a T1. I would say > > > > JMeter can easily produce enough stress to figure out what the upper > > > > limit is for your web application. The situations where it won't be > > > > suitable is if you're testing a system that has to support 5,000 > > > > concurrent users. You still could use JMeter if you setup each > > > > instance with 100 threads and use 50 machines. > > > > > > > > realistically, to do that kind of test, the server would have to be a > > > > big Unix box or mainframe hooked up to several gigabit routers. Using > > > > 100mbit ethernet, y
Re: Any other limitations of jmeter? How about scalability?
I should mention that in my case, I am brutal. I use ramp up, but I don't use timers. I tend to shoot for worse case scenario to expose flaws, weaknesses and memory leaks in the dev and staging environment. I usually try to shoot for better performance than the requirements. If my stress tests handle the worse case test, I usually feel confortable standing by the performance of the application. If it just barely meets the requirements, I usually state a lower number for sanity sake. I might be paranoid. peter On Thu, 15 Jul 2004 13:51:57 -0400, Michael Stover <[EMAIL PROTECTED]> wrote: > If you are on 3Ghz p4 with 1G, I would expect you can run more than 100 > users. I've run up to 500 with reasonable success (you can't trust the > absolute timings on it, but it doesn't chug badly or crash). > > However, it's all highly dependent on the test details. A test that > parses responses for embedded resources is going to kill JMeter's > performance a lot faster than one that doesn't. Regular expression > parsers, assertions also add significant processing time for JMeter. A > complex test might have 100 users as a max on that machine. A simple > test might allow up to 500 users. > > It also depends on how fast the server is - a faster server puts more > stress on JMeter because each thread spends less time blocked on IO and > more time preparing the next request. > > And, of course, timers. A test without timers is brutal for both > sides. A few timers increases dramatically the number of users that can > effectively be simulated. > > I think the biggest lingering limitation of JMeter is that the remote > testing feature was not adequately made, and does not in fact get you > anything in terms of scaling tests up. > > -Mike > > > > On Thu, 2004-07-15 at 13:05, joelsherriff wrote: > > Agree - my background is in writing commercial test tools - was team lead > > for Compuware on the web team for QALoad, before that with > > Rational/Pure/Performix (way way back when). So the big tests 1000+ users > > are what I'm used to dealing with. Right now I've been asked to evaluate > > jmeter against the commercial tools and scalability is always the killer - > > esp when you look at the tools that drive the server by driving instances of > > a browser (yuck!). I'm really liking jmeter - much better than I expected > > it to be. I expected to find lot's of holes and limitations (the arrogance > > of the old-timer) but really haven't seen any that aren't there for pretty > > good reason - like the proxy/ssl issue. > > > > To distill down something you said, and ignoring the network limitations > > (since that's such a variable): so in your experience you get about 100 > > threads per machine before it saturates it? Is it typically CPU bound or > > memory or...? > > > > J > > > > - Original Message - > > From: "Peter Lin" <[EMAIL PROTECTED]> > > To: "JMeter Users List" <[EMAIL PROTECTED]> > > Sent: Thursday, July 15, 2004 11:43 AM > > Subject: Re: Any other limitations of jmeter? How about scalability? > > > > > > > for general performance testing stuff, I have several performance > > > articles listed on the links page > > > http://wiki.apache.org/jakarta-jmeter/JMeterLinks. > > > > > > If I compare JMeter to other tools I've used, I would say it is > > > comparable. The tools I've used: > > > > > > 1. apache ab > > > 2. zdnet Webbench > > > 3. custom script perl > > > > > > The biggest challenge of stress testing is this, "what are you > > > testing?" Most of the time, the bottleneck for a website is the > > > connection to the internet. I have a explanation of it in the > > > articles. It doesn't really matter if your website can handle 80 > > > concurrent requests reliably, if you're server is on a T1. I would say > > > JMeter can easily produce enough stress to figure out what the upper > > > limit is for your web application. The situations where it won't be > > > suitable is if you're testing a system that has to support 5,000 > > > concurrent users. You still could use JMeter if you setup each > > > instance with 100 threads and use 50 machines. > > > > > > realistically, to do that kind of test, the server would have to be a > > > big Unix box or mainframe hooked up to several gigabit routers. Using > > > 100mbit ethernet, you wouldn't be able to test 5K concurrent requests > > > for a sustained period of time effectively. Sustained transfer rate > > > plays a huge role in how many concurrent requests a system can handle > > > reliably for a long time. > > > > > > peter > > > > > > > > > > > > On Thu, 15 Jul 2004 11:25:50 -0400, joelsherriff > > > <[EMAIL PROTECTED]> wrote: > > > > After Peter pointed out that the jmeter proxy doesn't do ssl, I thought > > I'd > > > > ask everyone if they know of other limitations they've run into and > > about > > > > what seems to be the cronic limitation of these tools - scalability. > > Not > > > > talking about bugs per se, just things you migh
Re: Any other limitations of jmeter? How about scalability?
If you are on 3Ghz p4 with 1G, I would expect you can run more than 100 users. I've run up to 500 with reasonable success (you can't trust the absolute timings on it, but it doesn't chug badly or crash). However, it's all highly dependent on the test details. A test that parses responses for embedded resources is going to kill JMeter's performance a lot faster than one that doesn't. Regular expression parsers, assertions also add significant processing time for JMeter. A complex test might have 100 users as a max on that machine. A simple test might allow up to 500 users. It also depends on how fast the server is - a faster server puts more stress on JMeter because each thread spends less time blocked on IO and more time preparing the next request. And, of course, timers. A test without timers is brutal for both sides. A few timers increases dramatically the number of users that can effectively be simulated. I think the biggest lingering limitation of JMeter is that the remote testing feature was not adequately made, and does not in fact get you anything in terms of scaling tests up. -Mike On Thu, 2004-07-15 at 13:05, joelsherriff wrote: > Agree - my background is in writing commercial test tools - was team lead > for Compuware on the web team for QALoad, before that with > Rational/Pure/Performix (way way back when). So the big tests 1000+ users > are what I'm used to dealing with. Right now I've been asked to evaluate > jmeter against the commercial tools and scalability is always the killer - > esp when you look at the tools that drive the server by driving instances of > a browser (yuck!). I'm really liking jmeter - much better than I expected > it to be. I expected to find lot's of holes and limitations (the arrogance > of the old-timer) but really haven't seen any that aren't there for pretty > good reason - like the proxy/ssl issue. > > To distill down something you said, and ignoring the network limitations > (since that's such a variable): so in your experience you get about 100 > threads per machine before it saturates it? Is it typically CPU bound or > memory or...? > > J > > - Original Message - > From: "Peter Lin" <[EMAIL PROTECTED]> > To: "JMeter Users List" <[EMAIL PROTECTED]> > Sent: Thursday, July 15, 2004 11:43 AM > Subject: Re: Any other limitations of jmeter? How about scalability? > > > > for general performance testing stuff, I have several performance > > articles listed on the links page > > http://wiki.apache.org/jakarta-jmeter/JMeterLinks. > > > > If I compare JMeter to other tools I've used, I would say it is > > comparable. The tools I've used: > > > > 1. apache ab > > 2. zdnet Webbench > > 3. custom script perl > > > > The biggest challenge of stress testing is this, "what are you > > testing?" Most of the time, the bottleneck for a website is the > > connection to the internet. I have a explanation of it in the > > articles. It doesn't really matter if your website can handle 80 > > concurrent requests reliably, if you're server is on a T1. I would say > > JMeter can easily produce enough stress to figure out what the upper > > limit is for your web application. The situations where it won't be > > suitable is if you're testing a system that has to support 5,000 > > concurrent users. You still could use JMeter if you setup each > > instance with 100 threads and use 50 machines. > > > > realistically, to do that kind of test, the server would have to be a > > big Unix box or mainframe hooked up to several gigabit routers. Using > > 100mbit ethernet, you wouldn't be able to test 5K concurrent requests > > for a sustained period of time effectively. Sustained transfer rate > > plays a huge role in how many concurrent requests a system can handle > > reliably for a long time. > > > > peter > > > > > > > > On Thu, 15 Jul 2004 11:25:50 -0400, joelsherriff > > <[EMAIL PROTECTED]> wrote: > > > After Peter pointed out that the jmeter proxy doesn't do ssl, I thought > I'd > > > ask everyone if they know of other limitations they've run into and > about > > > what seems to be the cronic limitation of these tools - scalability. > Not > > > talking about bugs per se, just things you might have been able to do > with > > > other tools you can't do with jmeter. Like, does jmeter support NTLM > > > authentication? (I realize that's a question, not a statement, but some > > > other tools have problems with NTLM so I thought I'd throw it out > there.) > > > > > > As to scalability...How many users can you emulate before saturating > your > > > driver machine given an "average" script (mix of text and graphics, > etc)? > > > Given something like a 3Ghz P4 with 1M of memory. > > > > > > I originally did intend to play with jmeter more and lurk on this list > much > > > longer before asking these types of questions, but, as always, it's > faster > > > to ask... > > > > > > J > > > > > > - >
Re: Any other limitations of jmeter? How about scalability?
for me, 100 threads gives me realiable performance for real webapplications. More than 100 threads, there's too much resource competition. For static files and graphics, I've been able to go up to 200-250 without any problems. Real webpages that are dynamic and contain 60K of HTML, I find 100 threads is a good limit. More than that I usually see the IO as a bottleneck. For webservices, I find the limit is lower because of how verbose XML is. but that's specific to the kinds of apps I test. peter On Thu, 15 Jul 2004 13:05:37 -0400, joelsherriff <[EMAIL PROTECTED]> wrote: > Agree - my background is in writing commercial test tools - was team lead > for Compuware on the web team for QALoad, before that with > Rational/Pure/Performix (way way back when). So the big tests 1000+ users > are what I'm used to dealing with. Right now I've been asked to evaluate > jmeter against the commercial tools and scalability is always the killer - > esp when you look at the tools that drive the server by driving instances of > a browser (yuck!). I'm really liking jmeter - much better than I expected > it to be. I expected to find lot's of holes and limitations (the arrogance > of the old-timer) but really haven't seen any that aren't there for pretty > good reason - like the proxy/ssl issue. > > To distill down something you said, and ignoring the network limitations > (since that's such a variable): so in your experience you get about 100 > threads per machine before it saturates it? Is it typically CPU bound or > memory or...? > > J > > > > - Original Message - > From: "Peter Lin" <[EMAIL PROTECTED]> > To: "JMeter Users List" <[EMAIL PROTECTED]> > Sent: Thursday, July 15, 2004 11:43 AM > Subject: Re: Any other limitations of jmeter? How about scalability? > > > for general performance testing stuff, I have several performance > > articles listed on the links page > > http://wiki.apache.org/jakarta-jmeter/JMeterLinks. > > > > If I compare JMeter to other tools I've used, I would say it is > > comparable. The tools I've used: > > > > 1. apache ab > > 2. zdnet Webbench > > 3. custom script perl > > > > The biggest challenge of stress testing is this, "what are you > > testing?" Most of the time, the bottleneck for a website is the > > connection to the internet. I have a explanation of it in the > > articles. It doesn't really matter if your website can handle 80 > > concurrent requests reliably, if you're server is on a T1. I would say > > JMeter can easily produce enough stress to figure out what the upper > > limit is for your web application. The situations where it won't be > > suitable is if you're testing a system that has to support 5,000 > > concurrent users. You still could use JMeter if you setup each > > instance with 100 threads and use 50 machines. > > > > realistically, to do that kind of test, the server would have to be a > > big Unix box or mainframe hooked up to several gigabit routers. Using > > 100mbit ethernet, you wouldn't be able to test 5K concurrent requests > > for a sustained period of time effectively. Sustained transfer rate > > plays a huge role in how many concurrent requests a system can handle > > reliably for a long time. > > > > peter > > > > > > > > On Thu, 15 Jul 2004 11:25:50 -0400, joelsherriff > > <[EMAIL PROTECTED]> wrote: > > > After Peter pointed out that the jmeter proxy doesn't do ssl, I thought > I'd > > > ask everyone if they know of other limitations they've run into and > about > > > what seems to be the cronic limitation of these tools - scalability. > Not > > > talking about bugs per se, just things you might have been able to do > with > > > other tools you can't do with jmeter. Like, does jmeter support NTLM > > > authentication? (I realize that's a question, not a statement, but some > > > other tools have problems with NTLM so I thought I'd throw it out > there.) > > > > > > As to scalability...How many users can you emulate before saturating > your > > > driver machine given an "average" script (mix of text and graphics, > etc)? > > > Given something like a 3Ghz P4 with 1M of memory. > > > > > > I originally did intend to play with jmeter more and lurk on this list > much > > > longer before asking these types of questions, but, as always, it's > faster > > > to ask... > > > > > > J > > > > > > - > > > 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 PROTECT
Re: Any other limitations of jmeter? How about scalability?
Agree - my background is in writing commercial test tools - was team lead for Compuware on the web team for QALoad, before that with Rational/Pure/Performix (way way back when). So the big tests 1000+ users are what I'm used to dealing with. Right now I've been asked to evaluate jmeter against the commercial tools and scalability is always the killer - esp when you look at the tools that drive the server by driving instances of a browser (yuck!). I'm really liking jmeter - much better than I expected it to be. I expected to find lot's of holes and limitations (the arrogance of the old-timer) but really haven't seen any that aren't there for pretty good reason - like the proxy/ssl issue. To distill down something you said, and ignoring the network limitations (since that's such a variable): so in your experience you get about 100 threads per machine before it saturates it? Is it typically CPU bound or memory or...? J - Original Message - From: "Peter Lin" <[EMAIL PROTECTED]> To: "JMeter Users List" <[EMAIL PROTECTED]> Sent: Thursday, July 15, 2004 11:43 AM Subject: Re: Any other limitations of jmeter? How about scalability? > for general performance testing stuff, I have several performance > articles listed on the links page > http://wiki.apache.org/jakarta-jmeter/JMeterLinks. > > If I compare JMeter to other tools I've used, I would say it is > comparable. The tools I've used: > > 1. apache ab > 2. zdnet Webbench > 3. custom script perl > > The biggest challenge of stress testing is this, "what are you > testing?" Most of the time, the bottleneck for a website is the > connection to the internet. I have a explanation of it in the > articles. It doesn't really matter if your website can handle 80 > concurrent requests reliably, if you're server is on a T1. I would say > JMeter can easily produce enough stress to figure out what the upper > limit is for your web application. The situations where it won't be > suitable is if you're testing a system that has to support 5,000 > concurrent users. You still could use JMeter if you setup each > instance with 100 threads and use 50 machines. > > realistically, to do that kind of test, the server would have to be a > big Unix box or mainframe hooked up to several gigabit routers. Using > 100mbit ethernet, you wouldn't be able to test 5K concurrent requests > for a sustained period of time effectively. Sustained transfer rate > plays a huge role in how many concurrent requests a system can handle > reliably for a long time. > > peter > > > > On Thu, 15 Jul 2004 11:25:50 -0400, joelsherriff > <[EMAIL PROTECTED]> wrote: > > After Peter pointed out that the jmeter proxy doesn't do ssl, I thought I'd > > ask everyone if they know of other limitations they've run into and about > > what seems to be the cronic limitation of these tools - scalability. Not > > talking about bugs per se, just things you might have been able to do with > > other tools you can't do with jmeter. Like, does jmeter support NTLM > > authentication? (I realize that's a question, not a statement, but some > > other tools have problems with NTLM so I thought I'd throw it out there.) > > > > As to scalability...How many users can you emulate before saturating your > > driver machine given an "average" script (mix of text and graphics, etc)? > > Given something like a 3Ghz P4 with 1M of memory. > > > > I originally did intend to play with jmeter more and lurk on this list much > > longer before asking these types of questions, but, as always, it's faster > > to ask... > > > > J > > > > - > > 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]
Re: Any other limitations of jmeter? How about scalability?
haha, that's funny. I didn't think of that. But then again, I'm busy porting CLIPS to java, so I don't have much time :) as soon as I find a way to go without sleep, I'll get that done yesterday. peter On Thu, 15 Jul 2004 12:52:20 -0400, Michael Stover <[EMAIL PROTECTED]> wrote: > If you want to record scripts with https, then you might try badboy (I > don't know the url). I think it is an IE plugin type thing that can > export rudimentary JMeter scripts. > > I usually advise people record the scripts with https turned off on the > server, then turn it on for playback. I think this is more reliable > than using a fake server that records and resends requests. > > IMO, the only good solution would be to embed a browser in JMeter that > allows users to browse normally, and allows JMeter access to the request > details before they are encrypted. But, I don't know of any > non-commercial java browsers that are anywhere near adequate. > > Peter, maybe you should turn jazillian onto gecko :-) > > -Mike > > > > On Thu, 2004-07-15 at 11:25, joelsherriff wrote: > > After Peter pointed out that the jmeter proxy doesn't do ssl, I thought I'd > > ask everyone if they know of other limitations they've run into and about > > what seems to be the cronic limitation of these tools - scalability. Not > > talking about bugs per se, just things you might have been able to do with > > other tools you can't do with jmeter. Like, does jmeter support NTLM > > authentication? (I realize that's a question, not a statement, but some > > other tools have problems with NTLM so I thought I'd throw it out there.) > > > > As to scalability...How many users can you emulate before saturating your > > driver machine given an "average" script (mix of text and graphics, etc)? > > Given something like a 3Ghz P4 with 1M of memory. > > > > I originally did intend to play with jmeter more and lurk on this list much > > longer before asking these types of questions, but, as always, it's faster > > to ask... > > > > J > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > -- > Michael Stover <[EMAIL PROTECTED]> > Apache Software Foundation > > > > > - > 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]
Re: Any other limitations of jmeter? How about scalability?
As to NTLM, the Apache HTTPClient implementation is supposed to be able to support that, but the code has not yet been added to the sampler. Feel free to create a Bugzilla enhancement request ... S. - Original Message - From: "joelsherriff" <[EMAIL PROTECTED]> To: "JMeter Users List" <[EMAIL PROTECTED]> Sent: Thursday, July 15, 2004 4:25 PM Subject: Any other limitations of jmeter? How about scalability? > After Peter pointed out that the jmeter proxy doesn't do ssl, I thought I'd > ask everyone if they know of other limitations they've run into and about > what seems to be the cronic limitation of these tools - scalability. Not > talking about bugs per se, just things you might have been able to do with > other tools you can't do with jmeter. Like, does jmeter support NTLM > authentication? (I realize that's a question, not a statement, but some > other tools have problems with NTLM so I thought I'd throw it out there.) > > As to scalability...How many users can you emulate before saturating your > driver machine given an "average" script (mix of text and graphics, etc)? > Given something like a 3Ghz P4 with 1M of memory. > > I originally did intend to play with jmeter more and lurk on this list much > longer before asking these types of questions, but, as always, it's faster > to ask... > > J > > > > - > 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]
Re: Any other limitations of jmeter? How about scalability?
If you want to record scripts with https, then you might try badboy (I don't know the url). I think it is an IE plugin type thing that can export rudimentary JMeter scripts. I usually advise people record the scripts with https turned off on the server, then turn it on for playback. I think this is more reliable than using a fake server that records and resends requests. IMO, the only good solution would be to embed a browser in JMeter that allows users to browse normally, and allows JMeter access to the request details before they are encrypted. But, I don't know of any non-commercial java browsers that are anywhere near adequate. Peter, maybe you should turn jazillian onto gecko :-) -Mike On Thu, 2004-07-15 at 11:25, joelsherriff wrote: > After Peter pointed out that the jmeter proxy doesn't do ssl, I thought I'd > ask everyone if they know of other limitations they've run into and about > what seems to be the cronic limitation of these tools - scalability. Not > talking about bugs per se, just things you might have been able to do with > other tools you can't do with jmeter. Like, does jmeter support NTLM > authentication? (I realize that's a question, not a statement, but some > other tools have problems with NTLM so I thought I'd throw it out there.) > > As to scalability...How many users can you emulate before saturating your > driver machine given an "average" script (mix of text and graphics, etc)? > Given something like a 3Ghz P4 with 1M of memory. > > I originally did intend to play with jmeter more and lurk on this list much > longer before asking these types of questions, but, as always, it's faster > to ask... > > J > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Stover <[EMAIL PROTECTED]> Apache Software Foundation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any other limitations of jmeter? How about scalability?
for general performance testing stuff, I have several performance articles listed on the links page http://wiki.apache.org/jakarta-jmeter/JMeterLinks. If I compare JMeter to other tools I've used, I would say it is comparable. The tools I've used: 1. apache ab 2. zdnet Webbench 3. custom script perl The biggest challenge of stress testing is this, "what are you testing?" Most of the time, the bottleneck for a website is the connection to the internet. I have a explanation of it in the articles. It doesn't really matter if your website can handle 80 concurrent requests reliably, if you're server is on a T1. I would say JMeter can easily produce enough stress to figure out what the upper limit is for your web application. The situations where it won't be suitable is if you're testing a system that has to support 5,000 concurrent users. You still could use JMeter if you setup each instance with 100 threads and use 50 machines. realistically, to do that kind of test, the server would have to be a big Unix box or mainframe hooked up to several gigabit routers. Using 100mbit ethernet, you wouldn't be able to test 5K concurrent requests for a sustained period of time effectively. Sustained transfer rate plays a huge role in how many concurrent requests a system can handle reliably for a long time. peter On Thu, 15 Jul 2004 11:25:50 -0400, joelsherriff <[EMAIL PROTECTED]> wrote: > After Peter pointed out that the jmeter proxy doesn't do ssl, I thought I'd > ask everyone if they know of other limitations they've run into and about > what seems to be the cronic limitation of these tools - scalability. Not > talking about bugs per se, just things you might have been able to do with > other tools you can't do with jmeter. Like, does jmeter support NTLM > authentication? (I realize that's a question, not a statement, but some > other tools have problems with NTLM so I thought I'd throw it out there.) > > As to scalability...How many users can you emulate before saturating your > driver machine given an "average" script (mix of text and graphics, etc)? > Given something like a 3Ghz P4 with 1M of memory. > > I originally did intend to play with jmeter more and lurk on this list much > longer before asking these types of questions, but, as always, it's faster > to ask... > > J > > - > 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]
Any other limitations of jmeter? How about scalability?
After Peter pointed out that the jmeter proxy doesn't do ssl, I thought I'd ask everyone if they know of other limitations they've run into and about what seems to be the cronic limitation of these tools - scalability. Not talking about bugs per se, just things you might have been able to do with other tools you can't do with jmeter. Like, does jmeter support NTLM authentication? (I realize that's a question, not a statement, but some other tools have problems with NTLM so I thought I'd throw it out there.) As to scalability...How many users can you emulate before saturating your driver machine given an "average" script (mix of text and graphics, etc)? Given something like a 3Ghz P4 with 1M of memory. I originally did intend to play with jmeter more and lurk on this list much longer before asking these types of questions, but, as always, it's faster to ask... J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: https url using Jmeter- pls help
I had the intention of writing something to import logs obtained by Daniel Savard's "Live HTTP Headers" extension for Mozilla. This would provide a way to create scripts for HTTP sites -- not perfect (since it would be limited to browsers able to run the extension), but better than nothing. Unfortunately I've been too busy in recent months, and I don't expect things to change soon, so anyone wanting to take on the idea... -- Salut, Jordi. Peter Lin wrote: I wouldn't call it a bug. More like an enhancement request. I generally don't stress test HTTPS, because it's hard to scale SSL/HTTPS without hardware accelerators. With hardware assistance, the performance is very close to normal (non-HTTPS) performance. BigIP is a popular setup for large banks. Basically BigIP handles all the SSL/HTTPS/encryption and the webservers only do non-encrypted traffic. which explains why the webservers perform the same. That's my preference personally, since it makes it easier to test and much easier to manage. without hardware assistance, SysAdmins resort to hacks to maintain the webservers. At a previous job, IIS set to round robin reboot on 15-30minute intervals, because the SSL traffic would hose windowsNT and IIS. It's also one of the reasons why win2K and win2K3 have an automatic restart feature. It's actually used to make sure the server is restarted ASAP. With Apache, I know plenty of SysAdmins that wrote PERL scripts to monitor httpd and restart it when it dies under HTTPS load. I hope that helps peter On Thu, 15 Jul 2004 09:17:41 -0400, joelsherriff <[EMAIL PROTECTED]> wrote: Peter, Glad you've pointed this out. Other tool's proxy servers do this (proxy SSL) by acting as server to the client and client to the server, decrypting browser requests and re-encrypting them to forward to the server. The only problem is when the client or server insists on being picky about certificates - but it works for most cases. I'm trying to find all of the limitations of jmeter and this is the first entry on my list - that's too bad. I wonder if anyone has put any effort into "fixing" this? J - Original Message - From: "Peter Lin" <[EMAIL PROTECTED]> To: "JMeter Users List" <[EMAIL PROTECTED]> Sent: Thursday, July 15, 2004 8:33 AM Subject: Re: https url using Jmeter- pls help I believe the proxy server cannot handle SSL or HTTPS. if it could, it would mean SSL is not secure. Others have asked the same question before. you have a couple options. 1. use http and simply change the test plan after you're done recording. assuming you can still use your web applications in insecure mode 2. use some other tool 3. manually create the test plan peter On Thu, 15 Jul 2004 11:18:17 +0530, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: hi i am using Jmeter to test a https site i am behind a fire wall and used -u and -a options to connect through the proxy server. it is workig fine for the http url while for https url it is showing a following error: java.io.IOException: Unable to tunnel through 10.200.102.5:8080. Proxy returns "HTTP/1.0 407 Proxy Authentication Required" if some one has coem acros such a problem previously, please help me out. thanks and rgds Nithya L Nathan Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. - 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]
Re: https url using Jmeter- pls help
yeah, I know what you mean. customers like to pinch pennies, which makes it hard for developers to do their job effectively. honestly, for something like https testing, it's going to be hard to avoid paying for commercial software like Mercury webrunner. HTTPS performance is linear and very predictable. most of the vendors have benchmarks comparing software vs. hardware performance. peter On Thu, 15 Jul 2004 11:05:35 -0400, joelsherriff <[EMAIL PROTECTED]> wrote: > Yeah, I agree - not a bug since the proxy works as designed, but definitely > a limitation. Hard to tell your customer they have to reconfigure their > system (buy hardware) before you can load test them (or capture unsecure) > when they just want to find the breaking point of their https > traffic/server. At that point it's probably cheaper to cough up the dough > for a commercial load test tool that can capture ssl. Sometimes you can get > away with capturing unsecure and playing back secure, but the customers > never seem to trust this. > > J > > > > - Original Message - > From: "Peter Lin" <[EMAIL PROTECTED]> > To: "JMeter Users List" <[EMAIL PROTECTED]> > Sent: Thursday, July 15, 2004 9:34 AM > Subject: Re: https url using Jmeter- pls help > > > I wouldn't call it a bug. More like an enhancement request. > > > > I generally don't stress test HTTPS, because it's hard to scale > > SSL/HTTPS without hardware accelerators. With hardware assistance, the > > performance is very close to normal (non-HTTPS) performance. > > > > BigIP is a popular setup for large banks. Basically BigIP handles all > > the SSL/HTTPS/encryption and the webservers only do non-encrypted > > traffic. which explains why the webservers perform the same. > > > > That's my preference personally, since it makes it easier to test and > > much easier to manage. without hardware assistance, SysAdmins resort > > to hacks to maintain the webservers. At a previous job, IIS set to > > round robin reboot on 15-30minute intervals, because the SSL traffic > > would hose windowsNT and IIS. > > > > It's also one of the reasons why win2K and win2K3 have an automatic > > restart feature. It's actually used to make sure the server is > > restarted ASAP. With Apache, I know plenty of SysAdmins that wrote > > PERL scripts to monitor httpd and restart it when it dies under HTTPS > > load. > > > > I hope that helps > > > > peter > > > > > > On Thu, 15 Jul 2004 09:17:41 -0400, joelsherriff > > <[EMAIL PROTECTED]> wrote: > > > Peter, > > > > > > Glad you've pointed this out. Other tool's proxy servers do this (proxy > > > SSL) by acting as server to the client and client to the server, > decrypting > > > browser requests and re-encrypting them to forward to the server. The > only > > > problem is when the client or server insists on being picky about > > > certificates - but it works for most cases. I'm trying to find all of > the > > > limitations of jmeter and this is the first entry on my list - that's > too > > > bad. I wonder if anyone has put any effort into "fixing" this? > > > > > > J > > > > > > > > > > > > - Original Message - > > > From: "Peter Lin" <[EMAIL PROTECTED]> > > > To: "JMeter Users List" <[EMAIL PROTECTED]> > > > Sent: Thursday, July 15, 2004 8:33 AM > > > Subject: Re: https url using Jmeter- pls help > > > > > > > I believe the proxy server cannot handle SSL or HTTPS. > > > > > > > > if it could, it would mean SSL is not secure. Others have asked the > > > > same question before. you have a couple options. > > > > > > > > 1. use http and simply change the test plan after you're done > > > > recording. assuming you can still use your web applications in > > > > insecure mode > > > > > > > > 2. use some other tool > > > > > > > > 3. manually create the test plan > > > > > > > > peter > > > > > > > > > > > > On Thu, 15 Jul 2004 11:18:17 +0530, [EMAIL PROTECTED] > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > hi > > > > > i am using Jmeter to test a https site > > > > > i am behind a fire wall and used -u and -a options to connect > through > > > > > the proxy server. it is workig fine for the http url while for https > url > > > > > it is showing a following error: > > > > > java.io.IOException: Unable to tunnel through 10.200.102.5:8080. > Proxy > > > > > returns "HTTP/1.0 407 Proxy Authentication Required" > > > > > > > > > > if some one has coem acros such a problem previously, please help me > > > > > out. > > > > > thanks and rgds > > > > > Nithya L Nathan > > > > > > > > > > Confidentiality Notice > > > > > > > > > > The information contained in this electronic message and any > attachments > > > to this message are intended > > > > > for the exclusive use of the addressee(s) and may contain > confidential > > > or privileged information. If > > > > > you are not the intended recipient, please notify the sender at > Wipro or > > > [EMAIL PROTECTED] immediately > > > > > and destroy all copies of this message and any attach
Re: https url using Jmeter- pls help
Yeah, I agree - not a bug since the proxy works as designed, but definitely a limitation. Hard to tell your customer they have to reconfigure their system (buy hardware) before you can load test them (or capture unsecure) when they just want to find the breaking point of their https traffic/server. At that point it's probably cheaper to cough up the dough for a commercial load test tool that can capture ssl. Sometimes you can get away with capturing unsecure and playing back secure, but the customers never seem to trust this. J - Original Message - From: "Peter Lin" <[EMAIL PROTECTED]> To: "JMeter Users List" <[EMAIL PROTECTED]> Sent: Thursday, July 15, 2004 9:34 AM Subject: Re: https url using Jmeter- pls help > I wouldn't call it a bug. More like an enhancement request. > > I generally don't stress test HTTPS, because it's hard to scale > SSL/HTTPS without hardware accelerators. With hardware assistance, the > performance is very close to normal (non-HTTPS) performance. > > BigIP is a popular setup for large banks. Basically BigIP handles all > the SSL/HTTPS/encryption and the webservers only do non-encrypted > traffic. which explains why the webservers perform the same. > > That's my preference personally, since it makes it easier to test and > much easier to manage. without hardware assistance, SysAdmins resort > to hacks to maintain the webservers. At a previous job, IIS set to > round robin reboot on 15-30minute intervals, because the SSL traffic > would hose windowsNT and IIS. > > It's also one of the reasons why win2K and win2K3 have an automatic > restart feature. It's actually used to make sure the server is > restarted ASAP. With Apache, I know plenty of SysAdmins that wrote > PERL scripts to monitor httpd and restart it when it dies under HTTPS > load. > > I hope that helps > > peter > > > On Thu, 15 Jul 2004 09:17:41 -0400, joelsherriff > <[EMAIL PROTECTED]> wrote: > > Peter, > > > > Glad you've pointed this out. Other tool's proxy servers do this (proxy > > SSL) by acting as server to the client and client to the server, decrypting > > browser requests and re-encrypting them to forward to the server. The only > > problem is when the client or server insists on being picky about > > certificates - but it works for most cases. I'm trying to find all of the > > limitations of jmeter and this is the first entry on my list - that's too > > bad. I wonder if anyone has put any effort into "fixing" this? > > > > J > > > > > > > > - Original Message - > > From: "Peter Lin" <[EMAIL PROTECTED]> > > To: "JMeter Users List" <[EMAIL PROTECTED]> > > Sent: Thursday, July 15, 2004 8:33 AM > > Subject: Re: https url using Jmeter- pls help > > > > > I believe the proxy server cannot handle SSL or HTTPS. > > > > > > if it could, it would mean SSL is not secure. Others have asked the > > > same question before. you have a couple options. > > > > > > 1. use http and simply change the test plan after you're done > > > recording. assuming you can still use your web applications in > > > insecure mode > > > > > > 2. use some other tool > > > > > > 3. manually create the test plan > > > > > > peter > > > > > > > > > On Thu, 15 Jul 2004 11:18:17 +0530, [EMAIL PROTECTED] > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > hi > > > > i am using Jmeter to test a https site > > > > i am behind a fire wall and used -u and -a options to connect through > > > > the proxy server. it is workig fine for the http url while for https url > > > > it is showing a following error: > > > > java.io.IOException: Unable to tunnel through 10.200.102.5:8080. Proxy > > > > returns "HTTP/1.0 407 Proxy Authentication Required" > > > > > > > > if some one has coem acros such a problem previously, please help me > > > > out. > > > > thanks and rgds > > > > Nithya L Nathan > > > > > > > > Confidentiality Notice > > > > > > > > The information contained in this electronic message and any attachments > > to this message are intended > > > > for the exclusive use of the addressee(s) and may contain confidential > > or privileged information. If > > > > you are not the intended recipient, please notify the sender at Wipro or > > [EMAIL PROTECTED] immediately > > > > and destroy all copies of this message and any attachments. > > > > > > > > - > > > > 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 P
Re: Hi any one pls help me
Hi, maybe you want to try this in a Regular Expression Extractor: sid=(\S+) supposed the String is only one line. I use a little Win Prog for testing RegExpression maybe it wil help you too. http://weitz.de/regex-coach/ Kind Regards Frank |-+> | | Michael Stover | | | <[EMAIL PROTECTED]| | | org> | | || | | 15.07.2004 14:25 | | | Bitte antworten | | | an "JMeter Users | | | List"| | || |-+> >--| | | | An: JMeter Users List <[EMAIL PROTECTED]> | | Kopie: | | Thema:Re: Hi any one pls help me | >--| The problem is your regular expression. .* will grab the whole page. you'd be better off with something like sid="?([[^ ]*) But, I can only guess since I don't really know the nature of your sid values. -Mike On Wed, 2004-07-14 at 22:28, Krishna, Raj wrote: > Hi there, > > > > I am not able to capture and httprequest attribute value > > > > sid=1401bc9b1cca027f83343a68204d8c9cce9f1f93c3d0a0acf90e8e2a1fef4adc2760 > 2f2e64092a65e8bda1c329e3c8f4ddd4ebb994c0cca5686a5c555a73bff1ba6ad6f4a4c1 > b3d3fd936fbd5a7c200b > > > > I have used the Regular Expression Extractor but in vain. > > > > This is what I have used. > > > > Regular expression :sid=(.*) > > > > And I tired this > > > > Regular expression :sid=(*) > > > > I am not able to capture this long length of number and letters. Pls if > any one how to pls let me know. > > > > Cheers > > Raj > > > > > > > -- Michael Stover <[EMAIL PROTECTED]> Apache Software Foundation - 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]
Re: https url using Jmeter- pls help
I wouldn't call it a bug. More like an enhancement request. I generally don't stress test HTTPS, because it's hard to scale SSL/HTTPS without hardware accelerators. With hardware assistance, the performance is very close to normal (non-HTTPS) performance. BigIP is a popular setup for large banks. Basically BigIP handles all the SSL/HTTPS/encryption and the webservers only do non-encrypted traffic. which explains why the webservers perform the same. That's my preference personally, since it makes it easier to test and much easier to manage. without hardware assistance, SysAdmins resort to hacks to maintain the webservers. At a previous job, IIS set to round robin reboot on 15-30minute intervals, because the SSL traffic would hose windowsNT and IIS. It's also one of the reasons why win2K and win2K3 have an automatic restart feature. It's actually used to make sure the server is restarted ASAP. With Apache, I know plenty of SysAdmins that wrote PERL scripts to monitor httpd and restart it when it dies under HTTPS load. I hope that helps peter On Thu, 15 Jul 2004 09:17:41 -0400, joelsherriff <[EMAIL PROTECTED]> wrote: > Peter, > > Glad you've pointed this out. Other tool's proxy servers do this (proxy > SSL) by acting as server to the client and client to the server, decrypting > browser requests and re-encrypting them to forward to the server. The only > problem is when the client or server insists on being picky about > certificates - but it works for most cases. I'm trying to find all of the > limitations of jmeter and this is the first entry on my list - that's too > bad. I wonder if anyone has put any effort into "fixing" this? > > J > > > > - Original Message - > From: "Peter Lin" <[EMAIL PROTECTED]> > To: "JMeter Users List" <[EMAIL PROTECTED]> > Sent: Thursday, July 15, 2004 8:33 AM > Subject: Re: https url using Jmeter- pls help > > > I believe the proxy server cannot handle SSL or HTTPS. > > > > if it could, it would mean SSL is not secure. Others have asked the > > same question before. you have a couple options. > > > > 1. use http and simply change the test plan after you're done > > recording. assuming you can still use your web applications in > > insecure mode > > > > 2. use some other tool > > > > 3. manually create the test plan > > > > peter > > > > > > On Thu, 15 Jul 2004 11:18:17 +0530, [EMAIL PROTECTED] > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > hi > > > i am using Jmeter to test a https site > > > i am behind a fire wall and used -u and -a options to connect through > > > the proxy server. it is workig fine for the http url while for https url > > > it is showing a following error: > > > java.io.IOException: Unable to tunnel through 10.200.102.5:8080. Proxy > > > returns "HTTP/1.0 407 Proxy Authentication Required" > > > > > > if some one has coem acros such a problem previously, please help me > > > out. > > > thanks and rgds > > > Nithya L Nathan > > > > > > Confidentiality Notice > > > > > > The information contained in this electronic message and any attachments > to this message are intended > > > for the exclusive use of the addressee(s) and may contain confidential > or privileged information. If > > > you are not the intended recipient, please notify the sender at Wipro or > [EMAIL PROTECTED] immediately > > > and destroy all copies of this message and any attachments. > > > > > > - > > > 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]
Re: https url using Jmeter- pls help
Peter, Glad you've pointed this out. Other tool's proxy servers do this (proxy SSL) by acting as server to the client and client to the server, decrypting browser requests and re-encrypting them to forward to the server. The only problem is when the client or server insists on being picky about certificates - but it works for most cases. I'm trying to find all of the limitations of jmeter and this is the first entry on my list - that's too bad. I wonder if anyone has put any effort into "fixing" this? J - Original Message - From: "Peter Lin" <[EMAIL PROTECTED]> To: "JMeter Users List" <[EMAIL PROTECTED]> Sent: Thursday, July 15, 2004 8:33 AM Subject: Re: https url using Jmeter- pls help > I believe the proxy server cannot handle SSL or HTTPS. > > if it could, it would mean SSL is not secure. Others have asked the > same question before. you have a couple options. > > 1. use http and simply change the test plan after you're done > recording. assuming you can still use your web applications in > insecure mode > > 2. use some other tool > > 3. manually create the test plan > > peter > > > On Thu, 15 Jul 2004 11:18:17 +0530, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: > > > > > > hi > > i am using Jmeter to test a https site > > i am behind a fire wall and used -u and -a options to connect through > > the proxy server. it is workig fine for the http url while for https url > > it is showing a following error: > > java.io.IOException: Unable to tunnel through 10.200.102.5:8080. Proxy > > returns "HTTP/1.0 407 Proxy Authentication Required" > > > > if some one has coem acros such a problem previously, please help me > > out. > > thanks and rgds > > Nithya L Nathan > > > > Confidentiality Notice > > > > The information contained in this electronic message and any attachments to this message are intended > > for the exclusive use of the addressee(s) and may contain confidential or privileged information. If > > you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately > > and destroy all copies of this message and any attachments. > > > > - > > 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]
Re: Hi any one pls help me
The problem is your regular expression. .* will grab the whole page. you'd be better off with something like sid="?([[^ ]*) But, I can only guess since I don't really know the nature of your sid values. -Mike On Wed, 2004-07-14 at 22:28, Krishna, Raj wrote: > Hi there, > > > > I am not able to capture and httprequest attribute value > > > > sid=1401bc9b1cca027f83343a68204d8c9cce9f1f93c3d0a0acf90e8e2a1fef4adc2760 > 2f2e64092a65e8bda1c329e3c8f4ddd4ebb994c0cca5686a5c555a73bff1ba6ad6f4a4c1 > b3d3fd936fbd5a7c200b > > > > I have used the Regular Expression Extractor but in vain. > > > > This is what I have used. > > > > Regular expression :sid=(.*) > > > > And I tired this > > > > Regular expression :sid=(*) > > > > I am not able to capture this long length of number and letters. Pls if > any one how to pls let me know. > > > > Cheers > > Raj > > > > > > > -- Michael Stover <[EMAIL PROTECTED]> Apache Software Foundation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: https url using Jmeter- pls help
running jmeter through a proxy server requiring authentication: http://jakarta.apache.org/jmeter/usermanual/get-started.html#proxy_server -Mike On Thu, 2004-07-15 at 01:48, [EMAIL PROTECTED] wrote: > > hi > i am using Jmeter to test a https site > i am behind a fire wall and used -u and -a options to connect through > the proxy server. it is workig fine for the http url while for https url > it is showing a following error: > java.io.IOException: Unable to tunnel through 10.200.102.5:8080. Proxy > returns "HTTP/1.0 407 Proxy Authentication Required" > > if some one has coem acros such a problem previously, please help me > out. > thanks and rgds > Nithya L Nathan > > Confidentiality Notice > > The information contained in this electronic message and any attachments to this > message are intended > for the exclusive use of the addressee(s) and may contain confidential or privileged > information. If > you are not the intended recipient, please notify the sender at Wipro or [EMAIL > PROTECTED] immediately > and destroy all copies of this message and any attachments. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Stover <[EMAIL PROTECTED]> Apache Software Foundation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: https url using Jmeter- pls help
I believe the proxy server cannot handle SSL or HTTPS. if it could, it would mean SSL is not secure. Others have asked the same question before. you have a couple options. 1. use http and simply change the test plan after you're done recording. assuming you can still use your web applications in insecure mode 2. use some other tool 3. manually create the test plan peter On Thu, 15 Jul 2004 11:18:17 +0530, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > hi > i am using Jmeter to test a https site > i am behind a fire wall and used -u and -a options to connect through > the proxy server. it is workig fine for the http url while for https url > it is showing a following error: > java.io.IOException: Unable to tunnel through 10.200.102.5:8080. Proxy > returns "HTTP/1.0 407 Proxy Authentication Required" > > if some one has coem acros such a problem previously, please help me > out. > thanks and rgds > Nithya L Nathan > > Confidentiality Notice > > The information contained in this electronic message and any attachments to this > message are intended > for the exclusive use of the addressee(s) and may contain confidential or privileged > information. If > you are not the intended recipient, please notify the sender at Wipro or [EMAIL > PROTECTED] immediately > and destroy all copies of this message and any attachments. > > - > 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]
