This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

2023.2 Transaction Player slower

2 days ago, I updated our Orion to HCO 2023.2 (plus the WPM license of course).  I have 2 remote player locations.  Each player has 35 transactions.  The average duration of the transactions on BOTH players went from sub 1 sec, to 2.5 seconds.  The player load has also increased due to the transactions taking longer.  There have been no changes to the recordings.  I do have a ticket open but so far they have just asked for the diagnostics.   Any one else seeing something similar or know the issue?

That jump, right above the A in 8:00 AM is when the player was updated.  The other player location looks similar.

Parents Reply Children
  • I don't suppose you found an answer?  

    Support had me add a line to one of the .config files, which helped a bit on one poller, but no impact on the other poller.

  • sadly no. wpm been very inaccurate as now we have player randomly stop playing transactions and having unknowns and remote player lose connection to main poller.  we had 40-45 transaction on each with no issues and since upgrade nothing but noise. all we get is add more players and users. lol player load looks okay but like i said get alot of unknowns and player disconnects. 

  • If you are game to try, edit your Solarwinds.WEUM.Agent.Worker.exe.config file and add

    probeExtraArgs="--extraSwitches " --disable-backgrounding-occluded-windows ""

    to the agentWorkerConfiguration section


    It helped on one of my pollers.  Didn't completely resolve it, but helped. 

  • Do you have a ticket open ? We are tracking this issue internally so it would be helpful to have your environment added to the research.

  • I replied to you in the other thread as well but just in case you didn't see it over there (much longer thread) I did not see reference to the extra arg being applied and not fully working in your ticket

  • It's definitely in the case notes.  It did help with one of the players.  "Help" is the operative word.  It helped with flapping alerts.   However, even on that one player, the average transaction time is still significantly increased, just like the above graph.  That increase in transaction time also then gets reflected in the player load.

    On the 2nd player, we currently have 50% of our transactions showing critical/warning times most of the time.  Prior to the upgrade, critical actually meant critical and we investigated.  Now unfortunately it is so frequent we are ignoring the alerts.  This player also shows the increased player load.

    Note that the transactions on both players are very similar and are evenly distributed.

    Thanks for looking!

  • Yeah, I see it now. OK, I am going to push for some escalation on this. It is concerning that the workaround did not fully resolve it for you. Other customers are having good results with the workaround so we need to dig a bit deeper to see what is different in your case. Thanks for your patience!

  • Thanks.  I appreciate it.   Just so you know I'm not making this up, this is the 2nd player:

    When using the recorder to play a transaction, the total time looks similar to the left part of the first chart.  Both players are Windows 2019, same CPU/memory, same subnet.

    Here's the part of the .config file on the above player:

      <agentWorkerConfiguration recordingTimeout="330"
        probeExtraArgs="--extraSwitches &quot; --disable-backgrounding-occluded-windows &quot;" />