9 responses

  1. Jay Dunk
    September 9, 2013

    Hi Jonathan,

    I’m about to try this to see if possible, however thought i would see if you have any ideas. i am currently stress testing a bespoke application using Dreplay. I have captured a trace file from an end to end system that had 5 users running random UI activity. However when i fire this off from 5 VM’s each one of those 5 users activities are going to fire at the same time across 5 dreplay clients ( same queries execute synchonously across 5 VM’s) Is it in anyway possible to fire up 5 cmd line windows each to control one of the vm’s replay activities and offset the start time with teh config file by 5 seconds on each one? this will mean there is some offset between each dreplay client to avoid inducing locking on certain resources caused by executing the same session queries 5 times in parralel

    • Jonathan Kehayias
      September 16, 2013

      Hey Jay,

      If you do a synchronized replay, then it will fire off exactly like it did for the capture so you wouldn’t need to offset each of the machines during the replay, you would just need to offset them during your initial workload generation period.

  2. Iyon Lion
    October 4, 2013

    2013-10-04 11:36:03:185 Error DReplay The client ‘xxx_yyy’ is not a registered distributed replay
    client. Make sure that the SQL Server Distributed Replay Client services is running on ‘xxx_yyy’,
    and that the client is registered with the controller ‘localhost’.

    Hi Jonathan I followed your steps but got the error message above. I went into component services and added permissions for DReplay for launch and activate, access and configuration permissions. I was able to preproces my trace file and and can see from the. The log file here C:\Program Files (x86)\Microsoft SQL Server\110\Tools\DReplayClient\Log that the client is registered with the controller. Can you think of anything I can try?

  3. Iyon Lion
    October 4, 2013

    never mind it looks like DReply does not like the FQDN. That is why I got that error.

  4. Srdjan
    November 18, 2013

    Can you leverage the TSQL or a custom Profiler template instead of the TSQL_Replay for Distributed Replay?

    Thank you.

    • Jonathan Kehayias
      December 9, 2013

      You can, but if the events are not included like they are in the TSQL_Replay profiler template, you won’t be able to perform a replay operation. Why do you need to customize the TSQL_Replay template that ships with Profiler, except for filtering on a specific database or user, which you can do in either an scripted copy of the template or when setting up the trace to begin with?

      • Srdjan
        December 25, 2013

        Thank you Jonathan. Our existing server traces are not based on the TSQL_Replay profile. Instead of matching them, we developed a custom Replay application.

  5. Jason Ingram
    May 1, 2014

    Hey Johnathon,
    Great article as always!!! Excellent detail and easy to follow. My one question is I’d like to simulate what the response times would look if I doubled or tripled the workload on the server. Is that possible through Distributed Replay? Is that what the Connect Time Scale and Think Time Scale are for? Or should I be upping the threads per workstation? I’ve tried a couple things with no luck. However my problem could also be that I only have 3 workstation clients. If you could point me in the right direction, I’d really appreciate it.

    • Jonathan Kehayias
      May 29, 2014

      Hey Jason,

      You can drive higher volumes of load with stress mode and scaling the connect and think time, but it’s not necessarily going to be linear or predictable like you might hope. You may just have to play with the values to see where you get the double/triple TPS from the captured workload.

Leave a Reply




Back to top
mobile desktop