Archives pour l'étiquette OJD

Audience en visiteurs unique et pages vues de Ameli.fr, site web de la caisse d’assurance maladie, ou l’utilisation d’internet par les assurés sociaux.

« Ameli.fr plébiscité »

Belle annonce sur l’intranet de la caisse primaire d’assurance maladie de Paris. Avec 1 Millions de visites pour l’année 2011 la CPAM parisienne semble aux anges. Ceci est à rapprocher des chiffres OJD de janvier 2012 ou l’intégralité du top 100 français fait le million de visiteurs en un uniquement mois.

Heu c’est tout ?

Ce qui est le plus remarquable c’est les 26,5% d’assurés parisienne qui ont ouvert effectivement leur compte.
Actuellement 66% des ménages ont une connexion internet, auquel s’ajoute ceux qui utilise internet depuis ailleurs que chez eux. Sur Paris le taux d’équipement doit être plus fort, compte tenus des effets du centralisme et de la composition CSP. Or un ménage c’est plusieurs assuré sociaux (environ 2).
Donc, grossièrement, cela veux dire que 13,25 % des ménages parisienne sont utilisateur d’un compte Ameli.fr ….. Moins glorieux compte tenu du taux d’équipement de 66%. Et nous parlons ici de Paris pas de la mamie du cantal !
Bisous Ameli, mais tu peux et dois mieux faire étant donné que tu es un service public

L’OJD publie l’audience du web français sur un site dédié

L’OJD ouvre un site web dédié à son activité de tiers certificateur des audiences web de ces membres.

Ces chiffres à destination des agences, annonceurs, éditeurs, journalistes… sont établis à partir de normes reconnues sur le plan international. L’OJD est membre fondateur de l’International Federation of Audit Bureaux of Circulations (IFABC) qui regroupe les pays les plus avancés et les plus actifs dans ce domaine (Etats-Unis, Allemagne, Grande-Bretagne, Espagne…).

Comme je l’expliquais sur mon billet à propose de l‘audience de septembre Tele-loisir.fr et de Voici.fr. L’OJD, est l’unique organisme de certification en France des données de fréquentation de l’Internet, publie chaque mois les résultats de trafic et d’audience de tous ses adhérents qui regroupe les plus grand site français.

L’OJD vous permet de ainsi de comparer les audience en terme de visite et visiteur unique ainsi que le véritable effort de production en pages vue des grands sites web de presse français toutes les données certifiées sont accessibles en accès gratuit sur ce site.

Septembre Tele-loisir.fr et les chiffres OJD, Aout Voici.fr et les chiffres Nielsen

Les chiffres OJD d’audience de Septembre 2009 sont publié. Il contabilise les pages vue, visite et visiteur unique des adhérent OJG. Adhérent qui regroupe de plus en plus de grand acteur français ton la quasi intégralité des sites de presse.

Tele-loisir.fr : 14% de pages vues supplémentaire selon l’OJD

Dans le classement OJD des sites grand public français Télé-loisir.fr est huitième devant Liberation.fr ou leparisien.fr avec 27 059 401 93 532 009 pages vues. Je commentais récemment du fait que nous avions battu notre record de production en septembre. Ce record explique le bon de 14% de pages vues supplémentaire.

Dans cet articles je donnais quelque une des pistes technique suivies pour soutenir une tel audience.

Voici.fr : le plus puissant des sites people selon Nielsen

Je vais citer le communiqué de presse de Prisma : Le site Voici.fr a enregistré en août un nouveau record d’audience avec 2 346 000 visiteurs uniques selon Nielsen, soit une progression de 14% (vs juillet 2009). Une performance qui permet à Voici.fr de passer devant son principal concurrent et de prendre la place de leader des sites d’actualité people français.

Je pense que que la stratégie du SEO Backling Discovery à du contribuer à ce résultat. Le pouvoir du mod_rewrite est immense… Un énorme potentiel de liens pas en valeur car débouchant sur des 404 ou du duplicate content que vous formatez correctement à coup de 301 c’est le coup d’accélérateur décisif.

Je pense également que la stabilité et la qualité constante de la diffusion même au moment du pic d’audience historique de la mort de Michael Jackson ne sont pas étrangés à ce succès.

Comment connaitre l’audience des grands sites web de presse français ?

L’audience et la page vue

Je vous parle parfois de forte audience sur voici.fr ou gala.fr par exemple au moment de la mort de Mickael Jaskson. J’évoque des fortes charge absorbé avec l’aide de NAS, squid et autre. Mais comme être sur de ce que j’avance ? Comment comparer avec votre architecture ? Est ce que ce les techniques ou solution que je dis utiliser sont si efficace ? Et les autres ils bourrent à combien sur leurs babasse ?

Bref « il est gros à quel point ton site ? »

Continuer la lecture de Comment connaitre l’audience des grands sites web de presse français ?

Comment voici.fr, gala.fr, geo.fr, femmeactuelle.fr en eZPublish utilisent le StaleCache et une architecture NAS

Second couche

Pierre Jean Duvivier, responsable du département WebFactory de EditPress n’en fini pas de revenir sur sa terrible expérience avec Ez Publish 3.x et les raisons de son abandon par EdiPress. Revenir car déjà le propos à déjà été exposé par ses soins dans un article nommé EzPublish : l’enfer du devoir article que j’ai un peu commenté en exposant ma propre vision des problématiques soulevé par le choix d’eZ.

Je trouvais déjà la première condamnation de eZ sans nuance alors que le respect de quelques préceptes de dev permet de faire des choses bien plus que honorable avec eZ. Mais bon chacun son vécu et pour avoir transpiré à trouver des solutions d’architectures capable de soutenir l’audience je compatissais. Par contre la nouvelle et seconde couche passé par Pierre Jean Duvivier me semble un peu injuste car depuis 18 mois l’eau à couler sous les ponts. Un peu car la conception d’architecture pour eZ reste quelque chose de peu documenté et qui repose sur des connaissance quasi chamanquie.

eZ publish assure que le partage de donnée entre serveur dans une configuration multi-frontaux est prévus. Or dans la pratique on trouve vite des limites à cela. Je me permet de me cité moi même ^_^.

Dans le cas d’un site eZ avec du contenu dynamique la limite technique est de 30000 VU / 24h avec le partage d’information via NFS. Au delà de cette limite différent « bug » apparaisse qui vienne défigurer le contenue du site (bug wilcard, Bug NULLNULL, Perte cache block)

Dans le cas d’un site eZ avec du contenu dynamique la limite technique est de 35000 VU / 24h avec le partage d’information via le mode cluster dans une base de donnée Innodb/Mysql. Au delà de cette limite les demandes d’accès exclusif au information trop nombreux au point de bloqué le fonctionnement de l’application.

Pour dépasser les 35000 VU / 24h la seul solution que nous avons trouvé est de localisé l’intégralité de l’application sur un unique serveur en mode filer. Le matériel ayant évolué, avec un serveur Bi-Cpu quadri-core de 3Ghz avec 8Go de RAM il est parfaitement possible de produire 95000 VU / 24h c.a.d 300K pages vues par 24h. Nous avons testé cette solution sur voici.fr et gala.fr en version eZ 3.10 avec à chaque fois une réussite total, une bonne stabilité et le dépassement des seuil de production précédent. Reste que dépendre d’un unique serveur n’est pas une chose très sécurisante quand à la scalabilité…..

J’ai testé personnellement en suite différente architecture pour arrivé sur cette base à une solution multifrontal. Le NFS pur depuis un serveur lambda étant à oublier j’ai testé les profiles d’architecture suivante en multi-frontal avec l’aide de mon hébergeur hors norme pour son aide en R&D

  • Un serveur lambda partageant en mode bloc un volume via iSCSI. Deux frontaux utilisant ce volument via le système de fichier OCFS2 qui gère les concurrences
  • Un SAN Dell EqualLogic en mode bloc un volume via iSCSI. Deux frontaux utilisant ce volument via le système de fichier OCFS2 qui gère les concurrences
  • Un SAN Dell EqualLogic en mode bloc un volume via iSCSI. Deux frontaux utilisant ce volument via le système de fichier GFS2 qui gère les concurrences

Nous n’avons pas retrouver le rapport stabilité / capacité de production que nous avions connue avec le principe du frontal unique. Nous avons constaté que eZ ouvre et verrouille énormément de fichier par instance rendant le partage d’information entre frontaux problématique. Nous avons même constaté des lock récursif ce qui nous à tous laisser dubitatif. La conclusion était terrible, plus nous ajoutions de frontaux plus les instances entrait en concurrence pour accéder à l’information.

Quand le sujet était évoqué auprès des gens de chez eZ la réponse était par forcement audible. Par contre il était amusant de faire toussé Paul Bogermans de eZ publish en lui posant la question.

Mais depuis les choses on évolué

Suite à un forte pression des utilisateurs des moyen on été investi par eZ Publish pour que soutenir plus facilement une forte audience. Ceci à eu pour résultat le patch StaleCache dont j’ai parlé en signalant qu’il signifiait peut être la fin des combats.

Précédemment la génération d’un fichier cache se faisait à invalidation du précédent fichier, à la demande, et par chaque process qui le requiert; entrainant de nombreuses concurrences d’accès (lock des fichiers dans var/…/ezmutex) et une grande surcharge sur le filesystem. Le nouveau système (StaleCache) se débarrasse intégralement de la gestion de la concurrence par locks. Le mécanisme consiste maintenant à fournir aux frontaux web l’ancienne version du fichier de cache jusqu’à ce que la nouvelle soient re-générée. Ce qui diminue grandement l’empilement des process sur le filesystem en garantissant la génération du fichier par un process unique.

J’ai testé le StaleCache mais malheureusement pas dans une config multi-frontal. Rien à redire, ceci me semble être un direction bien plus pérenne que précédemment. Si quelqu’un pouvait tester ce patch avec une architecture serveur lambda partageant en mode bloc un volume via iSCSI. Deux frontaux utilisant ce volument via le système de fichier OCFS2 qui gère les concurrences, avec une audience forte je serais heureux d’en connaître l’issue. Le StaleCache est arrivé trop tardivement pour nous pour que nous l’appliquions sur ce type d’ architecture , nous avons pris une autre direction.

NAS

Nous avons fait le choix d’utilisé un NAS avec le protocole NFS. Ben et les bug lier à NFS vous allez me dire. Et bien avec la puissance d’un NAS et certainement avec l’implémentation propriétaire du protocole NFS du fabriquant nous n’avons pas ces bugs, par contre l’addition est douloureuse et ceci n’a peu être justifié que par un l’utilisation de cette ressource par plusieurs sites et une audience global des plus forte avec 6,7 Millions de visiteurs unique et 18,7 millions de pages vue par mois (OJD Janvier 2009). Avec une moyenne d’utilisation de seulement 140 opération seconde sur ce NAS nous avons encore de belle perspective devant nous.

Et le  »StaleCache’ ? et bien nous l’utilisons sur nos sites peoples avec succès.