Linked Data is part of the process of publishing data in a way that it will be useful for anyone else. It is all about creating awesome stuff. Often, the task seems daunting for organizations or individuals, when it is just a question of baby steps. In the Linked Data page, there are 5 steps for starting publishing data in a way that would be useful for everyone else.

• ★     make your stuff available on the web (whatever format)
• ★★    make it available as structured data (e.g. excel instead of image scan of a table)
• ★★★   non-proprietary format (e.g. csv instead of excel)
• ★★★★  use URLs to identify things, so that people can point at your stuff
• ★★★★★ link your data to other people’s data to provide context

One of the big benefits of digital assets is that the cost of putting online data and modifying them is lower than in the material world (an online phonebook can be updated in real time and then evolve). One of the big benefits of Linked Data is URIs for piece of data or concepts on this data. Extensibility comes for free because data are expressed with a graph (not like relational databases).

Small steps are cool and full of awesome. Sharing gives you plenty of love.

En plus du projet Groupes plusieurs projets d’améliorations sont constamment en cours sur le Grand Club et nous permettent de l’améliorer à chaque semaine. Voici en gros le travail qui a été fait dans les dernières semaines afin d’améliorer la stabilité et la performance du Grand Club face à la demande toujours grandissante des usagers.

Le language: Ruby Enterprise Edition 1.8.6
La version ‘Enterprise’ de Ruby permet d’améliorer les performances générale du language et de corriger certaines défaillance de celui-ci. Oui, nous pensons déjà à le changer pour Ruby Enterprise 1.8.7….

La Fondation: Ruby On Rails
Nous avons passé à la version de Rails de 2.1.0 à 2.2.2 et nous comptons encore la changer pour la version 2.3.4 afin d’améliorer encore la performance de Rails.

Database Performance:
Plusieurs requêtes ont été optimisés. Notre façon de faire les requêtes avec Rails (ActiveRecords) a également été revue afin d’être plus optimal.

Caching: Squid
Squid est un proxy permettant de cacher les images, les css et les javascripts. Ceci nous permet de servir les pages plus rapidement. Il est également prévu de se servir de memcache pour cacher les pages du Grand Club afin de les servir plus rapidement encore.

Moteur de recherche: Caching, Ferret Vs Sphinx
Nous avons changer la façon de faire les recherches lors de certaines recherches en modifiant et optimisant les requêtes. De plus, les résultats de recherches sont maintenant caché pendant un certains temps. Par le passé, nous avons expérimentés plusieurs problèmes avec l’instabilité du moteur de recherche Ferret. C’est pour cette raison qu’un projet nous permettant de tester et d’implanter Sphinx (un autre moteur de recherche) a été mis sur pied. La dernière étape dans les tests sur Sphinx sera mise en place dans les prochaines semaines. Si les tests vont bien nous serons en mesure d’implanter ce nouveau moteur de recherche.

Dark Release:
Le principe de Dark release nous vient de Facebook. Il consiste à mettre en ligne graduellement des nouveaux features. Cette technique nous permet de suivre plus facilement les réactions de l’application et des serveurs. Une subite montée en charge dû à un nouveaux features est ainsi mieux contrôlé. Ce mécanisme nous permet également de couper temporairement un feature afin de supporter une charge plus grande. On pourrait par exemple couper le lifestream, lors de la journée des transactions afin d’avoir un gain en performance.

Ceux qui ont contribué à rendre tout cela possible Benoît, Martin, Amirouche, Louis, Marc-Antoine, Ana, Yves, Sébastien, Daniel et moi-même Jean-François.

Skyrock Summary

Skyrock has been created in December 2002 and is now the 7th largest social network in the world. In July 2009, it was said to have 26 millions blogs, 16.6 millions profiles, 650 millions of articles and almost 4 billions of comments. In December 2007, the blogs brought more than 15 millions euros in revenues according to its CEO Pierre Bellanger.

Skyrock Platform

The information is scarse about skyrock, but searching here and there, we can find a few details. In 2005, skyrock was serving

around 3 millions pages a day on two gigabit links. The balancing rules are quite complex since the content is splitted on multiple servers and SANs. We use software load balancers: Zeus ZXTM [zeus.com] on Gentoo Linux. The nice thing about software load balancers is that you can easily replace the hardware if it fails. Having a spare PC is way cheaper than a spare load balancer. We are very pleased with ZXTM so far. Very reliable, fast, and very flexible. It uses a PHP-like scripting language to process requests and you can really handle any specific backend architecture with that.

and we can discover a bit more information from 2004

We have a bunch of static servers for static HTML, CSS, images, etc. They run minimal Apache servers, designed for speed, with NPTL and the worker MPM. Non-forking servers like thttpd or lighttpd is also an option. The static servers are mainly old P3 machines, with only 512 Mb RAM.

Then, we have servers for PHP. The Apache they are running is huge (our web sites need a lot of modules), the hosts are dual 3 Ghz Xeon with 2 Gb RAM and there are some other specific tweaks.

Content differentiation is important. It’s a waste to spawn huge Apache process to serve static stuff, just because the same host should also be able to serve PHP. Also, tuning (esp. NFS) is very different for static and dynamic content. And as a specialized server often serves the same files, caching is more efficient.

We run Gentoo Linux on all web servers, plus one DragonFlyBSD (mostly for testing).

The same content differentiation is made for SQL server. One SQL server serves one sort of thing, so that caching is efficient. Also don’t forget that on x86, Linux and MySQL can hardly use more than 2 Gb of RAM. So with big tables, this is really annoying. We are switching SQL servers to Transtec Opteron-based servers for that.

On high traffic infrastructures, the I/O is often the bottleneck especially if you serve a lot of different content.

For our blog service, we had to buy a Storagetek disk array with 56 disks (fiber channel, 15k) in RAID 10. As NFS would introduce too much delay, we directly plugged two web servers to the controller of the disk array. These web servers are the NFS servers for the PHP servers, but they also directly serve the static content.

The access time of hard disk is really annoying. For shared data, but also for databases. We found that RAID 5 was way too slow (even with the high-end Storagetek/LSI controller) since we have about 1 write for 5 reads. So we had to switch everything to RAID 10. It really performs better, but it’s obviously more expensive.

Another bottleneck was the share of PHP sessions between all load-balanced PHP server. We first used a MySQL/InnoDB-based solution, but it poorly scaled. That’s why I had to write specific software : Sharedance http://sharedance.pureftpd.org/ [pureftpd.org]

If you have more information about this platform, please share with us. It would be an excellent opportunity for an article on High Scalibility blog.

Update 2009-10-19: That was quick ;) information from 2007 by the dev team.

9 loadbalancers Zeus Layer 7 ZXTM: machines diverses;

50 frontaux Web Apache 1.3.x: bi dual-core, 6 Go de ram, PHP 5.2, Xcache, Nginx pour les élements statiques;

50 serveurs MySQL 5.0.x: bi dual-core, 16 Go de ram, 8 disques SAS RAID 10 73 Go, en réplication master/master;

30 serveurs Memcached 1.2.x: bi dual-core (complètement sous exploité actuellement :), 16 go de ram, 3 instances memcached de 4 Go par machine;

2 serveur de sessions sharedance: stockage tmpfs 6 go (on en utilise grosso modo la moitié), un en master, un en secours;

1 cluster de stockage Isilon: 40 nodes de 12 disques SATA pour le stockage; A coté, divers types de stockages encore un peu utilisés (principalement des restes d’avant Isilon), avec SAN Sata Transtec, SAN Fiber Chanel Transtec, SAN Fiber Chanel Storagtek, SCSI Interne, SATA Interne… Oui, on a essayé beaucoup de systèmes différents par le passé :-)

Le tout tourne sous Linux x86_64, généralement du debian avec nos paquets.

Le Grand Club Platform

At Pheromone, we are developing a social network for RDS, Le Grand Club. It’s why we are always eager to learn about the features, tools and options that other sites have been using. The lead developer for this social network is Benoit Goyette (A Web developer team is working on it every day). The site runs on Ruby On Rails with postgres.

It is wise to have a good HTTP cache policy for your web site. It helps to reduce the cost of bandwidth, it gives a better user experience by not having to download each time you request a resource. Read Mark Nottingham’s post on tips for building a cache aware site.

The issue

When creating a social network site, some assets, such as avatars, require a contradictory HTTP cache policy.

• Avatars images need to be cached for not having to download them at each HTTP request
• Avatars images need to be refreshed each time they have been changed by the user. The user expects his, her image to change right away.

The solution

Usually, for highly dynamics assets, people use cache busting to force the refresh. The issue is that we still want the avatar images to be cached.

http://example.org/myavatar.jpg?dijfHG635jhdu

On RDS social network site, Le Grand Club, we recently implemented among other strategies a better cache policy for avatars. We used a timestamp in seconds of the last modification date of the avatar image.

http://example.org/myavatar.jpg?1242843683

This will smooth the experience of users on the longterm. Managing RDS Web sites is challenging, it pushes the limits for performance and optimization. We are researching, tweaking, improving the code on a daily basis.

Facebook a récemment donné la possibilité à ses utilisateurs de choisir des alias (username). Ils se sont préparés en avance pour ce qui allait sûrement être une option populaire du réseau social.

Une partie de Memcached a été attribuée spécifiquement pour la recherche des mots libres.

The Memcached infrastructure that runs behind every page on the site was partitioned and expanded to cope with users checking the availability of names.

1 terabyte de mémoire cache pour la nouvelle option username

One terabyte of in-memory cache was dedicated exclusively for the username launch.

Les pages d’enregistrement ont été réduites à leur strict minimum pour éviter les appels javascripts

the registration page for usernames was stripped down as much as possible to incur very little additional load on our web servers.

Ils ont lancé la nouvelle option pendant une heure de moindre charge

We intentionally chose to launch the feature at a time of low site activity (Friday at 9PM Pacific)

Deux semaines en avance, ils ont déployé cette option afin de la tester au niveau du backend avec un trafic normal.

“Dark Launching”: During the two weeks prior to launch we began what we call a “dark launch” of all the functionality on the backend.

Dans le cas d’un enjeu majeur de traffic, ils avaient prévu une désactivation de toutes les fonctions du site afin de ne favoriser que username.

“Nuclear Options”: In the event that Facebook became overwhelmed with traffic and suffered performance problems as a result we also prepared for what we called ‘Nuclear Options’ such as cutting off nearly all the functionality on the Profile page, turning off Facebook Chat, and completely disabling the Home page. Any of these options were an absolute last resort to keep the site functional as they would have resulted in a severely degraded user experience.

Lifestream du Grand Club

Toutes ces données sont fort intéressantes et nous l’avons appris à nos dépens récemment. Nous avons lancé le Lifestream (Mes Faits Saillants), une vue de toutes les interactions pour une personne donnée. Le trafic de la bigbox (boîte Grand Club sur les pages RDS) ajouté à la richesse des interactions du Lifestream a écroulé le site du Grand Club à plusieurs. En même temps que nous cherchions la source possible des erreurs, nous avons adopté différentes stratégies. L’une d’elle ressemble à celle de Facebook, nous avons redirigé 1/6 du trafic total du Grand Club vers une machine avec le lifestream et les 5/6 restants sans le lifestream.

Le plus fascinant a été la réalisation que certaines options ne peuvent être testées qu’une fois déployées en production. La stratégie de Dark Launching est donc absolument nécessaire. Elle permet de vérifier les interactions au niveau du backend.

Nous avons également atteint un palier supplémentaire en termes de performances ce qui nécessitera un nouveau travail d’optimisation et de développement. Un réseau social est objet de nature biologique. Son infrastructure doit évoluer en dehors du développement des options.