Conseils

14
janvier
2015

Au cours des derniers jours, de nombreuses attaques ont été constatées sur internet. Sur le seul week-end du 10 janvier, plus de 1200 attaques ont notamment été recensées.

Suite à une réunion ministérielle effectuée en présence des FSSI et RSSI, une forte menace pèse sur la journée du 15 janvier. Cette menace concerne principalement sur les site en .fr tels que les sites institutionnels, sites de municipalités, cliniques, collèges…

attaques-web-2015

Deux sortes d’attaques sont à craindre :

  • Défiguration de site avec message haineux (le plus constaté pour l’instant)
  • Attaque par déni de service

Nous vous invitons donc à procéder à une veille attentive sur vos sites afin d’être en mesure de réagir rapidement. En cas d’attaque, vous pouvez alerter rapidement votre brigade de gendarmerie locale.

Pour rappel, l’utilisation d’un mot de passe fort est préconisée, en particulier pour les applications type Twitter.

07
novembre
2014

Si vous travaillez dans une webagency, vous savez à quel point les journées peuvent être chargées, entre la gestion de projet, la création et le développement des sites, les rendez-vous clients, les démarches commerciales et administratives…

Un rythme de travail qui laisse peu de temps pour s’occuper aussi de l’hébergement des sites de vos clients, d’autant que cela demande certaines compétences techniques pas toujours présentes au sein des agences digitales.

Conscients que l’hébergement est un point sensible pour les agences web, nous avons construit nos offres autour de services spécialement adaptés aux agences, permettant de se libérer des contraintes liées à l’hébergement.

hebergement-web-agency 

Infogérance

La meilleure façon de vous concentrer sur vos projets est de déléguer la gestion de votre serveur. Chez Celeonet, nous vous proposons des forfaits d’infogérance qui vous apportent ainsi de la tranquillité et de la sérénité : nous gérons l’intégralité de votre serveur.

 

Sécurité & sauvegardes

Quoi de pire que de perdre une journée de travail à cause de données perdues (et donc, non sauvegardées !) sur le site d’un client ? Pour éviter ce type de désagrément, les services que nous vous fournissons sont monitorés 24h/24, 7j/7. En plus, vous ne risquez pas de perdre vos données car elles sont sauvegardées quotidiennement sur un serveur NAS distant.

Au fait, sur les 12 derniers mois, notre réseau a été disponible à 100% !

 

Support

Nous avons à coeur de proposer une qualité de service irréprochable, et cela passe nécessairement par un support disponible et réactif. En travaillant avec nous, vous bénéficiez d’un interlocuteur unique, qui est là pour vous aider et répondre à toutes vos questions.

En cas de souci, nous garantissons un temps d’intervention d’1 heure et un temps de rétablissement de 4 heures. Bref, l’hébergement des sites internet de vos clients n’est plus un problème puisque le suivi et les interventions nous incombent.

 

Autonomie

Parce que chaque client est différent, nous mettons à votre disposition une plate-forme d’hébergement adaptée à votre projet (site internet, application…). Ainsi, vous bénéficiez d’une configuration spécifique, à partir de laquelle vous pouvez gérer les tâches courantes (accès FTP, bases SQL…), en fonction des scripts et CMS que vous utilisez.

Résultat : vous gardez de la souplesse et de l’autonomie, avec une solution qui répond aux besoins de vos clients.

 

Pour en savoir plus…

Agences Web, l’hébergement des sites de vos clients ne devrait plus être un souci.

Si vous êtes confrontés à une problématique liée à l’hébergement des sites de vos clients, nous avons certainement une réponse à vous apporter. Serveur dédié infogéré, hébergement cloud : nos solutions – en permettant un gain de temps, d’autonomie et de sécurité – mettront un terme définitif à vos craintes (notamment techniques) et optimiseront vos coûts.

N’hésitez pas à prendre contact avec nous pour faire le point sur vos besoins et votre projet !

12
mai
2014
Attention, mail de Phishing.

Publié par Celeonet, Il y a 3 années | Conseils

Si vous avez créé un nom de domaine en .fr depuis le 1er janvier 2014, vous risquez de recevoir un mail de Phishing. Cet email ne provient pas de nos services, nous vous demandons donc de ne pas en tenir compte.

La mail en question est envoyé par contact@monsiteen48h.com et a comme sujet « Il gagne 28 834€ par mois avec son blog, posez lui vos qestions en direct ce week-end ».

Il s’agit bien-entendu d’une escroquerie et la mention « Vous recevez cet email car vous avez souscrit aux services de CELEONET SAS. »  est totalement abusive et infondée.

Nous vous invitons à le supprimer sans y répondre, il est également important de ne cliquer sur aucun lien, y compris le lien de désinscription.

Bonjour XXXX XXXX,

Vous recevez cet email car vous avez souscrit aux services de CELEONET SAS. Si vous n’avez pas souscrit au service de CELEONET SAS et que cet email est indésirable, vous pouvez le signaler comme spam en cliquant ici

Un bloggueur organise ce dimanche soir à 18H00 une conférence dans laquelle il dévoile TOUT : sa méthode, ses outils, ses techniques, et comment vous pouvez les utiliser pour vous aussi gagner de l’argent avec celeo-preprod.fr.

C’est gratuit, c’est en direct, et vous pourrez poser toutes vos questions :

=>INSCRIVEZ-VOUS gratuitement à cet évènement

Durant la conférence, il vous dévoilera:

  • Comment gagner de l’argent sur Internet avec un blog
  • Comment bien choisir le sujet de son blog… et comment être sûr qu’il s’agit d’un domaine qui rapporte
  • Comment faire en sorte que votre blog travaille pour vous… plutôt que l’inverse
  • Les 3 ingrédients indispensables pour faire de votre blog
    une réussite
  • L’outil indispensable qui fait LA différence entre 300 euros
    par mois et 3000 euros par mois et que 95% des blogueurs ne connaissent pas
  • La MEILLEURE source de revenus possible pour un blog
  • Comment gagner l’équivalent d’un an de chiffre d’affaire…
    en quelques jours
    , la méthode

Tout est là :
=>28 843,75 euros par mois avec un simple blog, la conférence
Patrice,

PS: l’enregistrement de cette conférence sera vendu 97€ d’ici quelques jours, une raison de plus de ne pas manquer ce live GRATUIT

 Se désinscrire de cette liste

 

07
mars
2013

Logo-MagentoSuite et fin de notre dossier Magento : nous avons abordé dans l’article précédent l’optimisation d’une montée en charge d’un site E-Commerce utilisant Magento. Nous allons à présent nous intéresser à sa montée en charge dont le suivi est trop souvent négligé lors de la mise en place d’optimisations.

•••

Les tests

Attention : les tests et leurs résultats ne valent que pour la configuration matérielle ici déployée. Elle a été décrite avec la méthodologie de test dans le second volet de ce dossier, « Dossier Magento – 2 : Optimiser les temps de génération des pages ».

Les tests d’optimisation ne sont à ce stade valides que si le système n’est accédé que par un seul internaute sur des pages identiques. Cette situation est très éloignée de l’utilisation normale d’un système en production.

JMeter n’est pas un navigateur web : la mise en cache côté client ainsi que la compression des éléments statiques sont sans effet sur son fonctionnement.

Toutes les 10 secondes, un nouvel utilisateur est simulé dans la limite de 100 utilisateurs :
   •  22 h 06 min 30 s : 0 utilisateur,
   •  22 h 22 min 10 s : 100 utilisateurs.

Les graphiques des temps de génération des pages web

Temps de réponse de la page d’index

1
Axe des abscisses : temps du test, une graduation équivaut à 20 secondes.
Axe des ordonnés : temps de génération des pages en millisecondes.

Temps de réponse d’une fiche produit

1
Axe des abscisses : temps du test, une graduation équivaut à 20 secondes.
Axe des ordonnés : temps de génération des pages en millisecondes.

Temps de réponse de la page de recherche

1
Axe des abscisses : temps du test, une graduation équivaut à 20 secondes.
Axe des ordonnés : temps de génération des pages en millisecondes.

Temps de réponse d’une catégorie

1
Axe des abscisses : temps du test, une graduation équivaut à 20 secondes.
Axe des ordonnés : temps de génération des pages en millisecondes.

Analyse des graphes

Les graphiques des temps de génération des pages web présentent des similitudes intéressantes.

Les temps de génération des pages web diminuent durant 50 secondes (5 utilisateurs simultanées, 50 pages générés), puis se stabilisent pendant 1 minute et 10 secondes (12 utilisateurs simultanés, 120 pages générées), et enfin augmentent régulièrement jusqu’à atteindre 100 utilisateurs simultanés et 1000 pages générées à 22 h 22 min 10 s.

En parallèle, nous avons constaté que 4 minutes après le début du test, les 24 cœurs de processeur (12 émulés) étaient actifs (24 utilisateurs). La charge CPU était à 100% après 5 minutes et 30 secondes. La baisse du temps de génération s’explique par la mise en cache des éléments du site internet, elle impacte directement la vitesse d’accès. Tant que tous les cœurs du serveur ne sont pas utilisés, le temps de génération reste stable. Une fois que tous les cœurs sont utilisés, le temps de génération augmente régulièrement.

La machine ne subit pas d’emballement, c’est-à-dire d’augmentation exponentielle du temps de génération en fonction du nombre de clients. Le temps de génération des pages est directement lié aux nombres de visiteurs une fois les processeurs saturés.

Trouver les limites

Le test suivant vise à déterminer la limite du serveur, c’est-à-dire le moment à partir duquel ce dernier affiche une erreur plutôt qu’une page web. Pour cela un nouvel internaute sera simulé toutes les secondes jusqu’au 10 000e.
Le paramètre max_connections de MySQL est fixé à une valeur de 1 000 afin qu’une saturation du nombre de connexions ne soit pas la source du non affichage de pages.

1

  • À 427 utilisateurs simultanés et 4270 pages appelées, la page « Produit » s’affiche en 17,67 secondes, le serveur a une charge à 5 minutes de 253,03,
  • À 593 utilisateurs simultanés et 5930 pages appelées, la page « Produit » s’affiche en 20,13 secondes, le serveur a une charge à 5 minutes de 252,23. La faible évolution de la charge indique que le serveur a atteint les limites de ses capacités de calcul. Ceci ne se traduit pas par un plantage du serveur ou du site mais par une grande lenteur d’accès,
  • À 740 utilisateurs simultanés et 7400 pages appelées, les différents éléments de la page commencent à s’afficher après 5 minutes,
  • À 1 000 utilisateurs simultanés, le nombre maximum de connexions aux bases de données est atteint et la page produit affiche une erreur.

L’arrêt du test provoque le réaffichage immédiat de la page produit.
En conclusion, il est possible de saturer le serveur de requêtes mais en aucun cas il n’est possible de provoquer un arrêt de son fonctionnement même en cas de très forte surcharge.
Le graphe de suivi permet de visualiser le « décrochage » du serveur, moment à partir duquel les temps de génération peuvent devenir aléatoires soit après 6 min 40 s, soit 400 internautes simultanées et 4000 pages appelées.

Conclusion

Magento est une boutique complète et bien conçue nécessitant d’importantes ressources. Il n’y a pas de recette miracle pour l’optimiser mais une série de solutions à implémenter ou non selon le serveur dont vous disposez. Il est donc primordial d’intégrer la contrainte de l’hébergement à la source du projet, cela vous permettra d’éviter des déconvenues techniques ou financières.

•••

Liens utiles
Liens internes :
Dossier Magento « Part. 1 : Les solutions d’hébergement »
Dossier Magento « Part. 2 : Optimiser les temps de génération des pages »
Dossier Magento « Part. 3 : Optimiser la montée en charge d’une boutique Magento »
Le DL 360 chez Celeonet : Celeo 360
Nos services d’ingénierie

Liens externes :
Le site de Magento
Le site d’Apache
Le site de MySQL

15
février
2013

Logo-MagentoNous avons abordé dans l’article précédent l’optimisation des temps de génération des pages web d’un site E-Commerce utilisant Magento. Nous allons maintenant nous intéresser à la montée en charge du serveur hébergeant Magento, c’est-à-dire comment obtenir les meilleurs temps d’accès possibles lorsque le site est visité par des internautes.

•••

La configuration matérielle déployée ainsi que la méthodologie de test ont été décrites dans « Dossier Magento – 2 : Optimiser les temps de génération des pages ».
Pour rappel, les optimisations réalisées en modifiant la configuration sur serveur sont indiquées par l’indication de (Serveur) dans le titre du test. Les optimisations réalisées en modifiant le fichier local.xml de Magento sont indiquées par l’indication de (Magento) dans le titre du test

Durée de vie de la cache (Magento)

Le fichier local.xml permet de spécifier la durée de vie de la cache. Sur le serveur de test, la durée de vie de la cache a été paramétrée à 86400s.

<lifetime>86400</lifetime>

Désactivation de l’auto-refresh (Magento)

Magento charge les éléments en cache à chaque accès, il est plus intéressant de maintenir en mémoire la cache. Ceci est paramétré via la directive suivante dans le local.xml.

<auto_refresh_fast_cache>0</auto_refresh_fast_cache>

Suppression de l’horodatage (Serveur)

Ce paramètre influe peu sur la vitesse d’écriture dans le cas qui nous concerne puisque nous disposons de disques SSD. Cependant, les partitions du serveur sont montées avec le paramètre « noatime » afin d’éviter que l’horodatage des fichiers soient modifiés à chaque accès disque.

Désactivation de la compression de la cache (Magento)

Notre serveur disposant de 32Go de mémoire dont 16 disponibles pour le RAMDISK, il n’est pas utile de compresser la cache Magento. Ce paramètre est donc désactivé afin que le script dispose de toute la puissance des processeurs.

<compression><![CDATA[0]]></compression>

Mise en cache des éléments statiques (Côté client)

Le mod Expires d’Apache permet de forcer la mise en cache des éléments statiques du site côté client. La fluidité de navigation s’en verra améliorée pour un internaute visitant le site et accédant plusieurs fois aux mêmes pages. Les valeurs spécifiées sont issues des spécifications Nitrogento.

ExpiresActive On
ExpiresDefault "access plus 1 year"
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
AddType image/x-icon .ico
ExpiresByType image/ico "access plus 1 year"
ExpiresByType image/icon "access plus 1 year"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresByType image/vnd.microsoft.icon "access plus 1 year"
ExpiresByType text/css "access plus 1 year"
ExpiresByType text/html "access plus 0 seconds"
ExpiresByType application/xhtml+xml "access plus 0 seconds"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType text/javascript "access plus 1 year"
ExpiresByType text/javascript "access plus 1 year"
ExpiresByType application/x-javascript "access plus 1 year"
ExpiresByType application/x-shockwave-flash "access plus 1 year"

Compression partielle des communications

Toujours via le .htaccess, certains contenus statiques sont compressés entre le serveur et le navigateur de l’internaute. Cette configuration n’impacte pas les temps d’accès dans le cadre de notre test (débits non limitatifs entre le serveur de test et la station de mesures).

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
Header append Vary User-Agent env=!dont-vary
AddOutputFilterByType DEFLATE text/css application/x-javascript
text/x-component text/html text/richtext image/svg+xml text/plain
text/xsd text/xsl text/xml image/x-icon<
FileETag MTime SizeCes

Mise en cache des éléments statiques (Serveur)

Si la mise en cache côté client fluidifie la navigation sur la boutique, elle présente un inconvénient majeur : l’internaute doit avoir déjà visité le site pour en bénéficier.

Sur un certain nombre de CMS (Magento, EZPublish…), il peut apparaître un phénomène de chargement long de la première page du site. Ceci s’explique par le temps nécessaire pour le calcul de la page d’accueil et la mise en cache côté client. Si l’internaute accède une nouvelle fois à la page, il ne constatera plus cette lenteur.

Si dans le mode multi-serveurs de Magento, le stockage d’un certain nombre d’éléments statiques en base de données impose l’utilisation d’un reverse proxy (ou accélérateur http). Dans le mode mono-serveur, son usage n’est pas un impératif mais le gain en termes de fluidité de navigation est important.

Le reverse proxy se place entre l’internaute et le serveur web, soit sur une machine dédiée, soit localement. Nous avons procédé à une installation locale, le reverse proxy écoute alors sur le port 80 et Apache sur le port 81. Cette spécificité est invisible pour l’internaute mais permet la mise en cache côté serveur de tous les éléments statiques du site. Les pages réécrites avec une extension de type htm ou html sont également interprétées comme un contenu statique. Un internaute qui accédera pour la première fois au site bénéficiera donc de tous les éléments mis en cache par le reverse du fait de visites précédentes d’autres internautes. Les pages s’affichent sans lenteur et sans décomposition des éléments.
Le reverse proxy est un élément important lors d’une montée en charge. Un élément statique accédé depuis la cache de squid nécessite moins de ressources que s’il était délivré par Apache.

Pour obtenir les meilleures performances, la cache de squid est stockée en RAMDISK et limitée à 1Go.

Tuning Apache et MySQL (Serveur)

Nous ne développerons pas sur les éléments de configuration d’Apache et de MySQL, le paramétrage effectué de base étant conforme aux spécifications Magento.
Ces spécifications s’appliquent à tout site internet de production, cependant il est à noter que si les bases de données s’avèrent volumineuses l’utilisation d’InnoDB est à préférer à MyISAM.

Apache

Timeout 120
Keepalive on
MaxKeepAliveRequests 100
KeepAliveTimeout 15
HostnameLookups Off
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 500
MaxClients 256

MySQL

Max_connections = 500
max_connect_errors = 1000000
Thread_concurrency = 8
Thread_cache_size = 32
Query_cache_size = 128M
Query_cache_limit = 2M
Sort_buffer_size = 8M
join_buffer_size = 8M
tmp_table_size = 64M
read_buffer_size = 2M
read_rnd_buffer_size = 16M
key_buffer = 32M
max_allowed_packet = 16M
max_heap_table_size = 64M
bulk_insert_buffer_size = 64M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 10G
myisam_max_extra_sort_file_size = 10G

À suivre – 4 : Test de montée en charge d’une boutique Magento

•••

Liens utiles
Liens internes :
Dossier Magento « Part. 1 : Les solutions d’hébergement »
Dossier Magento « Part. 2 : Optimiser les temps de génération des pages »
Le DL 360 chez Celeonet : Celeo 360
Nos services d’ingénierie

Liens externes :
Le site de Magento
Le site d’Apache
Le site de MySQL

04
février
2013

Logo-MagentoSuite du dossier Magento (Voir « 1 : Les solutions d’hébergement »)
Il existe de nombreux paramètres permettant d’optimiser l’affichage d’une boutique Magento. Cet article n’a pas pour objectif de fournir une recette miracle mais de vous donner une liste d’optimisations possibles qu’il vous faudra adapter en fonction des capacités du serveur sur lequel vous hébergez Magento.

•••

1. Les éléments du test

Lors de nos tests, nous avons fait un certain nombre de choix de configurations matérielles et logicielles. Le seul objectif était de nous placer dans la situation la plus favorable possible.

Configuration matérielle

360Magento est un script réputé gourmand en ressources systèmes.
Le serveur ayant permis la réalisation de ce test est un HP DL Proliant 360 G7. Nous le commercialisons sous le nom « Celeo 360 » dans une version  nommée « Performance ». Il est équipé de :

   • 32Go de mémoire ECC : Une partie sera utilisée pour accélérer les traitements de la cache logicielle (Magento) et système (Squid). Physiquement, les barrettes de mémoire sont installées par moitié dans les ranks dédiés à chaque processeur. Elles sont donc utilisées de manière optimale par les bus de chaque processeur.
   • 2 disques SSD Intel 520 de 180Go en RAID1 : Les disques SSD sont des mémoires flash non-volatiles. L’absence d’élément mécanique permet de disposer de capacités d’écriture et de lecture largement supérieures avec des temps d’accès très faibles (0.1ms).
   • 2 processeurs Xeon E5645 de 2.4Ghz (6 cœurs par processeur) : Le choix des processeurs est dicté par plusieurs impératifs. Schématiquement, un cœur va traiter une requête utilisateur : la cadence du processeur est donc importante et doit présenter le meilleur compromis cadence/coût. Le nombre de cœurs (12 physiques, 24 logiques) définit théoriquement le nombre maximum de processus simultanés. Le serveur dispose donc d’une importante capacité de calcul répartie de façon à servir dans les meilleures conditions de nombreux internautes.

Le script Magento

S’agissant d’un serveur unique et non d’une plateforme multi-serveurs, les éléments de cache, de session ou les images sont stockées au format « file », l’accès à un fichier étant beaucoup plus rapide qu’un accès à la base de données.
La dernière version stable de Magento a été utilisée (1.7.0.2). Afin de disposer d’un site proche d’une version de production, un jeu de test a été mis en place : les « Sample Data » fournies sur le site de Magento Commerce. Ils incluent 3 catégories d’articles, 120 produits (descriptions, photos), des pages statiques et un thème personnalisé.

Méthodologie

Afin d’obtenir des temps de générations stables et non corrélés à la performance ou à l’absence de performance du réseau d’un FAI :

   •  Les outils de mesure ont été installés sur un serveur de « base » (Processeur iCore3, 4Go de mémoire, disque dur SATA, OS Windows Server 2008),
   •  La station de mesures est installée dans le datacenter de Celeonet,
   •  Le serveur de test et la station de mesures sont connectés sur un réseau 1Gbs,
   •  Le serveur de test et la station de mesures sont connectés sur des switchs différents.

Seuls les temps de génération côté utilisateurs sont pris en compte et obtenus par l’intermédiaire du module Bugzilla de Firefox.

jmeter_logoLes montées en charge sont simulées par le logiciel « JMeter Apache » installé sur la station de mesures. Les graphes générés lors de ces tests sont fournis par le même outil. « JMeter » simule le comportement d’un nombre X d’internautes lorsqu’ils accèdent au site. Le logiciel a été paramétré de la façon suivante :

   •  Chaque internaute accède simultanément à 10 pages du site (l’index, trois catégories distinctes de produits, cinq produits distincts, une recherche de produit sur la base du mot clé « computer »),
   •  Un nouvel internaute se connecte toutes les 10 secondes dans la limite de 100 internautes,
   •  Une fois sa visite terminée, un internaute effectue de nouveau sans délai une nouvelle visite.

Ce mode de fonctionnement vise à stresser de façon intensive le serveur et ne reflète pas l’utilisation normale d’un internaute. Dans la pratique, un internaute ne visite pas 10 pages simultanément et ne réitère pas ses demandes à l’identique en quelques millisecondes. Le terme de visiteurs simultanés ne doit pas être considéré comme le nombre de visiteurs en ligne à un instant « t » sur un serveur en production.

2. Tests d’optimisation du temps de génération des pages

Les optimisations possibles sur Magento peuvent être classées en deux familles distinctes.
Les premières sont réalisées en modifiant la configuration sur serveur et seront indiquées par l’indication de (Serveur) dans le titre du test.
Les secondes sont réalisées en modifiant le fichier local.xml de Magento et seront indiquées par l’indication de (Magento) dans le titre du test

Temps de génération sans optimisation

Afin d’établir le gain de performance obtenu par les diverses optimisations, il est important de connaître les temps de génération des pages avant ces manipulations. Toutes les optimisations apportées sont cumulatives.

Page d’accueil : 703 ms
Article : 1,84 s
Connexion à l’admin : 3,34s

Mise en place de Memcached (Serveur) (Magento)

logo_memcachedMemcached a été installé sur le serveur et activé via le fichier local.xml. Dans une configuration mono-serveur, il aurait été possible de ne pas installer ce composant. En environnement multi-serveurs, son usage est impératif puisqu’il permet de partager les éléments mis en cache entre plusieurs serveurs.

Page d’accueil : 645 ms
Article : 1,08 s
Connexion à l’admin : 1,95s

Chargement du Backend en RAMDISK (Serveur)

Le serveur disposant de suffisamment de mémoire vive, les éléments de cache sont stockés en mémoire plutôt que sur le disque physique du serveur au format « file ».

Page d’accueil : 641 ms
Article : 1,13 s
Connexion à l’admin : 1,08s

Désactivation de l’écriture du cache dans le Slow Backend (Magento)

Le Slow backend est la partie la plus lente du cache. Via le fichier local.xml, on désactive l’écriture dans cette partie du cache. Ce paramétrage ne désactive pas le Slow backend.

Page d’accueil : 610 ms
Article : 1,05 s
Connexion à l’admin : 2,14 s

Gains obtenus

Ces différentes modifications impactent le temps de chargement des différentes pages de la boutique Magento. Les gains obtenus par rapport à une version sans optimisation sont les suivants :

Page d’accueil : 13%
Article : 43%
Connexion à l’admin : 36%

À suivre – 3 : Optimiser la montée en charge d’une boutique Magento

•••
Liens utiles
Liens internes :
Dossier Magento « Part. 1 : Les solutions d’hébergement »
Le DL 360 chez Celeonet : Celeo 360
Nos services d’ingénierie

Liens externes :
Le site de Magento 
Le module Bugzilla de Firefox
Le logiciel JMeter Apache
Le système de gestion de cache Memcached

29
janvier
2013
Dossier Magento – 1 : Les solutions d’hébergement

Publié par Celeonet, Il y a 5 années | Conseils

Logo-MagentoEn ce mois de janvier, nous voyons se multiplier les projets de Web boutique utilisant le CMS Magento, véritable référence dans le monde de l’E-Commerce. Son grand nombre de fonctionnalités et notamment sa facilité d’interfaçage avec des logiciels tiers de gestion de stock en font une solution particulièrement intéressante. Contrairement à d’autres CMS, comme par exemple Prestashop, il s’agit d’un script lourd. Même si Magento intègre deux niveaux de cache dans sa version communautaire (gratuite) et trois niveaux de cache dans sa version Enterprise (payante), vous serez déçu par la vitesse d’affichage de votre boutique en ligne si vous n’y apportez pas un certain nombre d’optimisations.
Nous avons réalisé en début d’année une étude technique sur Magento intégrant les optimisations les plus importantes ainsi que des tests de montée en charge. C’est cette étude que nous allons publier ici, sous la forme de quatre articles afin de vous donner toutes les informations qui vous permettront d’optimiser le temps de chargement de vos pages Magento.

•••

La solution d’hébergement doit être envisagée avant la mise en ligne de votre site marchand car elle en conditionnera l’évolution. La puissance nécessaire au bon fonctionnement de Magento ne doit pas être sous estimée ; une offre mutualisée ou virtuel/cloud n’est pas suffisante.
Magento préconise deux topologies distinctes pour héberger dans de bonnes conditions votre nouvel e-shop.

1. La solution mono-serveur

360La solution mono-serveur est la plus simple et la plus répandue : un serveur dédié est alors optimisé pour ce seul usage. Il vous faudra intégrer les impératifs suivants :

a. L’accès aux disques

Plus l’accès aux disques sera rapide, plus les systèmes de cache natifs de Magento seront efficaces. Magento préconise l’utilisation de quatre disques SAS 15000tm en RAID10, ils peuvent être avantageusement remplacés par deux disques SSD en miroir.

b. La vitesse d’affichage

La vitesse d’affichage de la boutique est conditionnée par la puissance des processeurs. Le nombre de visiteurs simultanés est lié au nombre de cœurs processeurs disponibles sur le serveur.
Lors de vos tests de mise en ligne, le temps de génération des pages dépendra de la cadence du processeur. Plus cette cadence sera élevée, plus l’affichage sera rapide.
Lors de la mise en production, il est souhaitable que plusieurs visiteurs simultanés accèdent à votre boutique. Schématiquement, tant que chaque visiteur dispose d’un cœur de processeur dédié pour afficher votre boutique, le temps de génération de vos pages sera identique à celui obtenu durant vos tests. Par exemple, sur un serveur disposant de 12 cœurs de processeurs, les performances de génération des pages seront optimales pour 12 visiteurs simultanés. (12 visiteurs simultanés étant 12 visiteurs appelant au même moment une page.) Dans les faits, le nombre de visiteurs de votre site peut être beaucoup plus important car les internautes vont passer un certain temps à consulter vos pages produits.
Si le nombre de pages générées simultanément est supérieur au nombre de cœurs processeurs disponibles, les temps de génération de vos pages augmentent.

c. La mémoire RAM

Durant nos tests de montée en charge, la mémoire n’a jamais été un paramètre bloquant. Le serveur HP utilisé disposait de 32Go de mémoire ECC DDR3 SDRAM cadencée à 10600 Mhz.
Si vous comptez utiliser un serveur qui n’est pas de constructeur (c’est-à-dire hors HP, Dell ou IBM), nous vous conseillons de vous enquérir de la qualité des composants et de la capacité de la carte mère du serveur à accéder rapidement à la mémoire. Ces deux détails s’avèreront en effet cruciaux.

La topologie mono-serveur sera à privilégier pour les « petites » Web Boutique. Le terme de « petite » est à nuancer, en effet HP propose aujourd’hui le Proliant DL585 G7 à un prix attractif équipé de 4 processeurs 12 cœurs, soit 48 cœurs de processeurs disponibles.

2. La solution Cluster

serveurs-clusterLa solution cluster, native dans Magento, est plus complexe. Elle est destinée aux gros sites e-commerce. Comparativement à la solution mono-serveur, son atout est sa capacité de calcul est évolutive par l’ajout de serveurs « à chaud » dans le cluster Magento. Il s’agit d’une infrastructure trois tiers, chaque niveau de traitement réalise une tâche spécifique.

1er niveau : les serveurs MySQL

Dans le mode cluster, l’unicité des données, c’est-à-dire le fait que chaque serveur web doit afficher les mêmes données au même moment, est un paramètre primordial. Magento a ainsi fait le choix de stocker tous les éléments variables en base de données, y compris les images présentes sur le site. L’affichage d’une image stockée dans une base de données est un processus extrêmement lent par rapport à un accès dit « fichier » (accès direct à l’image sur le disque dur). Ce problème sera réglé par le 3ème niveau de l’infrastructure.
Un serveur Maître MySQL a pour rôle de gérer les écritures en base de données (UPDATE, INSERT, etc.) et de répliquer ces modifications sur 1 à X serveurs esclaves qui ne seront accédés par Magento que pour les lectures (SELECT). Ce mode de fonctionnement est natif. Le script se chargera d’écrire et d’interroger les bons serveurs. MySQL, via la réplication Maître/Esclave(s), répliquera les données écrites sur le maître aux esclaves.

2ème niveau : les serveurs Web

Les serveurs web ont pour rôle de générer les pages web pour que l’internaute les visualise. Comme indiqué dans le chapitre précédent (voir « 1. La solution mono-serveur », ), dimensionner correctement les machines en fonction du nombre de visiteurs attendus est primordial. Cette fois, les données seront chargées depuis les serveurs MySQL et non pas depuis le disque dur local des serveurs. Dans cette topologie, vous pouvez ajouter autant de serveurs web que vous le souhaitez. Attention, si vous avez opté pour la version Magento Enterprise, vous devrez souscrire à une licence par serveur Web. Le coût d’une licence Enterprise n’ayant rien d’anecdotique, c’est un paramètre à prendre en compte.

3ème niveau : le reverse Proxy

Dans cette topologie, la présence d’un reverse proxy est indispensable. Il est placé entre l’internaute et l’infrastructure qui génère les pages web. Son objectif est de mettre en cache les éléments statiques tels que les css, les images, les pages html, etc. et de les délivrer aux internautes. Nous l’avons dit précédemment, accéder à une image stockée en base de données est un processus extrêmement lent. Grâce au reverse proxy, l’infrastructure web sera moins sollicitée et l’affichage de la boutique Magento sera beaucoup plus rapide.

À suivre – 2 : Optimiser les temps de génération des pages Magento

•••
Liens utiles
Liens internes :
Nos serveurs dédiés
Nos services d’ingénierie

Lien externe :
Le site de Magento 

12
novembre
2012
Garder vos coordonnées à jour

Publié par Celeonet, Il y a 5 années | Conseils

Vos informationsNous tenons à formuler aujourd’hui une petite alerte sur l’importance de bien conserver vos coordonnées à jour dans votre espace client.

Lors de l’ouverture d’un compte, nous demandons plusieurs informations :
1. Vos nom, prénom et adresse e-mail sont indispensables à la création de votre compte client,
2. Votre numéro de téléphone et vos coordonnées postales sont nécessaires à la création de votre facture,
3. Vos date et lieu de naissance si vous êtes un particulier, votre n° de SIREN ou autre référence permettant l’identification de votre société ou association si vous êtes une personne morale seront obligatoires pour déposer certains noms de domaine.

Il arrive que certaines de ces données évoluent avec le temps ; une modification d’adresse e-mail, un déménagement, un changement de statut… Pour des raisons logistiques et pour être en conformité avec les chartes validées lors de la mise à disposition de vos services, il est essentiel de bien penser à répercuter ces modifications dans votre espace client. En effet :

- La procédure de récupération de mot de passe ne peut être réalisée à tout moment que si votre adresse e-mail déclarée est toujours active. Si elle ne l’est plus, vous devrez contacter le service client qui devra s’assurer de votre identité avant de faire le nécessaire pour que vous retrouviez l’accès à votre compte.
– Les notifications de prochaine expiration de vos services, comme les communications importantes, ne sont envoyées qu’à l’adresse e-mail déclarée pour votre compte. Si elle n’est plus utilisée, nous ne pourrons pas être tenus pour responsable de la coupure de vos services ou des éventuelles modifications sur votre compte.
– Le titulaire d’un nom de domaine doit pouvoir être joignable et donc bien tenir à jour ses coordonnées. En cas de manquement à ce point, ou en cas de renseignements délibérément erronés et de non correction, les Registres se réservent le droit de procéder à l’annulation pure et simple du nom de domaine.

Nous vous conseillons vivement de vérifier la validité de vos informations et, le cas échéant, de les corriger depuis votre espace client, catégorie « Votre compte » puis « Vos informations » / « Votre adresse postale », ou depuis ce lien direct vers votre espace client (Connexion nécessaire).

Pour toute information, n’hésitez surtout pas à contacter notre service client ou notre support client (connexion nécessaire).
_______
Liens utiles
Liens internes :
Lien direct vers le module de mise à jour de vos informations dans l’interface client (connexion nécessaire)
L’article Sécuriser vos mots de passe sur ce blog
La rubrique FAQ de notre site

Liens externes :
Extensions françaises : La rubrique Charte de nommage de l’AFNIC
Extensions génériques  (.COM, etc.) : Accord d’accréditation mentionnant l’obligation de fiabilité des coordonnées d’un titulaire de nom de domaine par l’ICANN
Extension belge : Les conditions générales de DNS.BE

11
juillet
2012
L’erreur « Allowed memory limit »

Publié par Celeonet, Il y a 5 années | Conseils

PHPL’erreur « Allowed memory limit » apparaît lorsque l’opération demandée requiert plus de mémoire que le serveur ne peut en fournir. Pour corriger cela, il faut soit déterminer l’application qui demande de la mémoire afin de l’optimiser, soit augmenter l’espace mémoire. Lire la suite »

08
juin
2012
Sécuriser vos mots de passe

Publié par Yann [Celeonet], Il y a 5 années | Conseils

Un couple login / mot de passe a pour objectif de sécuriser l’accès à un service que vous utilisez ; le principe est de ne pas permettre  à un tiers non autorisé d’accéder à des fichiers ou à des fonctionnalités qui vous sont personnels. Lire la suite »