BatchPatch Forums Home › Forums › BatchPatch Support Forum › BatchPatch extremely laggy after latest version
- This topic has 16 replies, 6 voices, and was last updated 5 years, 7 months ago by paulzbp.
-
AuthorPosts
-
April 4, 2019 at 3:37 am #8694JustinMParticipant
Hey guys,
Since updating to the latest EXE for BatchPatch, running actions on groups of computers causes BatchPatch to stop responding for 10 – 20 seconds.
Even running simple commands like getting the Windows OS for 10 PC’s in a grid, can freeze BatchPatch.
It wasn’t doing this in the previous version.
Any idea what’s changed to make performance drop suddenly?
Regards,
Justin
April 4, 2019 at 3:58 am #9850dougModeratorJustin – I don’t think there is anything in the new version that could cause the behavior to be different than the previous version. Have you tried both versions side by side to compare? The code didn’t change for the actions you’re talking about.
-Doug
April 10, 2019 at 8:37 pm #9851paulzbpParticipantHi Doug,
My experience is similar to JustinM. I’ll share (below) the side by side comparisons I did in the lab. It might help to know that all servers in the tests are VMs with no antivirus installed on the 2008 and 2012 servers. The 2016 servers have Windows Defender installed. I am using BatchPatch with:
‘cached mode’ enabled
‘offline mode’ enabled
Do not download newest wsusscn2.cab if any version already exist enabled
Windows 2008 R2 (1 machine tested)
2018.10.4.14.1 (Average 8 sec) vs 2019.3.20.16.58 (Average 40 sec)
Windows 2012 R2 (4 machine(s) tested)
2018.10.4.14.1 (Average 5 sec) vs 2019.3.20.16.58 (Average 42 sec)
Windows 2016 (3 machine(s) tested)
2018.10.4.14.1 (Average 4 sec) vs 2019.3.20.16.58 (Average 30 sec)
Hope this helps.
-Paul
April 10, 2019 at 8:57 pm #9839dougModeratorPaul – I actually don’t really know what you’re describing or what you’re comparing. I don’t think it’s the same thing that Justin is talking about. If we just use your 2008 example for a moment, what are you saying took an average of 8 seconds on 2018.10.4.14.1 as compared to an average of 40 seconds on 2019.3.20.16.58?
April 10, 2019 at 9:17 pm #9840paulzbpParticipantHi Doug,
Sorry for the confusion. My numbers are “load” times of the BatchPatch.exe. So for the 4 Windows 2012 R2 machines I tested, the latest version of BatchPatch (2019.3.20.16.58) took on average 37 seconds longer to load than BatchPatch version 2018.10.4.14.1. I have been able to produce the same results consistently.
I have not noticed a lag time when executing command on groups of computer.
-Paul
April 10, 2019 at 9:25 pm #9841dougModerator“load” times? I’m still confused. Are you describing the amount of time that it takes to launch BatchPatch? So like from the time that you double-click the batchpatch.exe until the time that the BatchPatch window appears?
April 10, 2019 at 9:30 pm #9842paulzbpParticipantYes, my “load” time numbers are how long it takes from the time I launch the BatchPatch.exe and the BatchPatch Window appears. For what it’s worth, I have actually been right clicking and running as Administrator. -Paul
April 10, 2019 at 9:41 pm #9843dougModeratorI don’t have an explanation for why you would see significantly different load times between the two versions, but I would suggest that you simply try running BP on a physical machine or a VM with more horsepower. For comparison, on my physical workstation, which is approx 8 years old, the current version takes only 2 seconds to load. The older version also takes 2 seconds to load.
April 10, 2019 at 9:44 pm #9844paulzbpParticipantDoug, if I stumble across some useful information, I’ll be sure to share.
Best wishes, -Paul
April 11, 2019 at 1:54 am #9845JustinMParticipantSorry for the delay getting back to you Doug.
FYI – I’m not having the same issue as Paul.
My issue is when I use any of the functions in BatchPatch on large groups of hosts, the BatchPatch process essentially becomes un-responsive for a good 10 – 20 seconds (Depending on how many PC’s)
It’s easiest to reproduce:
– Select around 30 (online) hosts
– Click “Get Logged on Users” and “Get OS version/service pack level” one right after the other
– While both commands are running, I can’t select anything in BatchPatch, or switch to another tab (Takes about 10 – 20 seconds before control is restored)
This didn’t happen to me on previous versions of BatchPatch.
So, I was pretty happily using BatchPatch daily, and then immediately after I put the new EXE over the top of the old one and launched it, I noticed the issue.
With the older versions, I was running these 2 commands on even larger groups of hosts and BatchPatch would never stop responding.
That’s just the easiest way to reproduce the issue, but it does the same when I try to deploy something to large groups of PC’s, or run a remote command on a group of PC’s.
Here’s a recording of an example:
https://drive.google.com/open?id=18emuCgWN6sk2mJzJw5ew_Rxd0NMB3CJ4
You can see at 7 seconds when batchpatch flashes, that’s when I’ve clicked on a remote command (with logged output) to just get the Powershell version from a group of PC’s.
I then click on tabs at the top, and hosts in the grid, and nothing happens.
At 16 seconds, it starts switching to the tabs I clicked on while it was frozen, and then I get control back.
April 25, 2019 at 5:02 pm #9796dougModeratorI’m not sure what it could be since the code didn’t change in those commands between the last and current version. I noticed in your video that there is no tab header status icon, which makes me wonder are you definitely using the current version of the app? Or did you just disable it under ‘Tools > Settings > Grid prefs > Show tab header activity / alert images’.
I know you said the issue didn’t exist until you started using the new version, but I’m wondering have you since gone back and tried the previous version to see if it still does not occur in the previous version even though it occurs in the current/new version? Also are you running BP on the same computer as you always were or did you change computers or start running BP in a VM or something like that in between the last time you used the older version and the time that you started using the newer version?
May 6, 2019 at 9:25 am #9802boosterParticipantI’m in the same case as paulzbp. The load time of the BP application increased significantly with the latest release. I’m on W2016 dedicated server, estimation = 30 sec to open the application. during the 1st 5sec I see the Windows loading circle near the mouse cursor, then nothing for the rest of the time.
EDIT: My BP servers are only granted to a subset of sites. Removing this limit fixed the load time issue. Any IP/behaviour change that may explain it?
May 6, 2019 at 5:06 pm #9804dougModeratorbooster – have you tested the old version side by side with the new one? I’m wondering if the issue might be due to a change in server 2016 that happened in between last time you used BP on it to now when you used the new version of BP. We didn’t change anything in BP that would/should affect the load time of the app. The best guess I have is that it is something with the Windows SmartScreen. The new version of BP has a new certificate because the old one expired. I wonder if possibly the Windows SmartScreen check of the new certificate is what is causing the delay.
-Doug
May 7, 2019 at 2:19 pm #9809boosterParticipantHi doug,
Not side by side but well on the same server untouched between the BP update. There is definitely a link with an external check, whatever it is, as with full Internet access the issue is gone. The same version was slow with restricted Internet connectivity, opening slowness gone without the limitation. In the meanwhile it seems other issues were discovered with the firewall so I may not be the best example.
May 8, 2019 at 1:32 am #9813dougModeratorThanks. We’ll see what we can figure out.
-Doug
May 16, 2019 at 1:15 pm #9818djwwParticipantI just installed this yesterday and started using it and I will say when i click on a job queue and tell it to push to say 30 servers it takes about 45 seconds before i can click anything on the screen. then it catches up and all of the jobs start working. This is on a 16core VM with 64gb of ram on a SSD fast disk shelf netapp running server 2016 aka my WSUS server. Hardware is not the issue here. But I definitely see a “not responding” type action after initiating a job from the job queue.
May 22, 2019 at 1:46 pm #9791vaevictusParticipant@djww … try it with the ip addresses instead of the hostnames, on a whim… this smells a bit like a DNS resolution oddity.
-
AuthorPosts
- You must be logged in to reply to this topic.