Your SlideShare is downloading. ×
Accès concurrents et scalabilité
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Accès concurrents et scalabilité

3,862
views

Published on

L'accès concurrentiel est un problème majeur et récurrent dans toute application web un tant soit peu sollicitée. De sévères problèmes de corruption de caches et de locking se produisent quand la …

L'accès concurrentiel est un problème majeur et récurrent dans toute application web un tant soit peu sollicitée. De sévères problèmes de corruption de caches et de locking se produisent quand la concurrence d’accès n’a pas été prise en compte dans le processus de développement et l’analyse initiales de l’application.

Les conséquences business peuvent être fatales et donner une image catastrophique d’une plateforme: pages vides, données obsolètes présentées, images corrompues, autant d’échecs, cuisants pour les techniciens, et coûteux pour l’entreprise. Confrontés à ces problématiques au cours de 10 dernières années sur des plateformes critiques de publication de contenu, servant plusieurs dizaines de millions de pages par mois, nous voudrions partager les bonnes pratiques d’architecture logicielle que nous avons accumulées: résorption des lock & deadlock de bases de données, des transactions volumineuses, optimisation de l’entrée/sortie disque.

La diffusion de plus en plus large de PHP, et la professionnalisation de son usage le placent dans des contextes où sont rapidement atteintes les limites du langage quant à la gestion de la concurrence. Nous partagerons le résultat de notre recherche & développement, touchant aussi bien les outils utilisables dans ce contexte (Varnish, Memcached, Redis...) que les algorithmes et architectures adaptées.

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,862
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
25
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Accès%concurrents%et%scalabilité JérômeVieilledentmercredi 6 juin 12
  • 2. From simple presentation and content management to digital business Focus of organization’s core- business and simplify complexity: cloud-enablement Market-driven Innovationmercredi 6 juin 12
  • 3. The 5 pillars of Innovation @ eZ eZ Community eZ R&D Community eZ R&D Partner conferences Product Innovation Board eZ Marketmercredi 6 juin 12
  • 4. Quoi ? Des accès concurrents en PHP ??? 4mercredi 6 juin 12
  • 5. Quoi ? Des accès concurrents en PHP ??? PHP est synchrone Chaque processus est isolé HTTP est (à peu près) stateless et PHP respecte ce principe 5mercredi 6 juin 12
  • 6. Quoi ? Des accès concurrents en PHP ??? Sauf que les visiteurs ne sont pas synchrones ... Et les contributeurs non plus... Flux PHP => OK Interaction avec le monde extérieur => c’est une autre histoire Le cache est généralement écrit sur un disque Idem pour fichiers publiés par les contributeurs Transactions BDD 6mercredi 6 juin 12
  • 7. Accès concurrents : Cas classique 7mercredi 6 juin 12
  • 8. Le cas idéal WebApp 8mercredi 6 juin 12
  • 9. Le cas idéal Contentcache WebApp 8mercredi 6 juin 12
  • 10. Le cas idéal Contentcache WebApp 8mercredi 6 juin 12
  • 11. Cache en cours de génération WebApp 9mercredi 6 juin 12
  • 12. Cache en cours de génération Contentcache(genera9ng) WebApp 9mercredi 6 juin 12
  • 13. Conséquences potentielles Lock wait timeout Blocs de cache vides Deadlocks Pages chargeant indéfiniment Écritures concurrentes Cache corrompu 10mercredi 6 juin 12
  • 14. Conséquences potentielles 11mercredi 6 juin 12
  • 15. Solutions immédiates Pré-génération du cache Que sert-on pendant la génération ? CDN (Akamai, Level3) €€€ $$$ £££ Reverse-proxy (Varnish) Site plus statique (à première vue) 12mercredi 6 juin 12
  • 16. Stale Cache 13mercredi 6 juin 12
  • 17. 14mercredi 6 juin 12
  • 18. 14mercredi 6 juin 12
  • 19. 14mercredi 6 juin 12
  • 20. Scalabilité : Introduction au cluster 15mercredi 6 juin 12
  • 21. Pré-requis Scalabilité%horizontale 16mercredi 6 juin 12
  • 22. Pré-requis Scalabilité%horizontale Binaries Cache (content,config,transla9on...) 16mercredi 6 juin 12
  • 23. Pré-requis Scalabilité%horizontale Binaries Cache (content,config,transla9on...) 16mercredi 6 juin 12
  • 24. Synchronisation : Quel(s) outil(s) ? NFS Pas très copain avec PHP Pas fiable sur les metadata SAN €€€ $$$ £££ Rsync Lent Synchro indépendante de l’application (pas de contrôle) On part du principe que les ressources sont toujours disponibles DRBD Voir Rsync 17mercredi 6 juin 12
  • 25. Synchronisation : Quel(s) outil(s) ? PHP%Cluster 17mercredi 6 juin 12
  • 26. Cluster PHP Librairie PHP «cluster aware» Se substitue aux fonctions PHP natives $fh = eZClusterFileHandler::instance( ‘cache_file’ ); $cache = $fh->fetchContents(); Stream wrapper : http://php.net/streamwrapper $cache = file_get_contents( ‘ezcache://<some_cache_id>’ ); Logique et Backend FS dédiés Stockage fichiers physiques sur NFS + stats dans BDD (DFS) Stockage de blobs en BDD (Redis) Fichiers binaires servis via un front-controller spécifique Droit au but Éviter les facilités de convenance (ORM...) Utiliser X-SENDFILE si possible 18mercredi 6 juin 12
  • 27. «Varnish, ça a quand même vachement plus la patate» 19mercredi 6 juin 12
  • 28. Varnish : Avantages Cache statique, basé sur URI «Bulle de protection» autour des serveurs frontaux Possible de cacher des fragments via ESI 20mercredi 6 juin 12
  • 29. Varnish : Inconvénients Externe à l’application Basé sur des TTL en secondes (Cache-Control) Tout ne peut pas être caché (POST, certaines requêtes AJAX...) Gestion des ESI peut être un (gros) poil complexe 21mercredi 6 juin 12
  • 30. Le meilleur des deux mondes 22mercredi 6 juin 12
  • 31. Varnish : Le meilleur des 2 mondes Utiliser Varnish (ou autre CDN) pour les médias Utiliser l’API cluster pour purger/remplir le cache HTTP 23mercredi 6 juin 12
  • 32. Conclusion 24mercredi 6 juin 12
  • 33. Conclusion PHP est synchrone, pas vos visiteurs, ni vos contributeurs Toujours réfléchir si l’implémentation est «concurrency-safe» Eviter l’effet «boîte noire» d’outils externes 25mercredi 6 juin 12
  • 34. Fin Twitter : @jvieilledent https://joind.in/6461 26mercredi 6 juin 12

×