SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 7 of 7

Thread: Ramp Down

  1. #1
    Member
    Join Date
    Sep 2006
    Posts
    41
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Ramp Down

    Does anyone know if there is a way to set a rampdown period within QALoad? I know in LR that you can set a rampdown time so a user drops off every 5 seconds for example but have never found an option for this in QALoad or have read anywhere about any methods of achieving this.

    The reason I need to try and implement some sort of rampdown is to avoid a 'big-bang' effect on exit. What is currently happening is that for a high number of users they are waiting due to the pacing. When the test exits all of these users jump out of the transaction loop and attempt to exit the system at exactly the same time causing a 503 to be returned. Any ideas?

  2. #2
    Member
    Join Date
    Aug 2007
    Posts
    238
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Ramp Down

    You could setup the conductor based on number of transactions rather than session duration. Then setup the VUsers as increasing for the beginning of the test.

    If all users need to execute 100 transactions the first 10 will complete before the last 10 and should also logoff first. This should create the effect of a decreasing user count.

    Let us know what you come up with.

  3. #3
    Member
    Join Date
    Sep 2006
    Posts
    41
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Ramp Down

    Hi.

    Setting the number of transactions is a good idea but what I want to do is have the test run for a session time, say 4 hours and then gracefully exit.

    I have spoken to Compuware and they basically said achieving a ramp down isn't possible and asked me if I wanted to raise it as a product improvement. I have done as it is very poor not to have this in the first place.

    I have attempted to achieve some sort of ramp down by putting in a random delay after the end_transaction statement. This improved matters but due to the sheer number of users I have exiting it has not completely fixed the problem. One option is to not have the users exit gracefully after the end of a test as realistically all the data I need will have been during the period I was running at full concurrency. Still a pain though.

  4. #4
    Junior Member
    Join Date
    Apr 2008
    Location
    Arizona
    Posts
    14
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Ramp Down

    By "random delay", do you mean you have entered a fixed sleep value for each script? Like Sleep 30 for script A, Sleep 100 for script B, etc.?

    I was going to suggest this earlier, but wanted to think it over for a while. Actually, I would try putting this sleep statement into each script before the End_Transaction statement and turning off Pacing by setting it back to :01 for each script in Conductor.

    Then, a few trial runs may be necessary to tweak this sleep value for each script so that you are getting the desired throughput (trans/sec) that you want.

  5. #5
    Member
    Join Date
    Sep 2006
    Posts
    41
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Ramp Down

    By random delay i mean the statement RND_DELAY(#).

    So for example my script looks something a little bit like this:

    END_TRANSACTION();

    RND_DELAY(60);

    //logout code starts here

    What this achieves is a random wait for each user before they progress with the logout code. This staggers them but with the sheer number of users i have exiting it still causes a rush of requests and the corresponding 503 errors.

  6. #6
    Junior Member
    Join Date
    Apr 2008
    Location
    Arizona
    Posts
    14
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Ramp Down

    By using the RND_DELAY() function, I feel you are reducing your control over the test and you are going to get virtual users bunched together every once in a while.

    You would be exercising more control by replacing RND_DELAY(60) with Sleep(60) and using the Time Interval value in Conductor to add virtual users at several seconds apart.

    You may still get some transactions bunching together because of things like blocking on the database, but you can play with the Time Interval (4th tab in Conductor) and the Sleep Factor (on 2nd tab in Conductor) to see if you can reduce the 503 errors. Sleep Factor can be set to more than 100% by simply typing in a value.

    Of course, it may be that, if your servers are optimally tuned, you simply need more powerful servers to handle this load. You should be monitoring performance metrics on the servers, especially RAM and CPU%, to determine where the bottleneck lies.

  7. #7
    Member
    Join Date
    Nov 2007
    Location
    California
    Posts
    66
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Re: Ramp Down

    I agree with Godders - there should be an easy way to do this.

    Personally, I'm almost exclusively using the Vistree mode - as there's little that we haven't been able to do with it.

    But it does seem odd that you can't do this. Right now I'm having to do the following: 48 users ramp up over 10 minutes, then do their stuff, then after a half hour of solid activity (at the 40 minute mark) I'm killing off about half of them. It would be nice if I could just tell Conductor to do this for each script...

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 10.00%
vBulletin Optimisation provided by vB Optimise v2.6.4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.2.8 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominate (Lite) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 10:00 AM.

Copyright BetaSoft Inc.