search

andrewxhill / MOL

The Map of Life
mol.colorado.edu/
19 stars 4 forks source link

Tiling performance #71

Closed eightysteele closed 13 years ago

eightysteele commented 13 years ago

From Walter via email:

"Playing with other species, e.g. Canis lupus, is also noted that map drawing can be extremely slow. My connection here is fast and worked otherwise fine, so I was surprised, when this species took ca. 60 seconds to finish drawing all map types. Could you have a play and see whether you get similar slowness for some species? Is this something where by expending some more money (i.e. renting additional resources on the cloud etc.) we could (at least temporarily) speed things up? This scaling / speeding up part is of course a larger question that's been on our mind. Anyway, just asking for brief thoughts here."

eightysteele commented 13 years ago

Yeah, so there were some serious initial performance issues going from the Colorado server to Linode. Andrew made some immediate changes to address it which helped a lot:

1) Tile coloring on Linode instead of App Engine. Saves a few hundred milliseconds per request. Reduces drag on Linode.

2) Moved Mapnik implementations to pure python (instead of mapfile.xml which required I/O). Right now all Ranges/Ecoregions/PA are working. ER-Group and PA-Group still rely on the mapfile.xml to tell them what layers they include. should be fixed when DB storage is implemented. Until then, group types are going to be super super slow on Linode.

3) Added a Taskqueue. Whenever a tile is returned to the client, a task is created for the 4 tiles it covers at the next zoom. The execution of those 4 tasks is staggered over the next 6 seconds so not to bog the backend, and they all expire after 15 sec if they can't be run. This makes zooming to the next level much snappier.

eightysteele commented 13 years ago

So I don't think we have time to implement a DB solution in the next 4 days, but what we can do is jack up the Linode instance which is currently a Linode 512 (512MB RAM, $20 monthly).

To roughly match performance of the Colorado server we could upgrade to Linode 4096 (4GB RAM, $160 monthly). To jack it up all the way, we could get crazy with Mr. Linode 20 (20GB RAM, $800 monthly).

Walter and Rob, how should we proceed on this?

robgur commented 13 years ago

I think we need to consider the Linode 4096 upgrade at $160 monthly. That is still a pretty good deal for a year ($1920/yr). Will check with Andrew about making it so, ok?

eightysteele commented 13 years ago

Yeah, the Linode 4096 seems right. Definitely check with Andrew to see if this makes sense.

walterj commented 13 years ago

4GB RAM does not strike me as much, but defer to you as experts.

eightysteele commented 13 years ago

So we've upgraded to Linode 4096 but I'm not seeing a huge performance increase WRT tiling. The bottleneck is layers requiring mapfile.xml I/O, but I'm a little stumped why range tiles (which are now pure Python via Mapnik) appear to be a little sluggish? Need to look into it a bit.

eightysteele commented 13 years ago

Um, ok, now it's about 4 times faster than it was this afternoon after clearing memcache. Still looking into things...

eightysteele commented 13 years ago

Performance is a little better now, generally in the 4 second range for rendering tiles at a new zoom level. I think this is as far as we can go with this issue before the demo though.

eightysteele commented 13 years ago

Next step in performance tuning is spatial db stuff via couch or postgresql/postgis. Huge performance gain there since we'll skip mapfile.xml I/O which is the bottleneck in general.