a, b and c.tile.openstreetmap.org refer to the same server?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

a, b and c.tile.openstreetmap.org refer to the same server?

Maarten Deen
Is it normal that the a, b and c.tile.openstreetmap.org IP-adresses
refer to the same server? For me, they all refer to
amsterdam.tile.openstreetmap.org and for some reason it is not
responding very well (lots of read times out messages in JOSM).
To me it would seem more logical to have different tileserveraliases
refer to different physical servers.

Regards,
Maarten


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: a, b and c.tile.openstreetmap.org refer to the same server?

Jochen123
On So, Mai 17, 2015 at 04:46:24 +0200, Maarten Deen wrote:
> Is it normal that the a, b and c.tile.openstreetmap.org IP-adresses refer to
> the same server? For me, they all refer to amsterdam.tile.openstreetmap.org
> and for some reason it is not responding very well (lots of read times out
> messages in JOSM).
> To me it would seem more logical to have different tileserveraliases refer
> to different physical servers.

Thats normal. The a/b/c stuff is a workaround for a "feature" in browsers that
only allow a limited number of connections to the same host at the same time.
(Modern browsers probably don't have this limitation any more, sombody should
probably check whether we need the a/b/c stuff any more.) It is not ment to
be some kind of load-balancing.

And in this case it wouldn't really help to make those aliases to different
servers. If one of them is slow your map will still be patchy.

Jochen
--
Jochen Topf  [hidden email]  http://www.jochentopf.com/  +49-351-31778688

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: a, b and c.tile.openstreetmap.org refer to the same server?

Richard Z.
On Sun, May 17, 2015 at 05:09:59PM +0200, Jochen Topf wrote:

> On So, Mai 17, 2015 at 04:46:24 +0200, Maarten Deen wrote:
> > Is it normal that the a, b and c.tile.openstreetmap.org IP-adresses refer to
> > the same server? For me, they all refer to amsterdam.tile.openstreetmap.org
> > and for some reason it is not responding very well (lots of read times out
> > messages in JOSM).
> > To me it would seem more logical to have different tileserveraliases refer
> > to different physical servers.
>
> Thats normal. The a/b/c stuff is a workaround for a "feature" in browsers that
> only allow a limited number of connections to the same host at the same time.
> (Modern browsers probably don't have this limitation any more, sombody should
> probably check whether we need the a/b/c stuff any more.) It is not ment to
> be some kind of load-balancing.

probably doing more harm than good by preventing caching.

In Firefox the number of connections is settable and imho high enough:
http://kb.mozillazine.org/Network.http.max-connections-per-server

Richard

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: a, b and c.tile.openstreetmap.org refer to the same server?

Svavar Kjarrval
In reply to this post by Jochen123
The problem the "feature" was supposed to solve is more or less solved
in HTTP/2. However, the specification was only formally published this
month so the a/b/c subdomains will probably need to be active for some
time longer due to older software (eg. browsers) which will probably not
utilise HTTP/2 for some time or not at all.

- Svavar Kjarrval

On 17/05/15 15:09, Jochen Topf wrote:

> On So, Mai 17, 2015 at 04:46:24 +0200, Maarten Deen wrote:
>> Is it normal that the a, b and c.tile.openstreetmap.org IP-adresses refer to
>> the same server? For me, they all refer to amsterdam.tile.openstreetmap.org
>> and for some reason it is not responding very well (lots of read times out
>> messages in JOSM).
>> To me it would seem more logical to have different tileserveraliases refer
>> to different physical servers.
> Thats normal. The a/b/c stuff is a workaround for a "feature" in browsers that
> only allow a limited number of connections to the same host at the same time.
> (Modern browsers probably don't have this limitation any more, sombody should
> probably check whether we need the a/b/c stuff any more.) It is not ment to
> be some kind of load-balancing.
>
> And in this case it wouldn't really help to make those aliases to different
> servers. If one of them is slow your map will still be patchy.
>
> Jochen


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: a, b and c.tile.openstreetmap.org refer to the same server?

Grant Slater
In reply to this post by Richard Z.
On 17 May 2015 at 16:30, Richard Z. <[hidden email]> wrote:

> On Sun, May 17, 2015 at 05:09:59PM +0200, Jochen Topf wrote:
>> On So, Mai 17, 2015 at 04:46:24 +0200, Maarten Deen wrote:
>> > Is it normal that the a, b and c.tile.openstreetmap.org IP-adresses refer to
>> > the same server? For me, they all refer to amsterdam.tile.openstreetmap.org
>> > and for some reason it is not responding very well (lots of read times out
>> > messages in JOSM).
>> > To me it would seem more logical to have different tileserveraliases refer
>> > to different physical servers.
>>
>> Thats normal. The a/b/c stuff is a workaround for a "feature" in browsers that
>> only allow a limited number of connections to the same host at the same time.
>> (Modern browsers probably don't have this limitation any more, sombody should
>> probably check whether we need the a/b/c stuff any more.) It is not ment to
>> be some kind of load-balancing.
>
> probably doing more harm than good by preventing caching.
>

Nope. The tiles server alias (a,b,c) are selected using a hashing
algorithm which always selects the same alias for the same tile:
https://github.com/Leaflet/Leaflet/blob/master/src/layer/tile/TileLayer.js#L134
(also applies to OpenLayers).

Overdue me explaining how the OpenStreetMap Tile CDN works:

We have 16 distributed edge cache servers all over the world [1],[2],[3].
These cache servers are monitored in near realtime by pingdom for outages.
We use GeoDNS [4] for [a|b|c].tile.openstreetmap.org which points a
client to the closest or preferred cache server for the client's
region. [5]
We rebuild [6] the GeoDNS when pingdom notices an outage, visitors are
moved across shortly once their DNS TTL has expired (~5mins)
The cache servers use 2 backend rendering servers (orm + yevaud), with
one being the preferred server [7] (cache hot path). We monitor the
backends similarly with pingdom and GeoDNS updates.

The cache servers have a fairness algorithm (token bucket) which
ensures that no single client / network can degrade the service for
others.

The 2x backend rendering servers are near perpetually overloaded,
particularly during style updates. The short-term solution would be to
add in an additional rendering server, but longer term it would be
better to move to a model where tiles (png) are rendered on the edge
cache servers with the backend servers producing vector tiles which
are pulled by the edge cache servers. There are a few people working
on this, but no complete working open source solution ready to go.
Some of us on the OSM operations team + a team from Wikimedia are
watching developments closely. ;-)

1: http://wiki.openstreetmap.org/wiki/Servers#Other
2: http://dns.openstreetmap.org/tile.openstreetmap.org.html
3: http://wiki.openstreetmap.org/wiki/Servers/Tile_CDN
4: https://github.com/openstreetmap/chef/tree/master/cookbooks/geodns
5: https://git.openstreetmap.org/dns.git/blob/HEAD:/src/tile.openstreetmap
6: https://git.openstreetmap.org/dns.git/blob/HEAD:/bin/mkgeo
7: https://git.openstreetmap.org/dns.git/blob/HEAD:/src/render.openstreetmap

Kind regards,
Grant
Part of the OSM operations team.

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: a, b and c.tile.openstreetmap.org refer to the same server?

Andrew Guertin
In reply to this post by Jochen123
On 05/17/2015 11:09 AM, Jochen Topf wrote:
> (Modern browsers probably don't have this limitation any more, sombody should
> probably check whether we need the a/b/c stuff any more.)

I gave this a quick check, Firefox's was last changed in 2008:
http://hg.mozilla.org/mozilla-central/rev/d57879bc8021
https://bugzilla.mozilla.org/show_bug.cgi?id=423377

A quick read through of the bug showed that other browsers were
increasing their limits at around the same time. That means that the
changes should have propagated to nearly all users by now.

Whether the new limits are sufficiently high for OSM I haven't
investigated enough to answer.

--Andrew

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: a, b and c.tile.openstreetmap.org refer to the same server?

Stefan Baebler


18. maj 2015 10.30 pop. je oseba "Andrew Guertin" <[hidden email]> 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://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.

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

best regards,
Stefan


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: a, b and c.tile.openstreetmap.org refer to the same server?

Florian Lohoff-2
On Tue, May 19, 2015 at 01:03:32AM +0200, Stefan Baebler wrote:

> 18. maj 2015 10.30 pop. je oseba "Andrew Guertin" <[hidden email]>
> 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                                                 [hidden email]
     We need to self-defense - GnuPG/PGP enable your email today!

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

signature.asc (845 bytes) Download Attachment