Ce que nous faisons · Données et web: Audits de performance d'applications web
Quand un site est lent, la réponse facile est « ajoutez des serveurs ». La nôtre est de mesurer chaque tier, de trouver la seule chose qui retient réellement les requêtes, et de la corriger, avec des chiffres avant et après. Souvent, les serveurs s'avèrent inoccupés et la cause se trouve là où personne ne regardait.
De quoi il s'agit
Une investigation structurée d'une application web lente ou instable, de l'extérieur vers l'intérieur. Vous recevez un rapport à notre identité qui nomme le tier à l'origine du problème (infrastructure, application ou tiers), montre les preuves pour chaque tier, et liste les correctifs par ordre de priorité. Là où le correctif nous revient, nous l'appliquons et mesurons à nouveau.
Nous couvrons WordPress, Magento, PrestaShop, Laravel et le PHP sur mesure, sur Linux ordinaire, Plesk et cPanel avec CloudLinux, derrière nginx, LiteSpeed ou Apache.
Comment nous le construisons
L'infrastructure d'abord, pour l'incriminer ou l'écarter. Nous prouvons si les serveurs sont occupés ou inoccupés pendant que les pages sont lentes. Si les CPU sont surtout inoccupés et que la base de données répond depuis la mémoire, ajouter du matériel n'aidera pas, et nous le disons.
Chronométrage de l'extérieur vers l'intérieur. Nous chronométrons les requêtes à travers le CDN, à l'edge et à l'origine, en cache et hors cache, pour savoir où passent les secondes avant de lire la moindre ligne de log.
PHP, par frame bloquante. Les slow logs de PHP-FPM sont regroupés par la fonction dans laquelle chaque requête lente était réellement coincée. Cela transforme « le site est lent » en « quarante pour cent du temps lent est un seul appel externe ».
La base de données, par les preuves. Slow query logs avec plans EXPLAIN, analyse des verrous et comportement du buffer pool. Nous dimensionnons le buffer pool InnoDB au working set, corrigeons les buffers par connexion réglés trop grands, et trouvons les requêtes non bornées et les parcours de table qui brûlent réellement du CPU.
Chaque dépendance externe. Passerelles de paiement, API d'ERP et de stock, serveurs de licences, polices et analytics : nous sondons chacune, parce qu'un appel synchrone vers un tiers lent bloque la page aussi sûrement qu'une requête lente.
Des correctifs qui tiennent. Des tailles de pool fixées d'après l'épuisement mesuré des workers, des délais de terminaison de requête et des plafonds mémoire pour qu'une seule forme de requête malheureuse ne puisse pas faire tomber le pool, et des limites de buffers nginx et Varnish qui correspondent aux vrais cookies et en-têtes.
Ce dont il vous protège
- Payer plus de matériel quand le matériel n'est pas le problème.
- Un seul réglage de base de données mal configuré qui transforme un serveur sain en incendie de CPU ou d'E/S de stockage.
- Des années de redémarrages planifiés tenant lieu de cause racine.
- Des paiements lents causés par un tiers dont vous ignoriez la présence sur le chemin de la requête.
- Des disputes entre hébergeur, développeurs et éditeurs sans aucune donnée sur la table.
En pratique
La boutique PrestaShop d'un détaillant d'articles de sport. Des milliers de requêtes par jour prenaient plus de quatre secondes pendant que les serveurs web restaient surtout inoccupés. Nous avons attribué environ 40 pour cent du temps lent à un appel de stock ERP synchrone au délai d'attente très long, 24 pour cent à des requêtes parcourant des millions de lignes, et 12 pour cent à la navigation à facettes. Le client a reçu un rapport à notre identité avec des preuves par tier et une liste de correctifs priorisée pour ses développeurs.
Pourquoi EuroVPS
- Nous mesurons avant de recommander, et nous mesurons à nouveau après le correctif.
- Nous lisons toute la stack : réseau, stockage, base de données, PHP, serveur web, CDN et tiers.
- Les rapports nomment une cause et un tier, avec des preuves sur lesquelles vos développeurs peuvent agir.
- Nous appliquons nous-mêmes le volet infrastructure du correctif, en sécurité et de façon réversible.
- Des conclusions honnêtes : si vos serveurs vont bien, nous vous le disons, même quand vendre du matériel serait plus facile.
Questions fréquentes
- Avez-vous besoin d'accéder à notre code ? Non. Nous travaillons à partir des logs serveur, base de données et accès, et du chronométrage extérieur. Si la cause est dans le code, nous pointons le plugin, l'endpoint ou la requête exacts.
- Pouvez-vous auditer un site hébergé ailleurs ? Oui, avec l'accès nécessaire pour lire les logs et les métriques. Beaucoup d'audits se terminent par une migration ; certains n'en ont pas besoin.
- Combien de temps prend un audit ? Beaucoup de causes sont trouvées en quelques heures. Un rapport complet avec chaque tier mesuré prend généralement quelques jours, selon le caractère intermittent du problème.
- Changerez-vous quelque chose sans demander ? Non. Chaque changement est convenu, appliqué avec un chemin de rollback, et mesuré.
- Que recevons-nous ? Un rapport à notre identité avec les mesures, le tier à l'origine du problème, et une liste priorisée de correctifs avec leurs responsables.
Site lent, serveurs inoccupés ? Parler à un ingénieur.
Votre prochain partenaire d'infrastructure
Examinons votre environnement.
Dites-nous ce que vous faites tourner aujourd'hui et ce qui doit s'améliorer. Un ingénieur examinera votre demande et vous aidera à planifier la suite.
+357 222 32280
Commençons par votre environnement.
Un peu de contexte nous aide à démarrer la bonne conversation.