Nextcoin market place

Bonjour,

La version 1.3.4 est plus accessible que jamais au commun des mortels. Ce qui confirme que cet ebay décentralisé est l’avenir pour moi des ecommerces. Au revoir prestashop, magento… Et vous y voyez, CatchChallenger en version Ultimate.

Les prix sont trés bas car il n’y as plus de tiers de confiance, plus d’intermédiaire, et le système est performant et optimisé.

Les captures d’écran parle d’elle même:

nextcoin market place 1.3.4
nextcoin market place 1.3.4

nextcoin-market-place

Optimisation prestashop en 2012

Bonjour, pour ultracopier j’ai ouvert ma boutique en ligne, avec prestashop 1.5 (Version Beta en développement):

http://ultracopier-shop.first-world.info/ pour vendre Ultracopier ultimate

Suite à ça je me suis attaqué aux performances, voila les conclusions:

  1. Le CCC cache conseillé par prestashop est à désactiver +40% de performance, -20% de temps de chargement (voir Theoretical_css_grouping_on_site_web pour plus de détails)
    • Raison: Car le CCC cache compresse le contenu de la page en échange d’énorme temps cpu (car il doit lire la syntaxe des fichiers), hors cela oblige de passer tout les fichiers par du php (perte de perf + blocage lors des accés concurrents), le gain en taille brute dans le thémes par défaut est mois de 10%. De plus grouper tout les js permet une meilleure compression, mais oblige à charger tout le groupe à chaque fois, donc on télécharge 150Ko à chaque page différentes au lieu de télécharger 2Ko des seuls fichiers js qui sont spécifique à la page (mauvaise utilisation du cache navigateur)
    • Example: Visite sur la page home, la catégorie, le produit, le payement: Avec CCC 4x150Ko=600Ko de chargé, sans CCC 148Ko+2Ko*4=156Ko
    • Solution: Compresser manuellement les fichiers, la compression html devrai étre avant la mise en cache, pour en pas recalculer la même chose à chaque fois. Il ne faut pas voir le gain sur une page, mais dans la navigation générale du site.
  2. Les statistiques dans prestashop sont à désactiver -50% de temps de chargement
    • Raison: Tout les logiciels de statistiques prennent du temps de calcule, dans le cas de prestashop, ces temps sont ajouté au temps de la page, dans un outils comme google analitics ou piwik, ces temps sont mis en arriére plan car il sont appellé aprés le changement de la page en arriére plan. De plus, il font des écritures constantes, ce qui anule la plus part des caches dans le systéme et dans mysql.
    • Solution: Temporaire: désactivé les stats dans prestashop et activé des stat google analitic ou piwik, Finale: désyncroniser les taches annexe tel que le tracking visiteur pour ne pas ralentir le corps de page
  3. Les caches dans prestashop sont à activer partiellement +30% de performance
    • Caches:
      • Smarty: cache + Compile cache if templates are updated, activé ça diminue les performances
      • Optional features: désativé ça n’augemente pas les performances, ça les diminues. Laissez les actifs.
      • CCC (Combine, Compress and Cache): Désactivé, voir le point 1), par contre la minimisation du js/css devrai être quand même faite, et prestashop la font de façon correcte (compression puis accès à un fichier statique).
      • Apache optimization: Désactivé (à réglé proprement sur apache pour avoir tout les sites du serveur bien réglé, et ne pas faire 2x la même chose), déjà fait chez les bons hébergeurs. Il mettent Etag à none, hors désactivé le module est mieux, mais à cause du non chargement du module la directive fait une erreur 500
      • Media servers (use only with CCC): à activer, cela permet sur supprimé 2Ko par fichiers et en upload! (pas de cookie, vu le nombre de fichiers c’est intéréssant de l’activé sans CCC, ça fait 50% de la taille de l’upload), par contre il ne met pas tout les medias sur les serveurs de médias.
      • Caching: -40% de performance si activé, quelque soit l’endroit où est le cache (File system, ram disk, memcached, APC, …)
    • Raison: Les caches sont pire que sans cache si il sont mal géré ou buggé, ici c’est le cas
    • Solution: Corrigé proprement les caches, leurs syncronisation et implication.

Prestashop est un bon utilitaire, cepandant: les performances ne sont pas là (wordpress qui est lent, est plus rapide), les caches font perdre en performance au lieux de faire un gain. Les conseilles sont faux et il n’explique pas ce que ça implique.

Voila des exemples de performance sur mon serveur:

  • WordPress: Requests per second:    425.22 [#/sec]
  • Prestashop: Requests per second:    33.99 [#/sec]
  • Site php pur sans aucun cache + bibliotéque php rapide + tout d’un site web (rewrite rules, …): Requests per second:    5127.05 [#/sec]
  • Site avec un cache html pur type http://www.calle-hardware.com/: Requests per second:    32954.36 [#/sec], ce genre de site est facilement fait, et n’oublige pas d’avoir des pages statiques mis en cache coté navigateur
Gestion de cache possible
Des meilleurs performances serai idée pour un meilleur confort de navigation. Pour minimiser les frais d’hébergement. Et pour maximiser le nombre de visiteurs lors d’aflux masif (newsletter, projet populaire, …).
Les ratios visites/achat sont en générale: beaucoup de vistes pour peu d’achat, soit beaucoup de lecture de page, pour peu de modification de page (si sont affiche par exemple l’état du stock, il change à chaque achat). En plus on ne peu utiliser aucun reverse proxy pour prestashop car il faudrai qu’il asyncronise les données dynamiques, cela permettrai aussi de faire un affichage réactif car ça afficherai directement la page, et les trackings des visiteurs, obtentions des données de session (panier, nom du visiteur, …) serai chargé en différé sans géné la navigation.
Gestion de la bande passante
Je note aussi que dans les pays riches les connexions sont rapide, alors + la compression gzip d’apache, la page html (avec html bien formaté) reviens à 5Ko, soit 0.001s en france (avec du 500Ko/s pratique soit 5Mega), et 0.1s en dans un pays pauvre telque la bolivie. Donc les temps de chargements de pages de plus de 30ms sont trés important en comparaison du temps de téléchargement de la page. Donc arrété d’essayer d’optimiser le poids de la page en dépis des performances. Surtout que le poids viens surtout des images.
Configuration de teste
Teste prestashop fait sur: http://ultracopier-shop.first-world.info
Commande pour tester les sites:
ab -k -r -c 100 -n 1000 http://www.site.com/en/
Les performances de php 5.2 avec apc sont les mêmes que php 5.4 sans apc (sauf que pour php 5.4 il y as moins de mémoire utilisé, donc ça évite de swapper et de ralentir le hdd pour la monté en charge).
Serveur ovh SP SSD, Intel Core i5-240016 Go DDR3, avec ramdisk (tmpfs), ext4 nobarrier, kernel 3.1.
La version de prestashop utilisé: 1.5.0.9 (Version Beta en développement).
Utilisation des ressources
Teste fait sur un serveur de production, réglé pour la production. Mysql avec cache et buffer. Cpu: 3.5% pour mysql, 80.5% pour php, 16% de temps système, 0% de temps wa -> hdd).
Pourquoi tant de temps systéme??? Que fait t’il pour faire autant d’appelle au noyau?
Les appelles systèmes sont lent car il faut faire le lien entre l’espace noyau et l’espace utilisateur, et en espace noyau, certaines ressources bloque la monté en charge car une seul thread peu y accéder.
La commande ab est lancé sur le même serveur pour ne pas avoir de limitation de bande passante, elle ne peu étre responsable des temps systéme vu qu’elle n’utilise pas intensivement la couche réseau (quelque dizaine de requetes secondes)
Profiling du prestashop

Détails de ce qui prends du temps:

Context::getContext()->shop = Shop::initialize(); 11ms
Shop::setContext(Shop::CONTEXT_SHOP, Context::getContext()->shop->id); 3ms devrai étre 0ms
Configuration::loadConfiguration(); 3ms
require_once(dirname(__FILE__).'/smarty.config.inc.php'); 13ms
Dispatcher::getInstance()->dispatch(); 76ms
Autre cumulé: 5ms

Temps rajouté par l’activation du cache:

50ms par l'activation du cache smarty, le temps est rajouté à Dispatcher::getInstance()->dispatch();
20ms par l'activation du cache normal dans settings.inc.php dans divers partie du code