Jump to content

Recommended Posts

Bonjour,

 

Aprés mes testes de charge:

http://www.first-wor...op-en-2012.html

J'ai mon prestashop qui ce charge en 111ms sur un serveur correcte. Alors que plein de modules sont désactivé.

 

Juste une optimisation somaire pour étre < 30ms serai sympa, sachant que j'ai plein de modules désativé (dons les stats).

 

Les serveurs de média ne sont pas utilisé pour les images dans les modules, ni les css.

 

Et comme je le disait, désyncronisé les stats et données dynamique permet de faire un affichage rapide sur les pages.

Notez aussi que l'activation des caches ralenti le site.

 

J'ai bien lu (et ce qui est logique), que le gros des optimisations arrivera aprés.

Si besoin, je peu aider (j'ai pas mal d'expérience dans l'optimisation php ou C ;) ), et conseiller coté cache.

 

Merci d'avance.

  • Like 1
Link to comment
Share on other sites

Bonjour,

je trouve dommage dans l'article qu'il ne soit pas mis en avant que la version 1.5 est actuellement en BETA, ça fait assez mauvaise pub gratuite. Nous sommes conscient des problèmes actuels sur les performances de la version 1.5, et il est bien sur prévu de faire une grosse passe sur les performances de cette dernière. Merci tout de même pour les benchs qui nous aideront à concentrer nos efforts là où il faut ;)

 

Cordialement

Link to comment
Share on other sites

Salut,

 

Merci pour le retour.

  • CCC

Le but de CCC est de réduire le temps de chargement de la page (moins de requetes HTTP et fichiers concaténés et minifiés).

Il y a effectivement une perte au niveau CPU, mais relativement minime du fait qu'a chaque chargement on verifie que les fichiers JS et CSS n'ont pas été modifiés.

Le fichier de 150Ko est envoyé à la premiere requete puis mis en cache navigateurs par les suivantes.

  • Stats

En soit rien d'anormal, on stock enormément de données sur toutes les connexions et pages visitées.

Pour les sites à forte affluence on recommande de désactiver les statistiques et l'utilisation de Google Analytics.

  • Cache

Optional features: désativé ça n’augemente pas les performances comme il dise, ça les diminues.

Ca me parrait peu probable, quand une feature est désactivée des gros blocs de traitements ne sont plus executés.

Media servers (use only with CCC)

Je n'ai pas bien compris ta remarque. Le media serveur accelere le chargement de page en permettant de faire plus de requetes HTTP en simultannées.

 

Comparer Wordpress à Prestashop n'est à mon avis pas pertinent, PrestaShop ayant de base beaucoup plus de fonctionnalités.

 

Comme tu l'as fait sur le forum, je pense aussi qu'il serait bien de préciser dans l'article que tu te bases sur une version 1.5 Beta ;) On a des choses à améliorer, on y travaille.

  • Like 3
Link to comment
Share on other sites

Le fichier de 150Ko est envoyé à la premiere requete puis mis en cache navigateurs par les suivantes.

Hélas non, c'est ce que je note comme critique principale, c'est 150Ko à chaque page utilisant une template différente (css ou js différent). Au lieux de 130Ko de base commune et 20Ko quand la template change. Avec la connexion 512K que j'ai ça ce ressent. Avec CCC ça fait 3x150Ko=450Ko en visitant 3 page différente, et 130+20x3=190Ko sans CCC. Facilement vériable en regardant la taille des fichiers chargé par le navigateur.

 

En soit rien d'anormal, on stock enormément de données sur toutes les connexions et pages visitées.

Pour les sites à forte affluence on recommande de désactiver les statistiques et l'utilisation de Google Analytics.

Asyncronisé les appelles en ajax permettrai d'augementé la réativité du site avec le module de stat par défault. Ici mon probléme c'est que plein de gens laisse les trucs par défault, et rajoute les modules pour leur besoins. Hélas sur la page principal d'optimisation ce n'est pas mentionné:

http://www.prestashop.com/en/top-tips

 

Ca me parrait peu probable, quand une feature est désactivée des gros blocs de traitements ne sont plus executés.

Ca c'est ce que ça veux dire, mais suffit que pour une raison inconnu l'accés au cache est plus lent que la génération de la donnée, souvent due au vérif si le cache est à jour (ces vérif ne doivent pas étre fait à l'accéss, mais le cache doit étre regénéré lors du maj de la template, de l'info en question, et sur l'admin)

 

Je n'ai pas bien compris ta remarque. Le media serveur accelere le chargement de page en permettant de faire plus de requetes HTTP en simultannées.

Corrigé, ici je disait que sans CCC, soit avec plein de fichiers, une gagne fortement sur l'upload (coté entéte http)

 

Comparer Wordpress à Prestashop n'est à mon avis pas pertinent, PrestaShop ayant de base beaucoup plus de fonctionnalités.

C'été pour comparer avec ce que les gens connaisses, ici c'est la vitesse d’exécution vis à vis d'autre site en php. Comme dit dans prestashop je sais plus ou, c'est un compris fonctionnalités/performances. Et ont peu avoir les 2. Certain site peuvent avoir plus de fonctionnalité de prestashop et étre + rapide, ou moins de fonctionnalité et plus lente. Tout dépend de l'implémentation et non pas des fonctionnalités.

 

Comme tu l'as fait sur le forum, je pense aussi qu'il serait bien de préciser dans l'article que tu te bases sur une version 1.5 Beta ;) On a des choses à améliorer, on y travaille.

J'ai corrigé dans l'article. ;)

Link to comment
Share on other sites

J'ai maj l'article, j'ai développé la raison de la perte avec CCC (lien wiki), j'ai clarifié l'article.

Une minimisation du html avant la mise en cache smarty, et des css/jss comme fait avec CCC mais sans CCC (accés à des fichiers statiques) serai un plus.

 

J'ai aussi noté des pertes de performance lors de l'activation du cache avec la version stable.

 

EDIT: Directement les utilisateurs m'ont demander ce qu'été l'addresse de livraison pour des biens virtuels. C'est vrai que ça peu étre génant. Alors j'ai fait ça:

http://files.first-w...er-carrier.diff

Je suis pas sur du code smarty que j'ai écrit, histoire de masquer les textes pouvant perturber l'utilisateur pour l'achat un panier virtuel.

Link to comment
Share on other sites

En passant, je n'est pas mit dans l'article car ça n'as rien à faire la. Mais un outils de benchmark automatique pour tracker les régressions serai utile. Histoire de voir les commits qui font plus de 10% de perte de performance. Avec le teste avec/sans cache, ...

 

C'est ce qui est utilisé par un certain nombre de logiciel et même le noyau linux pour tracker les régressions de performance.

Link to comment
Share on other sites

Nous n'avons pas réellement de tests unitaires en interne, il s'agit plutôt de tests séléniums qui sont mis en place petit à petit afin de nous aider à plus facilement identifier les bugs éventuels lors de commits, l'architecture du logiciel se prête malheureusement actuellement peu aux tests unitaires.

Link to comment
Share on other sites

l'architecture du logiciel se prête malheureusement actuellement peu aux tests unitaires.

 

C'est le moins qu'on puisse dire ! Tous les modèles objet sont construits par "constructor injection", c'est un belle balle dans le pied.

 

Mais bon vous pouvez quand même créer des tests unitaire pour beaucoup de choses, genre des méthodes statiques qui ne font pas d'accès à la base de données.

 

Je me demande comment vous avez pu sérieusement faire PrestaShop 1.5 sans tests unitaires pour les régressions... c'est un travail empirique

Link to comment
Share on other sites

  • 1 month later...

Rien que tester si l'installation marche, le processus d'achat, les produits par défaut (et peu étre quelque variantes, ...).

 

J'ai vu le gain de performance de la 1.5.0.13, rien d’extraordinaire, mais c'est toujours ça de pris.

Je vais poster sur la forge pour avoir plus de réponse.

Link to comment
Share on other sites

Salut,

 

alpha one tu as quoi comme config hardware serveur ?

 

moi avec un 2,6Ghz 2gb ram, je suis coulé sur la 1.4 avec la compile php, et le cache et la 1.3 fonctionne comme une rocket !

 

j'ai noté aussi une perte de CPU non négligeable sur l'activation CCC ! surtout JS

Link to comment
Share on other sites

Salut,

 

alpha one tu as quoi comme config hardware serveur ?

 

moi avec un 2,6Ghz 2gb ram, je suis coulé sur la 1.4 avec la compile php, et le cache et la 1.3 fonctionne comme une rocket !

 

j'ai noté aussi une perte de CPU non négligeable sur l'activation CCC ! surtout JS

 

Pour le CCC c'est normal, c'est l’inconvénient, ça demande du CPU pour minifier et concaténer les ressources.

Link to comment
Share on other sites

Normalement la minification devrai étre caché, en dur pour le js/css, et dans un cache template pour la template. Moi j'utilise (voir post en 1ere page), core i5 750, 8Go DDR3, prestashop. Mais ici je ne perds que 20~40% de performance (déjà pas mal).

Link to comment
Share on other sites

oui il la régénère à chaque appel ?

 

Après un décorticage du debug la fonction qui appel les produits détails (je ne sais plus le nom exact) me coute de 10 à 100 ms par produit.

 

je me demande si je vais pas passer en dédié, mais juste pour passer sur la 1.4 et son code plus lourd que la 1.3 ça me fait mal !

La 1.5 ne sera pas mieux je pense? Je voulais essayer la bêta, mais elle n'est pas encore optimisé apparemment .

Link to comment
Share on other sites

Oui, si non ça n'induirai pas de charge supplémentaire.

 

Mois +100ms tout le temps (voir http://www.first-wor...op-en-2012.html et http://www.first-wor...prestashop.html).

 

Ici la 1.4 est tout aussi lourde que la 1.5. Après c'est optimisable (désactivation des stat -> remplacé par google analitics, ... voir mon post). Par contre oui, en générale, les dédiés sont largement plus rapide que les mutualisés.

 

EDIT: Mais la 1.5 ne semble pas plus lourd que la 1.4.

Edited by alpha_one_x86 (see edit history)
Link to comment
Share on other sites

Les stats sont désactivés depuis longtemps.

Les fonctions les plus terribles selon mon profiler php sont JS compile, Statistic et Cart.php

J'ai donc viré CCC js, statistiques désactivés, et cart.php on peut pas faire grand chose si ce n'est le passer en static et non ajax pour le test.

 

Je pensais que c'était le serveur SQL au début, mais non il tourne bien et le load server est à 0,4 constant

 

Voici mon interprétation avec Xdebug :

 

c'est la fonction ProductCore::getProductProperties()

appel > ProductCore::getPriceStatic()

appel> ProductCore::priceCalculation()

 

Qui me prends presque 1sec en tout, dépends du nombre de produits sur la page. ca me fais mouliner mon CPU

Sur la 1.3 elle est moins structuré au niveau du code, ça se voit clairement dans le debug, mais elle calcul beaucoup moins de fonctions

 

Je vais investiguer du côté de l'hébergeur

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...