7

When I execute a simple statement locally

$path = 'C:\Windows\System32\WindowsPowerShell\v1.0'
gci $path

I see the response immediately. But when I execute it as job on my local machine

$start = get-date
$path = 'C:\Windows\System32\WindowsPowerShell\v1.0'
$cmd = [scriptblock]::Create("gci $path")
$jnr1 = Invoke-Command -computer localhost -ScriptBlock $cmd  -asJob
Wait-Job $jnr1
Receive-job $jnr1
$end = Get-date
($end - $start).totalseconds

I have to wait 55 seconds. From my unix experience a decade ago. I would expect background jobs to run nearly as fast as foreground jobs.

Are there ways to speed up the execution of PowerShell background jobs?

bernd_k
  • 11,558
  • 7
  • 45
  • 64
  • Starting up a powershell window takes long time in my machine. But after its loaded it runs command quite fast. May be the cron is loading powershell first, hence the delay. – Shiplu Mokaddim May 13 '12 at 17:31
  • PowerShell_ISE starts in about 10 sec and Powershell in less than 3 sec for me. There must be something else. – bernd_k May 13 '12 at 17:55
  • I've tested your script on XP sp3 and Windows 7 pro and Windows server 2008 R2 always w/ powershell 2.0 and time elapsed is (in order): ~6 sec, ~5 sec, ~4 sec. – CB. May 14 '12 at 06:53

3 Answers3

4

This shorter command does the same thing: 

Measure-Command {Start-Job -Command {gci C:\Windows\System32\WindowsPowerShell\v1.0} | Wait-Job | Receive-Job}

On Win8 beta w/ PSv3 it was fast for me ~3 seconds, on WinXp w/ PSv2 it was ~15-30 seconds.

Background jobs were introduced w/ PsV2. They've had time to optimize since v2 and PowerShell now uses the DLR in v3 now so that might explain the differences in performance.

It has to spin up another powershell process with the command text, run the command, send back the serialized results and tear down the process.

To find out what its doing I ran procmon while the above command was running and a majority of the time powershell.exe was reading networking and COM related reg keys.

Andy Arismendi
  • 50,577
  • 16
  • 107
  • 124
0

I'm having a problem with slow jobs too where it runs fast in the foreground, but your problem is so pronounced for a single command that I'd suspect it's something related to the cost or some machine specific difficulty of spawning a new powershell process. (Yes, you get an extra powershell.exe for every concurrent job.) For a lot of people though, it's more than that. This post: (https://vwiki.co.uk/Background_Jobs_(PowerShell)) mentions that jobs are run in PS as below normal priority by default. Some posts suggested putting one of the following in the job code block to fix mostly CPU problems:

[System.Threading.Thread]::CurrentThread.Priority = 'AboveNormal'
([System.Diagnostics.Process]::GetCurrentProcess()).PriorityClass = 'AboveNormal'

Unfortunately for me, I think I'm having an I/O performance problem as upposed to a CPU performance problem with jobs. This post: (How to set Low I/O ("background") priority in Powershell) touches on the concept of increasing memory and IO priority, but I didn't see an answer that I feel comfortable implementing.

One of the most important features of Powershell jobs is parallel execution of multiple jobs. An alternative to PS Jobs are PS "Workflows", but it seems I still have the same performance problems with workflows as with jobs. Very frustrating.

Community
  • 1
  • 1
scradam
  • 1,053
  • 11
  • 11
0

Your demo works quite fast on a windows server I tested. I believe in this particular case it might not be problem with jobs, but rather with calling the localhost! Try changing it to 127.0.0.1 instead. I had a problem with performance of PHP app because it somehow took too long to resolve localhost. Changing it to ip address fixed it. Give it a try.

related discussion https://forums.iis.net/t/1153459.aspx?PHP+very+slow+on+IIS7

McVitas
  • 272
  • 1
  • 17