The AudioScrobbler folk are thinking very hard about scalability. Having recently switched to a new database server they’re now pondering what other changes they may need to make to ensure that the service scales as smoothly as possible.
In this posting to the audioscrobbler-development list Richard Jones outlines some proposed options. It seems that they’ve already tuned the database server and are considering changes to the submission protocol, the means by which your MP3 player submits track info.
The most fundamental change to the protocol, which is further described in the AudioScrobbler Wiki, is to do more on the client. Each client would hold it’s own database of track information and then intermittently upload data, based on a interval controlled by the server. In the existing model data is POSTed to the server after a track is ~50% of the way through.
Personally I think the protocol could be adapted to be more RESTful. The key thing being to make each user account a resource which can have information requested from it (GET) or updated (POST). Making more use of GET ought to help scalability as caching intermediaries can better do their thing.
This would make an good optimisation/design exercise for RESTafarians to get involved with. Comments should be added to the Wiki or sent back to the mailing list.
Update: I posted a suggestion for an alternative interface which I think is more RESTful. I’d love to get this critiqued (hint, hint!)
AudioScrobbler Scalability
Published
Lost Boy 