Vasyenmetro gets noticed

Vasyenmetro, our interactive Paris metro map has just been featured on the Google Geo Developers Blog.

This week we are featuring a sample app by the French web development house Medusis. They have put together a custom directions application that guides you between Paris metro stations. It is a beautiful app that uses several interesting features of the Maps API (...)

This is a great demonstration piece on using the Google Maps API to show custom data. Well done Medusis.

This comes after two mentions on Google Maps Mania, once for the inital French version and then when we developed an interface in English

Ultimately, of course, what's important is serving users well; but getting the word out is a necessary step, and peer recognition is always nice.

So thanks!

Paris Metro Map

A new interactive Paris Metro Map

A little bit of history

Navigating the Paris Metro is notoriously difficult. The official maps are helpful only if you already know your way around the network. The official interactive map by RATP is feature-complete but not very user friendly, and sometimes not working (for reasons we discuss below).

There used to be a fantastic device in the Paris Metro, called "PILI" for "Plan Indicateur Lumineux d'Itinéraire" where one could push a button for a start station, and a button for a destination, and the best way between the two would light up on a big metro map above.

These machines were built in the 1930 and at some point there were around 80 of them in the metro; but they were very difficult to maintain and so they eventually fell into disrepair; the only ones that are left don't work anymore.

PILI Online

Nowadays, it should be possible to make an interactive map that would replicate the ease of use of a device built... more than 80 years ago; and yet the existing transport map (for Paris or other cities) are usually very complex to use (when they exist at all)

In a bold and very welcomed initiative, the RATP (the public body that runs the Paris Metro) recently published its data about stations, routes, schedules, etc.

And so I decided to use this data to build an online version of the "PILI".

Our approach

The originality of our approach, I think, is that pathfinding is done in the browser; all the other apps or services (that I'm aware of) call a server to do the pathfinding, resulting in delays (Google Maps is by far the fastest, but it's still not immediate; others can be quite slow) or complete non-response if the service is down (the official RATP Plan Interactif is often down on week-ends for instance).

Doing pathfinding in the browser has many advantages

• it always work
• it's fast
• it doesn't cost me anything

The last point sounds trivial but it's actually a very important part of the UI; I can afford to make pathfinding as easy as 2 clicks (or even one click) because every path is calculated on the client. If a child decides to spend an afternoon clicking on the map (and my kids love it!) I have absolutely no problem with that. This addresses scalability issues in a big way.

In English

The application was first implemented in French, but today I'm happy to say that the English version is out! Language is not hugely important, since it's mostly visual, but directions should be easier to understand for English speakers now.

Caching is Magic

This blog is hosted on a small Linode machine that does many things; I was interested in speeding things up without improving the hardware.

For a blog, caching makes a lot of sense, since posts usually don't change much (or at all) with time; only aggregate pages change (with every new post).

In the same way, if you manage a website that serves content that's not updated frequently (case in point: product pages on an eCommerce site), implementing caching should be the first thing you try, before worrying about machines, load balancing, database bottleneck, etc.

I first tested the existing config. with ApacheBench on 5000 requests and a concurrency of 200; that failed after the 1000th request:

# ab -n 5000 -c 200 http://blogs.medusis.com/
This is ApacheBench, Version 2.3 
Benchmarking blog.medusis.com (be patient)
Completed 500 requests
Completed 1000 requests
apr_socket_recv: Connection timed out (110)
Total of 1022 requests completed

Then I implemented disk-based caching thusly (Apache2 on Debian):

• turned on mod_disk_cache (mod_cache is automatically turned on as a dependency of mod_disk_cache): a2enmod mod_disk_cache
• set up caching in the corresponding VirtualHost (CacheEnable disk /)
• restarted Apache /etc/init.d/apache2 restart

And that's it! Cache is on! The results are good -- here's the output from a new test with ApacheBench (edited for length):

# ab -n 5000 -c 200 http://blogs.medusis.com/
This is ApacheBench, Version 2.3 

Server Software:        Apache/2.2.16
Server Hostname:      blog.medusis.com
Server Port:               80

Document Path:          /
Document Length:        9689 bytes

Concurrency Level:      200
Time taken for tests:   15.633 seconds
Complete requests:      5000
Failed requests:        0
Write errors:           0
Total transferred:      49997231 bytes
HTML transferred:       48755613 bytes
Requests per second:    319.83 [#/sec] (mean)
Time per request:       625.327 [ms] (mean)
Time per request:       3.127 [ms] (mean, across all concurrent requests)
Transfer rate:          3123.19 [Kbytes/sec] received

Percentage of the requests served within a certain time (ms)
 50%    291
 66%    299
 75%    301
 80%    303
 90%    341
 95%   1144
 98%   7375
 99%   9234
100%  14428 (longest request)

These numbers are not extraordinary but they are honorable:

• 90% of requests are served under 400 ms (less than half a second)
• no request fails
• the mean number of requests per second is over 300 (wich is a respectable amount of traffic -- in 2008, Twitter used to get a mean of 300 requests per second).

There are many other things to caching; for instance, for disk-based caching you need a way to periodically clear the cache with htcacheclean. For more on this, Google and man pages are your friends.

But the point is: caching is the closest thing to a free lunch!