The last part of ForEach‑Object that I want to demonstrate to
you is this parallel feature. This is not something that you
necessarily need to use all the time,
but I want you to understand how it works and why you might want to use it.
I'm going to create a variable that's going to hold the names of
four servers in my little test domain here.
Now this is the way you would traditionally have done this in PowerShell.
I'm going to save the results to a variable.
You would say I'm going to take my variable with all those server
names, and for each one I'm going to use Get‑WinEvent and get the
security log, because I have to do this one at a time and get me
the 2,500 most recent events.
So I'm going to run this.
This may take a little bit of time. So Get‑WinEvent can only process one
computer at a time. And that ran relatively quickly.
Let's see how quickly it ran. So I'm going to do get‑history ‑count 1,
and this is going to give me the last command that I just ran. In
PowerShell 7, this now has this little duration object. And I can
see there that this ran in just a little over 6 seconds. And this
should have got me, let's say measure the results, alright so I got
10,000 entries.
Now, let's try this in parallel.
Let's take my same servers, and let's do foreach‑object.
Now let's see that ‑parallel.
Same command, Get‑WinEvent, Security, ‑ComputerName,
‑MaxEvents, and have this run.
This should run faster.
It looks like it ran a little bit faster.
Let's check the history here.
Yep, so that took about 3 seconds.
That took 50% of the time.
Your results will vary, and depending on the command you're doing,
sometimes it runs faster.
Sometimes it may not because there could be other things that could be involved.
It's very possible that the time that I'm running this in parallel,
that maybe one of my servers is under high utilization
that's really slow to respond. So, don't assume the
‑parallel always means that it's faster,
but often it can be. Because what's happening in the first scenario,
Get‑WinEvent has to run for the first server,
wait for all those results to come back,
then it does the next one, then it does the next one.
Whereas in parallel, it does all five of those at once, all at the same time.
If there's more than five,
then it adds the next one to the list as each of them finished.
So it just kind of rolls through. And you can adjust that with
that ThrottleLimit parameter. And I should be able to see the
same number of results.
So, I got the same results,
except it took half the time. So imagine the performance gains
when you scale out in this example. If I had 50 servers, and
let's say I was retrieving 10,000 logs,
you know the ‑parallel is going to make a big difference. However,
if you're not going to need the results right away and it takes longer,
but you're not going to get to the results until after it's done anyway,
yeah maybe it doesn't matter.
So, the parallel is there. It's something that you can play with. This
is why I think PowerShell is a fantastic management tool once you
understand the basics. The fundamental techniques and concepts apply to
everything. Once you learn the basics, you can apply them everywhere.
Is the boss dropping Azure on you?
No problem.
Discover the Azure cmdlets and parameters and then use them the same
way you would like Get‑Servers and Get‑Process.
Now,
I still need to show you one more important skill when working with the PowerShell pipeline, and I'll cover that next. So, hurry back.