[OSM-talk] a, b and c.tile.openstreetmap.org refer to the same server?

[Florian Lohoff]

On Tue, May 19, 2015 at 01:03:32AM +0200, Stefan Baebler wrote:
> 18. maj 2015 10.30 pop. je oseba "Andrew Guertin" <andrew.guertin at uvm.edu>
> napisala:
> > Whether the new limits are sufficiently high for OSM I haven't
> investigated enough to answer.
> 
> Browser limits, network speeds and screen resolutions all increased in the
> recent years, but tile size stayed at 256*256.
> 
> To put this in perspective, currently trending 1920*1080 needs 40-54 tiles
> for a full screen map, whereas 1024*768 (most popular in 2009) only needed
> 12-20.
> Source: http:// <http://www.screenresolution.org/>www.screenresolution.org/
> <http://www.screenresolution.org/> + quick calculation.
> 
> Average tile complexity also increased somewhat, increasing their average
> size in kB.
> 
> Using a,b,c hostname aliases only increases initial DNS resolution time.

No - The initial limit for browser was 4 connections with HTTP
pipelineing. When introducing the a/b/c hostnames you triple your number
of connections to 12 - So you can have 12 simultanous open connections.

This is a crude hack needed to work around a limit introduced i think in
Netscape 1.

In the End it always stays a hack. You basically open a "massive" amount
of connections (Which harms NAT by flooding the connection table) and
download tiles in parallel e.g. interleaving your data. This brings
you advantages when on a good connection. I have a 384Kbit/s connection
at home. I'd rather like to have fewer connections and a nicer
algorithm which tiles to load first e.g. center to edge in circles. Most
of the time i would not need to wait for all tiles to arrive before
beeing able to make use of the visual of the map. Now i am waiting
sometimes minutes until a previous uncached area of the map
gets loaded.

HTTP/2 will solve some of those problems e.g. the tcp handshake
necessary to open the 12 connections as all connections can be
interleaved into the same HTTP/2 tcp connection. 

This whole issue is a broken mess which gets worse with every iteration.
The client should be the one to decide how many connections or in HTTP/2
speak parallel transfers not the application/implementation. Decisions
should be made based on latency e.g. when a tile loads in 3ms but your
request round trip is 100ms you might want to request 30 tiles at once.
For me downloading a tile takes something between 200 and 1000ms whereas
my round trip time on an empty link is ~50ms. When you now use the same
scheme and request 30 tiles at once it'll take 30 seconds for the first
tile to be displayed. When you request only 2-3 tiles i'll have the
first parts of the map be displayed after 2-3 seconds, beeing able to
watch the map build up. 

There is no "one size fits all" and OSM could use some love in terms
of bandwidth preservation, caching, well thought algorithms.

For example: Use Firebug to investigate the amount of data transferred
for a simple login e.g. OAuth on the main osm.org website. For me this
takes 20-30 seconds for getting an OAuth login. My guess is excessive
javascript librarys not beeing cachable or only for the session.

> This hack IMO still serves as a relatively cheap performance boost... until
> HTTP 2 is widely used.

Its not performance. It only gives you performance when on a good
connection. It makes it worse when on a slow connection.

You are trading link saturation vs. latency.

Flo
-- 
Florian Lohoff                                                 f at zz.de
     We need to self-defense - GnuPG/PGP enable your email today!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20150519/296e34dc/attachment.sig>