Hey everyone! This week I’d like to take some time to talk about getting the most out of BatchPatch from a performance perspective. As you have probably already discovered, BatchPatch is geared toward doing a lot of things at once. One of the most important design elements for us was to figure out a way to allow the user to execute a lot of tasks in a very small amount of time. We didn’t want to bog down the user interface with a lot of extra windows requiring lots of clicks to get the software to do your bidding. We wanted to keep things simple, intuitive, and fast, while still being very powerful for getting the job done effectively.
We know that the large majority of BatchPatch users are highly skilled technical wizards (frequently referred to as sysadmins) who really know what they’re doing when it comes to computers and networking. We like to think of ourselves as more than just average power users, and we wanted BatchPatch’s interface to be driven as much as possible by function, giving the user as much control as possible, rather than dumbing-down the interface at the cost of functionality. We know as well as you do that there’s nothing more annoying than a clunky app that shields the user from the core functionality of the app so much that it begins to feel like you’re not driving the app, and instead the app is driving you.
There were a number of trade-offs that we made during the development process, always bent toward providing the user with maximum control, even if it meant that in some cases the user could dig him/herself into a performance bottleneck. For example, BatchPatch allows you to execute actions such as remotely installing Windows Updates, remotely installing software, or remotely executing scripts on an unlimited number of machine simultaneously. The awesome thing about this is that tasks can be accomplished extremely quickly since BatchPatch can be configured to allow a very large number of execution threads to run concurrently. The downside is that if you attempt to execute more simultaneous threads than the computer or network connection is able to gracefully handle, you could end up causing the computer to stutter a bit in its responsiveness while it completes all those tasks.
I know for myself that I don’t want to be limited by some over-protective factory setting that isn’t changeable. We we believe that our super-savvy users should have the final say over how the app runs rather than being limited to settings geared for less savvy users. One area where this holds true is with maximum thread count. BatchPatch is a multi-threaded app that takes advantage of the capability of modern processors to run numerous different execution threads simultaneously. In fact, if you happen to watch the ‘Threads’ column in the ‘Process’ tab of Windows Task Manager when you execute an action across a large number of hosts in BatchPatch, you’ll see that BatchPatch might quickly spin up many more threads than any other app running on your computer. Of course once the action completes those threads are released back to the OS.
In the Tools > Settings window, we provide an option called “Concurrent Thread Maximum.” The default value is set to 100, but you can choose any number you like, with 0 being an unlimited number of threads. The concurrent thread maximum value is used to control the number of worker threads that will execute concurrently. If you execute a set of actions simultaneously on more computers than the concurrent thread max value is set to- so for the sake of this example let’s imagine executing a remote Windows Update installation on 200 computers when the concurrent thread max is set to 100- you’ll notice that the first 100 rows begin execution immediately while the second 100 rows show a status of ‘Queued.’ As computers in the first 100 rows complete their actions, their threads are freed up for the queued rows to begin executing.
If you’re running BatchPatch on a computer that doesn’t have a lot of CPU power and/or RAM you might want to decrease the concurrent thread max. If your computer has a lot of horsepower, you might consider increasing the concurrent thread max or even removing the limit altogether by setting it to 0. It’s your choice.