Contexte

2. Contexte • Refonte du Site www.Téléshopping.fr

3. Contexte • Refonte du Site www.Téléshopping.fr

4. Enjeux et objectifs Proposer une offre produit élargie avec une majorité de références disponibles uniquement sur le web : le site proposera ainsi l’assortiment le plus complet et le plus large de l’enseigne. Multiplier et diversifier les zones de sollicitation et d’animation commerciale : multiplication des liens up et cross selling, création de listes de produits thématiques et transverses, meilleur affichage des promotions, achats groupés, ventes flash, zone éditoriale… • Choisir l’outil le plus adapté à nos besoins via étude comparative. • Disposer d’une plateforme « dernière génération » permettant de supporter les futurs projets d’évolutions fonctionnelles et d’accélérer nos développements • Miser sur une solution de gestion de site e-commerce innovante et complète

5. Pourquoi Magento • Solution Open Source • Coûts de développement maitrisés • Répondant à nos besoins E-commerce • Répondant à nos besoins Editoriaux • Prise de risque acceptable

6. Fonctionnalités • Répondant à nos besoins E-commerce (natif) • Gestion de panier • Gestion de frais de port • Gestion des remises (pas totalement) • Gestion des clients • Aux besoins éditoriaux (natif) • Commentaires produits • Gestion des mails • CMS … • Gestion des univers (via les catégories) • Adaptées pour nos besoins • Gestion de trucs et astuces • Gestion des offres commerciales • Achats groupés • Le paiement • Flux externes : ERP, RNVP, Dédup

7. Les offres commerciales • Le prix et l’affichage des articles sur le site Téléshopping sont déterminés par les offres commerciales. • La gestion des offres se basent sur le module des « Promotions » déjà existant dans Magento et exploite l’application des règles sur les prix. Le module à été étendu et adapter pour répondre aux besoins de Téléshopping sans modifier son noyau. • Une offre commerciale est associée à un article et un seul. Un article est associé à 0 ou n offres commerciales. • Les articles et les offres associées sont mis à jour quotidiennement à partir de l’ERP (Générix)

8. Les fiches Trucs et astuces • Les fiches « Trucs et astuces » correspondent à un contenu éditorial qui permet de donner des informations supplémentaires sur un produit donné. • La particularité de ce module est l’association des fiches à des articles et inversement. • Soucieux d’exploiter au maximum les fonctionnalités de Magento, nous avons adapté le modèle des catégories et des produits pour créer les niveaux et les fiches « Trucs et astuces » • Ainsi, nous pouvons créer un niveau ou une fiche indépendamment, associer une fiche à un niveau, associer une fiche à un article et inversement.

9. Extensions spécifiques • Achats groupés : • L’achat groupé permet d’obtenir un produit à un prix réduit. Le % de réduction augmente en fonction des clients participants. • Ce module est associé au module de gestion des Télécodes existant dans Magento. Le télécode sera envoyé à tous les participants en fin des enchères • Paiement : • Création d’une extension de paiement avec Ogone complètement paramétrable dans le BO • Intégration du paiement avec la carte de fidélité OK Shopping • Application des facilités de paiements aux différents mode de paiement (complément de module paramétrable dans le BO)

10. Les performances et notre intervention • Contraintes projet : • 3 pics de prises de commandes dans l’année à hauteur de 6000 commandes/heure • 1500 produits actifs au catalogue • 2500 règles de gestion actives de prix • Environnement de preprod : • 1 loadbalanceur, 1 firewall • 2 frontaux • mono processeur, 8 Go de RAM • APC • Zend Debugger • Magento 1.1.6 avec utilisation des règles de réécriture • 1 SGBD • bi processeur, quadri coeur • 32Go de RAM, dont 12 dédiés aux clés Innodb • 1 filer (pour les partages du cache, des sessions et des médias) • var/session, media/catalog/product/cache, jpg, video, skin • 3 webservices (interconnectant avec le site) : • ERP : gestion des clients et de leur commandes • AMABIS : normalisation des adresses • MailPerformance : gestion de mailing

11. Les performances et notre intervention • Tests de charges : • Réalisés avec l’outil …. • pic à 100 utilisateurs sur un frontal • pic à 100 utilisateurs simultanées sur deux frontaux • pic à 200 utilisateurs simultanées sur deux frontaux • Résultats et nos optimisations : • Lenteur de navigation dans les pages du site : • Utilisation du cache Magento • Compression gzip du contenu envoyé au client • Pré-génération du cache des informations produits et catégories (à adapter en fonction de l’architecture : partager/copier le cache ou le pré-générer pour chaque frontal) • Requêtes MySQL : • Optimisation du moteur MySQL avec l’intervention d’un expert MySQL • Amélioration de certaines requêtes: contrairement à ce que l'on pourrait penser, l'utilisation d'index n'a pas forcément montré les meilleures performances. Il est préférable parfois de passer par les valeurs des attributs plutôt que par les clés primaires => Bien utiliser le profiler

12. Les performances et notre intervention • D’autres pistes d’optimisations : • Augmentation du nombre de frontaux (4 prévus) • Réduction du nombre d'insert / update en désactivant notamment les logs gérés par Magento • Dissocier lecture et écriture sur des SGBD différents • Utilisation du module de compression des css et js. • Monter en version Magento

13. Optimisation des performances 1/3 • Optimisation des fronts • Configuration serveur : HP Proliant 360 G5, 8Go RAM, 1 CPU quad core 2,83Ghz, 2HDD 72 Go SAS, 4 Nics • Montage NFS des volumes suivants : • var/session • media/catalog/product/cache • media/catalog/product/jpg • media/catalog/product/video • Skin • Montage tmpfs du volume var/cache

14. Optimisation des performances 2/3 • Optimisation MySql • Configuration serveur : HP Proliant 360 G5, 32Go RAM, 2 CPU quad core 2,83Ghz, 2HDD 72 Go SAS, 4 Nics • Configuration & tunning MySQL : • max_connections = 800 - table_cache = 4096 • max_allowed_packet = 2M - binlog_cache_size = 1M • max_heap_table_size = 256M - sort_buffer_size = 16M • join_buffer_size = 512K - thread_cache_size = 128 • thread_concurrency = 8 - query_cache_size = 128M • query_cache_limit = 2M - ft_min_word_len = 4 • thread_stack = 192K - transaction_isolation = REPEATABLE-READ • tmp_table_size = 256M - tmpdir = /mysqltemp • key_buffer_size = 128M - read_buffer_size = 1M • read_rnd_buffer_size = 512K - bulk_insert_buffer_size = 64M • innodb_additional_mem_pool_size = 16M - innodb_buffer_pool_size = 12G • innodb_file_io_threads = 4 - innodb_thread_concurrency = 16 • innodb_log_buffer_size = 8M - innodb_log_file_size = 512M • innodb_log_files_in_group = 3 • Montage du volume tmpdir en tmpfs (5Go) • Utilisation de la console d’Administration Mysql : Mysql Entreprise Dashboard • Activation de la fonction « Query analyzer » dans Mysql Entreprise Dashboard.

15. Optimisation des performances 3/3 • Optimisation du code • Analyse du nombre de requêtes • Analyse des requêtes • Mise en place du cache • Activation de APC • Résultat : • Nombre de requêtes réduit par 4 au niveau du code • Nombre de requêtes réduit à 0 pour la demande de la page d’accueil grâce à la pré génération des pages en cache.

16. Test de charge • Test de charge effectué avec 2 Fronts & 1 BDD • Charge utilisateur maximale : 200 • Requêtes/s : 630 • Temps de réponse moyen (s): 0,66 • Durée de test moyenne (s) : 84,3 • Temps de réponse moyen de la page (s) : 0,061 • Resultat • Charge non visible par un utilisateur. • Charge CPU sur Front : uptime de 1 • Charge CPU sur BDD : moins de 5%