Hey @Dennis,
Can you expand on what exactly is still happening here? There were various topics discussing this thread about this. One was about the multple requests to the WMS, another about slow loads on SingleTile mode and another about caching. Can you expand on the issue a bit more? I know were were talking in another thread about the bottleneck to your WMS provider due to no load balancing. Is that still related?
Thanks,
Kyle
hi Kyle,
There was really only one issue in this thread. That being the client, running with TileType=MultipleTile, will send anywhere from two to four WmsRasterLayer requests to the local server for each move to a new extent. Each of those requests are then sent on to our WMS Provider.
It would be nice if the design was such that one request was sent and when the client received the response divide it up into the two or four individual extents and then pass those to the rendering process.
SingleTile Mode sends only one request, but then the rendering takes much longer, which is too slow for our users.
I am still working with our WMS Provider on resolving the bottleneck. I have added code to set WebRequest.Timeout to 20 seconds, where the default was 10 seconds. It’s been running for 24hours without reaching 100% on IIS Worker Process. Our provider is going to change their system from a minimum of 8 replicas to 16. I don’t know what a “replica” is, but doubling it sounds good.
If WmsRasterLayer can be changed to send one request in MultipleTile Mode, that would make the whole process much more efficient.
Thanks,
Dennis
Hey @Dennis,
For WMS, it requires that you specify a bounding box of the area that you want in the GetMap request.
In SingleTile mode, this is accomplished by taking the map’s newly changed bounding box and sending that to the GetMap request. Unfortunately, this means that the image that we get back is highly dependent on the size of your map. So if the map was fullscreen 1080p, it would request a full 1080p image. Likewise, a 4k map size would need a 4k image. This isn’t entirely efficient because if the user perfectly pans to the West by 10%, we still get the entire map’s extent and send that off to the remote server. This also increases the workload of the server proportionate to the size of your map, which is often why it is slow for users. You could override this behavior and instead request the difference area between the old and new bounding box, which would just be a tall vertical strip. The problem comes when the user pans the map diagonally. Even if just by one pixel, the difference area between the old and new bounding box would result in a request bounding box that would be the exact same as the new bounding box. If there was a way to provide the WMS an area rather than the bounding box of the area, then it might be more efficient. Unfortunately, this is not the case. An additional problem comes in when the user becomes impatient waiting for a result and keeps panning the map around, causing even more map requests to fire each time for a large image.
In MultipleTile mode, some of the inefficiencies of SingleTile mode get resolved at the expense of an increased number of requests to the WMS server. The map gets sliced up into a grid of 256x256 tiles and when the user pans the map to where a tile hasn’t been requested yet, we request a small image from the remote server. Because of this, it would be fairly difficult for this mode to make just one request. That said, this method resolves the issue with a map at 4k size. Rather than requesting a full 4k image, it requests several smaller images of only the newly exposed smaller tiles with the total dimensions not getting anywhere close to the full 4k map size. This also resolves issues pertaining to the user panning in small increments since it takes panning a full 256 pixels before requesting new tiles from the server.
So with those two methods described, there might be a bit of a hybrid approach that you could take, but it would take some engineering to get working properly. On the client side, set the TileType to SingleTile and also tack on an additional query parameter of the map’s previous bounding box. On your proxy server, use the incoming bounding box and the additional previous bounding box to get the vertical difference and the horizontal difference between the two. Then your proxy would make two requests to the remote WMS, one for the vertical and one for the horizontal. Once you get both results, stitch the two together and send it back to the client. This would simulate the perfect panning I described in the SingleTile section but with removing the need to get the full bounding box. An issue you would be met with would be the client only displaying the newest image because I believe it flushes the canvas, but you should be able to preserve it or store the previous canvas result while waiting for a response back. The downside of the user panning in small increments still exists in this method, however. And not to mention, this would be a fairly custom implementation that might require maintaining down the line.
Unfortunately, a perfect solution doesn’t really exist in this situation. A lot of issues might be resolved if your provider had a WMTS server, which uses that MultipleTile solution and also makes it really easy to cache the tiles on their side so that they don’t have to constantly query their backend imagery data every request, which is what I imagine is holding up a lot of those requests. And maybe by increasing the number of concurrent replicas will help resolve the issue already, but that largely depends on the volume of requests coming in.
Thanks,
Kyle