posted 10-10-2002 09:47 AM         

Could someone please advise me if there is such concept as a 0 time delay even for static pages?

We use Rational Team Test and I was asked to perform a test using 100 virtual users and have 0 sec time delay... Well, I changed the settings of the tool, but it is just... I don't really understand how there could be 0 sec time delays? \

Thanks in advance.
With Best regards,

------------------
Kina

posted 10-10-2002 10:12 AM         

Second. What they are asking you to do, whether they realize it or not, is a stress test. Rather than opening up the semantical arguement about what terms to use for different types of tests, let me just say this. The test they have asked you to do may be useful for detecting system stability, memory leaks, resource contention issues and many other issues if conducted and monitored properly. What it will NOT do is predict the actual end-to-end response time for 100 (or 1000, or even 2) users. It will NOT apply a load on the sytem that will ever be applied when the system is in production.

I suggest being very careful about these types of tests. They can be very valuable when looking for something specific, but results from them can be extremely misleading when not quoted properly.

Take a look at article 8 on www.perftestplus.com (under publications). It talks about different types of tests and what they are and are not good for. (Yes it uses my terms that other members of the forum may or may not use in the same way, but it does include definitions!) The article may be a useful starting point for communications with the folks who are asking you to execute these tests.

Good luck!

posted 10-10-2002 11:09 AM         

This is just a prototype, ASP sessions, and developer just wants to measure the performance of different components: prototype with just static pages, then performance of the database by itself, then common frame work, then the intgrated site itself and etc. etc.

Today's task is a Prototype, I ran the stress test on the prototype with VUs and i got all passed (time delay=5 sec, and set think_avg = 100 ms). The developer was surprised when found that results that we got were showing that the response time is pretty high - max% 36 sec at the login page. He wasn't able to understand why static page is taking so long, and to be honest, I wasn't sure myself.... Could you help me please?

Thank you.

P.S. The site that you always refer to is awesome, I believe that this is the information that can be put together after "million" years of working experience. Thanks for sharing with us

------------------
Kina

[This message has been edited by konulr (edited 10-10-2002).]

posted 10-10-2002 12:28 PM         

First - are those times for actually logging in, or just launching the login page?

If logging in, make sure that you are simulating 100 DIFFERENT users (especially if you are using LDAP). I have yet to figure out why, but LDAP gets really confused when one user tries to authenticate a whole bunch of times in a short period of time.

If just painting the login page - try playing with arrival rate. One user every 5 sec, then 3, then 1, etc. See how that changes the response time (you may try that for if it is logging in as well).

2) Look at the scatter chart. (If you aren't familiar with analyzing scatter charts, take a screenshot and attach it). I am guessing that what is really happening is that you are getting requests all queued up somewhere and that it's not really response time that is bad, but threading or throughput or concurrent connection configuration on the web server or something.

3) For your times between pages do me a favor and put this line in between your start and stop times...

delay(uniform(4000,6000));

instead of think_avg. You can change the values (they are in milliseconds) but using a range instead of a static number will keep your test from "strobing" which sometimes just causes weird things to happen.

Thanks for the compliment on the site. My wife deserves most of the credit. She is the one who gets all that stuff out of my head and into some kind of format that other people can understand!

posted 10-10-2002 01:33 PM         

Answers:
1. It is not the actual login, there is no authentication at this point, I just click on the Login without any inputs in UserId and Password fields.
2.Regarding the "scatter", I assume that you are talking about Response vs Time chart, and you are right - commands do not perform at the same time. I actually ran the script with syncpoints and got 2 failures out of 100 VUs
3. I modified the script with line that you provided, but unfortunately wasn't able to execute it as someone else is using the tool we have just 1 license). I will try it next week.

I am attaching the printout of the chart for your review, hope that is what you were referring to .

With Best Regards,

P.S. My Respect and Thanks to your wife, she has done a great job. Women are always good in organizing .

------------------
Kina

posted 10-10-2002 03:01 PM         

If it won't go through for some reason, feel free to email me.

oh, and yes, the Response vs. Time chart, selecting the scatter radio button.

hmm - no real authentication yet, huh. What web server are you using? Can you verify that the concurrent user setting/license is configured correctly? Several of them default at 3. That very often leads to odd results in the beginning until someone fixes that.

posted 10-17-2002 10:48 AM         

ResponsevsTime.doc Table.doc

Sorry for silence, could not get to the forum..

Today I ran the modified script (used Delay(Uniform(4000, 6000)), and as a result 2 users failed and 98 passed. Seems like Rational script timedout after 4 minutes after Disclaimer page.

I attached the Resp vs Time graph and table, hope it will give more details.

Thanks for your help,

posted 10-17-2002 12:14 PM         

The first think I notice is that 4 users started at (almost exactly) the same time, then the other 96 started at (almost exactly) the same time. You are going to want to stagger the start of those users over some amount of time. The easiest way is to put a synchronization point in your suite before your script. Try something like a saggered from 0 to 600 seconds. (1 user every 6 seconds) That should give you some significantly improved performance.

View that on the response vs. time (to get the scatter version, run the response vs. time report, right click, settings, graph type scatter). Then, if you want to see what happens, incrementally decrease the time in the sync point and/or your delays until response times start getting worse.

How's that?

posted 10-17-2002 01:22 PM         

I am going to play with the numbers in order to get the failure, and hope nothing unexpected will arise. Meanwhile I would like to thank you for your rush reply and REAL help.

With Best Regards,