I’m trying to improve the loading speed of our 3D tiles map. It’s hosted in S3 and served via CloudFront with caching, compression and HTTP/2 & /3 enabled. It still loads heaps slow, even on a really fast internet connection. It doesn’t matter which browser I use, not even which computer or OS (tested on Chrome, Edge, Safari, Mac, Windows, …)
I noticed the 3dbm files load sequentially as I move through the map. This means if I move fast, Cesium builds a queue of HTTP requests that await fulfillment.
I’m trying to nail any possible network/infrastructure bottlenecks, but I was wondering if there are any settings I can check to see if things are all good on the browser side?
For example, is there any setting to turn on parallelisation in tile fetching?
Which options in the 3D tile layer might be relevant to overall speed of loading individual tiles?
You could try adjusting RequestScheduler.maximumRequestsPerServer. I have occasionally seen speedup by increasing this to 50 or so, although results will depend on the server and network.
In most cases, the default settings are already fairly fast. So if a particular tileset is very slow, it is more likely a result of how the tileset was constructed. How large (in KB) is your largest tile?
Hey @jjhembd, thanks for the reply, I’ll try to tweak the request limit, although I thought it has no bearing when HTTP/2 or /3 is in use.
I’m now scanning the S3 bucket to find the largest tile (assuming you mean the b3dm files), but I think I saw sizes ranging up to 10MB, but often it’s less than 1mb - is that too much? What’s the best practice?
I recorded what’s happening. It’s not a high-fps gif, but it should show what my issue is: the tiles are loading sequentially (I’m hoping they could load in parallel - why not?), and it takes a long time for the detail to catch up once I stop moving around the map.
Yes, you are correct that HTTP2/3 (unlike HTTP1) do not impose a limit on the number of simultaneous requests. However, leaving it completely unlimited often leads to processing bottlenecks on the browser side, which is why we set the RequestScheduler.maximumRequestsPerServer inside Cesium.
In my experience, the fastest tilesets have smaller tiles: in the 50-200 KB range. But I don’t think that’s enough to explain what you are seeing in that screen recording.
Is the data public? Are you able to share a Sandcastle link with a minimal reproduction of the problem? That would make it easier for us to diagnose further.