Upload
hamblin-pascal
View
117
Download
2
Embed Size (px)
Citation preview
2
Refonte du Site www.Téléshopping.fr
Contexte
3
Refonte du Site www.Téléshopping.fr
Contexte
4
Enjeux et objectifs
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
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…
5
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
Pourquoi Magento
6
Répondant à nos besoins E-commerce (natif)• Gestion de panier
• Gestion de frais de port
• Gestion des remises (pas totalement)
• Gestion des clients
Fonctionnalités
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%