On 01/04/2013 10:13 AM, Alex Barth wrote:
Pawel -
This is great.
What would it take to make this blazing fast?
There is still a lot challenges ahead with performance such as:
* On high zoom levels OWL API response time is acceptable most of the
time but I only tested it with 1.5M changesets. Will it scale to 10
times that? I think it will (on high zoom levels) without major changes
but if it doesn't then database schema needs to be adjusted (SP-GiST
indexing maybe).
* On low zoom levels there is a known issue with performance because a
lot of changesets match and they need to then be sorted by timestamp to
select the latest ones and the sorting right now does not use the index.
I spoke with a Postgres guru on IRC and he gave me some hints which I
still need to try out.
* Client-side performance is still a challenge - I managed to kill
Firefox a couple of times with the amount of changes that the code tried
to show. There should probably be a limit of geometry features to be
shown (plus it should be based on the browser you use) and some kind of
warning and/or filtering of changes just like the "Browse map data"
feature does it currently.
* Another performance challenge is with processing history data and
creating tiles. It used to take a long time but I optimized the hell out
of the tiler code and now it can process about 500k changesets per 24
hours so in a month we would have the whole history (in theory, don't
try this at home...). That's on the zark server with two cores. More
core = more tiling jobs that can run efficiently so it should not be
that bad after all (unless the database blows up).
So to answer your question - mostly more testing and development is
needed, for that I need time.
Echoing Christian: where should we file bugs/suggestions?
I enabled Issues on my fork of openstreetmap-website repo:
https://github.com/ppawel/openstreetmap-website/issues
Paweł
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
