Re: [OSM-dev] Tiles cache and HTTPS
Hmm, if I anonymise x-forwarded-for, mod_tile will throttle the proxy, I'm afraid. Curious to know the config of the OSM CDN squid caches for https. Anybody for a short explanation? Yves Le 3 novembre 2019 23:38:23 GMT+01:00, Stefan Baebler a écrit : >In that case you would ideally find a way for the caching proxy server >to >reach the original tiles over plain http (make sure to strip any user's >personal data from the requests!) and save some CPU cycles on both >ends, >improving the latency slightly. > >You might also want to consider serving larger tiles. 256x256 is really >small for today's standards and most major map frameworks (well, at >least >leaflet, openlayers and mapbox) already support loading 512x512 tiles, >reducing the number of requests, improving the load times and server >disk >usage. Yes, those tiles will take some more time to render, but most >likely >less than four times more ;-) > >Some rendering/caching systems internally already use even larger tiles >to >combat these problems >https://wiki.openstreetmap.org/wiki/Meta_tiles > >Br, >Štefan > >V ned., 3. nov. 2019 09:24 je oseba Yves napisala: > >> Ah, I should've told that I own the opensnowmap render server. >> My concern is to keep the ~0.5 TB of tiles available on both a proxy >cache >> and the render server in case things goes bad on the later, even if >only >> old tiles. >> Also, as heavy tiles user are more and more common, I'd like to >propose >> them a quick solution that looks better than 'no warranty, I may have >to >> cut your access'. >> Yves ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Tiles cache and HTTPS
In that case you would ideally find a way for the caching proxy server to reach the original tiles over plain http (make sure to strip any user's personal data from the requests!) and save some CPU cycles on both ends, improving the latency slightly. You might also want to consider serving larger tiles. 256x256 is really small for today's standards and most major map frameworks (well, at least leaflet, openlayers and mapbox) already support loading 512x512 tiles, reducing the number of requests, improving the load times and server disk usage. Yes, those tiles will take some more time to render, but most likely less than four times more ;-) Some rendering/caching systems internally already use even larger tiles to combat these problems https://wiki.openstreetmap.org/wiki/Meta_tiles Br, Štefan V ned., 3. nov. 2019 09:24 je oseba Yves napisala: > Ah, I should've told that I own the opensnowmap render server. > My concern is to keep the ~0.5 TB of tiles available on both a proxy cache > and the render server in case things goes bad on the later, even if only > old tiles. > Also, as heavy tiles user are more and more common, I'd like to propose > them a quick solution that looks better than 'no warranty, I may have to > cut your access'. > Yves ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Tiles cache and HTTPS
Ah, I should've told that I own the opensnowmap render server. My concern is to keep the ~0.5 TB of tiles available on both a proxy cache and the render server in case things goes bad on the later, even if only old tiles. Also, as heavy tiles user are more and more common, I'd like to propose them a quick solution that looks better than 'no warranty, I may have to cut your access'. Yves ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Tiles cache and HTTPS
Https might not be strictly needed between tile renderxcxer and the cache, but if this is the only way that you can get to the tiles (eg from the pucxcxccxczxcxzcxxxblic opensnowmap tile server) you can technically still use that. If possible try to use http 2 or at least keep-alive connections. Also check their tile usage policy. Br, Štefan ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
