The web is not print, however, and the embedding of nice typography seems to come with a few other issues: the first few site prototypes on which we worked with @font-face tended to be plagued with performance problems – a really big deal in our case, given that we manage high-traffic sites. The User experience of the pages we had tested was sub-par: slow loading times, blocks of text “jumping” after the actual font gets loaded, etc.

And yet, webfont services are popping like mushrooms and seem rather popular. I decided to give four of them a look, to see how good – and how fast – their service was.

My test page, based on fontsquirrel’s webfont comparison page loads the fonts from the 4 providers (unfortunately, fontdeck does not seem to offer the Cantarell fount, a common denominator between all other three services, hence the difference). The rest of my testing consists mostly of analysis of speed, HTTP headers and other tinkering through firebug.

Google Font Directory

Google’s webfont solution is “view source” friendly: one can copy-paste from another site and get the fonts working immediately. Their offering is still rather limited, but their site is no-nonsense, immediately usable, and does not require any signup, payment – indeed all the fonts provided are Open Source (distributed under Open Font License).

Google’s service is also pretty good with caching – their servers appropriately respond with a 304 not modified open a request, and they send proper Expires: and Last-Modified: HTTP Headers.

Font Deck

Setup with Fontdeck is relatively easy: one needs to register on their site, choose a few fonts, and get a piece of HTML and CSS code to use. While I ran into a silly UX issue and couldn’t find the code samples at some points (a case of bad whitespace and beyond-the-fold design), using the font deck web site is rather pleasant.

However, after setting up my test page by following all their instructions, I never managed to get the fonts to appear: the URIs given to me in the sample systematically resulted in “403 forbidden” responses. I could not test the performance of this solution yet.

Font squirrel

Font Squirrel is clearly different from the rest. Similar to the many foundry catalogs available for designers, it includes a really simple wizard to create a font-face kit from any (downloaded) font. Very geek friendly. This is also the only service that caters to site admins who want to host their fonts themselves, and it does not provide a hosted font-face service.

Typekit

One of the first service of the genre, Typekit also requires you to register yourself and your site. Javascript-based. Really similar to font-deck (which I believe it predates), Typekit will let you browse fonts for your site, and will provide a javascript snippet to add to pages to embed the fonts.

However, after setting up my test page by following all their instructions, I had trouble getting the fonts to appear: the URIs given to me in the sample systematically resulted in a “404 Not Found” response. It took me a while to understand (DOH!) that I had to choose fonts, add them to my site’s collection THEN publish in order for the system to work. My bad, their UX is really decent and I should really have understood this faster.

This solution is actually quite nice, as it allows me to choose which weight and style I want to include in my kit – which can be a big win for file weight, and thus performance.

Caching-wise, Typekit also behaves nicely, with the same combination of “304 Not Modified” response, Expires: and Cache-Control: HTTP Headers seen in Google’s service.

Their caching policy is much less aggressive than Google’s, however: while Google sends a cache directive for 14 days (Cache-Control: private, max-age=1209600), Typekit sends one for 300 seconds. I assume the reason for this difference is that with Google, you link to each individual font (which change very rarely), while with Typekit you link to your kit, which you may tinker with a lot. In any case, a cache policy of 300 seconds (5 minutes) is rather likely to cover the average visit, so this short timeout should hopefully not have too much of an impact on your visitor’s experience.

One thing I’m not a big fan of: the script Typekit gives you doesn’t just lets you embed fonts, it also adds a little Typekit logo on all your pages. Not cool. I assume that paid customers don’t get the pesky logo, but regardless, if a service is going to advertise itself on my site, I’d like to know in advance…

Anything Else?

Any other service you would like to see tested here? Any other indicator of performance or cost-effectiveness you would like to see in the table? Tell us in the comments and we’ll try to keep this page up to date.

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.