Large WebGL AssetBundles and Chrome

So a bit of backstory first. I work for a CPQ (Configure, Price, Quote) company that creates a web based configurator for our clients. We have a whole back-end system in place where our clients or us internally can upload asset bundles to our web servers and when the session starts we retrieve the asset bundles in unity before the configuration starts.

Recently we had a client's asset bundle get large enough to make me do some research because of the odd behavior. This clients asset bundle was 106MB and when using chrome, the unity instance would crash with an 'out of memory' error in chrome. We were able to lower the size of the bundle to ~45MB with some compression and optimization and that solved the crashing error. Anyways that made me curious so I spent a half a day doing some testing to see what the threshold is.

Below are my results. I tested with Unity 2019.2.0f1, but I have had the same results with another client that uses Unity 2017.1.


The ~80MB bundle with chrome was a weird case, it loaded just fine but the breakpoint for the 'out of memory' error triggered. So that was sort of a fringe case.

If you were to split 1 ~100MB bundle into 2 ~50MB bundles, chrome will work just fine.

Anyways this is an odd behavior for chrome and I haven't heard of this before. I wanted to get it out there in case somebody knows a solution. Also to determine if this is a Unity issue or a Chrome issue.

Thanks!
Nick D.

 

What type of assets were in those asset bundles?

 

In Unity 2019, try increasing the memory size using:

Code (CSharp):

1. PlayerSettings.WebGL.memorySize = 128;

...by calling it once and saving the project or using a build script (confirm it saved by looking the value in your diff). You may need to try other sizes.

There may be something up with the latest versions of Chrome and memory expansion.

Also, make sure you save the asset bundles in brotli and you're serving them on https with content-encoding: brotli. This is easy to do with object metadata from the command line when using something like S3, and CloudFront will respect that header if you configure it to.

 

The one I tested out was just filled with images to bloat the size of the bundle. I have experienced similar issues with bundles with just .fbx's and also a mix of both models and textures (and materials).

I went ahead and tried bumping the memory size up and that was a no go (we have our own build script so it was easy to implement). Then I went ahead and got brotli compression enabled on our IIS and got it to work with unity and that didn't change it either.

This is leaving me to believe that chrome is the suspect in this case as other browsers still work fine. But I have been wanting to get brotli going on our sites for quite some time so this was nice to get off my plate.

Thanks for your help and suggestions!
Nick D.

 

I wonder in which part of the process it happens. Downloading the file, extracting, or trying to use an asset from it

 

I believe it happens when its decompressing the bundles. There always seems to be a 'hitch' when the bundle is finished downloading before the next bundle download begins. I don't do anything special other than add the AssetBundle to a list for later use when I need to extract out models.

 

Also try to build not from the command line or a build script.

Do you by chance use TextMesh Pro?

 

I tried to build with using Unity's default build menu to no avail. Also I don't use TextMesh Pro at all so I shouldn't have to worry about that (checked package manager to see if it was installed, but it wasn't)

 

You'll have to break up your asset bundle into smaller pieces then.