EcommerceDEV. Développement, optimisation et sécurisation des sites de commerce électronique.
arrowAccueil arrow Optimisation arrow Performance arrow Besoins en performance des sites B2C
Samedi 22 nov 2008
Nom d'utilisateur     Mot de passe      Conserver       Mot de passe perdu ?  Inscription
Menu
Accueil
A propos du site
Carte du site
Moteur de recherche
Nouvelles
Contactez-nous
Evénements
- - - - - - -
Analyse
Conception
Optimisation
Programmation
Sécurité
Produits/Services
Dec 20 2005
Besoins en performance des sites B2C Version imprimable Suggérer par mail
Appréciation des utilisateurs: / 4
FaibleMeilleur 
Optimisation - Performance
Ecrit par Kamal AOUDA   
20-12-2005

A l’intérieur du modèle d’affaires B2C, nous ferons dorénavant la distinction entre deux types de sites :


• Les sites d’intermédiation financière.
• Les sites conventionnels de shopping (qui vendent au détail des produits/ services non financiers).

Les sites d’intermédiation financière sont visités à un rythme très intensif. Pendant les horaires d’ouverture des marchés les clients s’y connectent fréquemment pour suivre l’évolution des cours, effectuer des transactions, obtenir des nouvelles sectorielles et/ou télécharger des rapports d’activité. Le caractère volatile des données ainsi que la surveillance des organismes de réglementation exigent de ces sites un très grand taux de disponibilité et des temps de réponse hors du commun.



Les cas d’utilisation des sites d’intermédiation financière posent de véritables défis à l’équipe de développement parce que :

• Ils augmentent la demande pour les pages générées dynamiquement.
• Ils mettent beaucoup de pression sur la base de données.
• Ils font massivement appel aux services d’applications tierces (exemple : services web d’un système de compensation installé sur le main frame d’un tiers).

Les pages des sites d’intermédiation financière contiennent peu de graphismes [122]. Certains sont statiques (logo, image gif pour la navigation) mais la plupart sont générés à la volée sur la base des données personnalisées de chaque utilisateur (ce qui limite les possibilités de mise en cache).


Figure 18: Pattern du trafic quotidien sur un site d’intermédiation financière [123]

 

 

Les cours des titres, pour leur part, doivent être rafraîchis en temps réel afin de refléter la dynamique de l’offre et de la demande sur les marchés. Ce rafraîchissement épuise non seulement la base de données mais également les applications tierces qui fournissent leurs services au site. Les bulletins d’informations et les rapports d’activités offrent, néanmoins, plus de possibilités de mise en cache parce que leurs données ne sont pas rapidement périssables (dépendamment de la périodicité des bulletins et des rapports celles-ci ne changent pas aussi fréquemment que les cours des titres).

Les besoins en sécurité affectent également les performances des sites d’intermédiation financière. Outre l’obligation légale de garder des traces sur toutes les transactions effectuées ceux-ci échangent des données confidentielles [124] via des protocoles sécurisés (SSL, SET…). Comme le montre les figures 19 et 20 le recours à ces protocoles augmente le temps de réponse et ralentit le débit notamment en raison des encryptages de données et des vérifications qui doivent être effectuées auprès des organismes de certification (exemple : vérification des données d’un certificat numérique auprès de Verisign [125] ) .

Pour leur part, les sites de shopping présentent les mêmes caractéristiques que les sites d’intermédiation financière à la différence près que :

• Leurs pages retournent un nombre plus important d’images (sous forme de catalogues avec la possibilité d’agrandir ou de réduire la taille par effet de zoom).
• Les données qui servent à la génération des catalogues sont moins volatiles ce qui offre plus de possibilités de mise en cache.
• Le trafic, qui est plus prévisible, atteint son paroxysme pendant les périodes de fêtes et de liquidations (voir figure 21).
• L’activité des robots sur ces sites est beaucoup plus intensive.


Figure 19: Impact de l’utilisation du protocole TLS sur le débit d’une application d’e-commerce [126]

 

 

Figure 20: Variation du temps de réponse et du débit en fonction de la taille de la clé TLS [127]

 

 

 

Notes de bas de page

 

[122] Ces affirmations sont basées sur les résultats des travaux de Stacy Joines, Ruth Willenborg, Ken Hygh publiés dans le livre Performance Analysis for Java™ Web Sites, Addison Wesley, September 10, 2002, ISBN: 0-201-84454-0
[123] Source: Stacy Joines, Ruth Willenborg, Ken Hygh, Performance Analysis for Java™ Web Sites, Addison Wesley, September 10, 2002, ISBN: 0-201-84454-0, pages 464
[124] Numéro de carte de crédit. Numéro de compte. Identité des clients….
[125] Clé publique, date d’expiration…
 

Dernière mise à jour : ( 20-12-2005 )
< Précédent   Suivant >
Benchmarks de performance

Les benchmarks de Keynote Systems sont conçus pour permettre aux entreprises de comparer la performance de leurs sites de commerce électronique avec celle de leurs principaux concurrents. Au-delà d’une simple mesure des indicateurs traditionnels comme le débit et le temps de réponse, les benchmarks de Keynote tiennent compte des cas d’utilisation et des contraintes sectorielles. Pour plus d’informations sur les benchmarks de Keynote, leur méthodologie et leur utilité, consulter les articles suivants :


 

* Keynote Index : benchmarking des performances des sites E-commerce.

* Perception de la performance par les utilisateurs, le temps de réponse.

 

 

Cliquer sur ce lien pour voir les résultats du mois de décembre 2005: 

 

Hébergement PHP, Mambo, MySQL
Web hosting services
Moteur de recherche
Recommander ce site
Collaboration
Téléchargements
Derniers événements
Aucun événement
Sondages

Temps de réponse tolérable pour afficher la page d’accueil d’un site e-commerce

  
Blogs Ecommerce
Blog de capitaine commerce
top

Ce site a été crée avec le CMS Mambo. Un logiciel gratuit disponible sous licence GPL.

Copyright Ecommerce DEV 2006.

Hosted by SiteGround