Swarm is what handles communication between the editor and Lightmass.
When I start the Build, a little Swarm icon appears in my Windows bar (called system tray, I keep mine at the bottom). I click on it (or double-click, I can’t recall) and it opens another window where you can edit things in there.
If you’re on Windows, you can find the swarm agent in your system tray, located by the clock on your taskbar by default. You’ll want to look for a small black “S” surrounded by yellow. Once you double click on it, it’ll bring up the window that ZenArtist mentioned.
Once that’s open, open the settings tab and change the setting for “EnableStandaloneMode” to true. You’ll probably want this unless you know that your network has been hooked up to distribute the light bakes across the network.
i found it ,hope it helps cause this sure is taking long and all i did was add a smal wood cabbin in my level 
I know this is old, and I don’t have a suggestion regarding the build times…
But… Regarding the crash. I recently encountered this and solved it.
For me, my issue was Virtual Memory. The problem is, is that windows will notify you about low VM, but if you don’t respond to the window (which only stays visible for a brief period), Windows will automatically kill the offending process; which is the building of your lightmass. Thus the crash.
So the solution is simply to increase the Paging file. For example, I had hard set my paging file to be 12GB min/max, and I have 24GB of RAM. This was insufficient for my building needs (even with using a swarm comprised of 4 computers).
All I needed to do to fix the crash was increase my paging limit. For my scenario, I needed 12GB more of a Paging Limit.
However, what I did to future proof this issue, was to add a small 128GB SSD I had lying around, added it to my build server, and completely moved my Page file to that drive (no page file on the system drive) with a size of 8GB-64GB.
The key to note if you do this, is that any “other” drives with paging files, need to be at minimum; equal performance as your system drive. Meaning, if your OS is on an SSD, don’t try to put your paging file on a normal “spinner” HDD. Failing to heed this drive “matching” will result in worse problems.
I haven’t had a single Lighting hang/crash since doing this.
Regarding swarms:
I copied the Engine/Binaries/Win64/DotNet folder from my build to the desired systems (destination location really isn’t relevant)
I then setup a shortcut to the SwarmAgent.exe process on all systems to automatically start the swarm agent on each system (place the shortcut in “c:\programdata\microsoft\windows\startmenu\programs\startup”
Then, launch each swarm agent and update the following properties
CacheFolder - Something appropriate for each system (really depends on where you copied the DotNet folder to)
AgentGroupName - Must be the same for all agents, what you call it is irrelevant
AllowedRemoteAgentGroup - Must be the same for all agents, what you call it is irrelevant
AllowedRemoteAgentNames - Must be the same for all agents, I simply used “*” (no quotes)
CoordinatorRemotingHost - Must be the same for all agents, enter the name of the system that runs your editor
On your building server, you must have the DotNet\SwarmCoordinator.exe process running prior to starting your lighting build. For me, I just have a shortcut for this executable in my statup folder (like with the swarm agent) on my build server. So that way, everytime my building computer starts, my Swarm Coordinator and Agent processes are automatically started for me without having to remember.
Hi guys, I’ve just worked on an asset to improve compile time: Compiler Booster in Code Plugins - UE Marketplace
Thank you!
