Connexion initiale
Vous constaterez que la connexion initiale comprend la négociation du SSL, donc comme la poignée de main est élevée, c'est un bon indicateur que quelque chose ne va vraiment pas dans la façon dont vous avez configuré le SSL.
Google Chrome: Comprendre la synchronisation des ressources
Le temps qu'il a fallu pour établir une connexion, y compris les négociations / tentatives TCP et la négociation d'un SSL.
Prise de contact SSL et TTFB
Vous avez deux problèmes majeurs, le temps passé à terminer une négociation SSL et les serveurs en attente de TTFB (temps jusqu'au premier octet).
- TTFB: 4079ms (devrait être inférieur à 1000ms)
- Prise de contact SSL 11830 ms (doit être inférieure à 100 ms)
Il convient également de noter que lorsque vous testez avec des appareils 3G / 4G, cela peut entraîner des premiers octets plus longs en raison du fait que les signaux téléphoniques varient en intensité ... cela peut entraîner des problèmes de connexion intermittents et des temps de latence variables.
Étape 1: enquête sur le problème SSL
Il est assez évident que vous avez un problème SSL grave et probablement dû à une installation défectueuse d'OpenSSL ou similaire. Commencez par tester votre certificat SSL à l'aide de SSL Labs , puis corrigez les problèmes ou avertissements suggérés.
Si le SSL fonctionne toujours lentement, vous avez probablement un serveur surchargé ou une panne de serveur. Si c'est le plus tard, vous devrez essayer de préciser où se situe la faute. Utilisez la pile Server Fault si vous avez besoin d'aide supplémentaire à ce sujet, un utilisateur a signalé que la création de nouvelles clés résolvait un problème SSL lent qu'il rencontrait, qui pouvait ou non être pertinent.
Les équilibreurs de charge peuvent vous aider en cas de problème de ressource serveur.
Étape 2: Enquête sur le TTFB
Une fois que vous avez enquêté sur la résolution du problème de SSL et que vous disposez toujours d'un TTFB accru, vous devez tester votre serveur en vous assurant qu'il dispose de suffisamment de ressources.
Le temps du premier octet est influencé par, mais sans s'y limiter:
- La distance de l'utilisateur au centre de données hébergeant le serveur peut augmenter le TTFB
- Le GZIP non mis en cache peut augmenter le TTFB
- Les réseaux encombrés peuvent augmenter le TTFB
- Les serveurs congestionnés peuvent augmenter le TTFB
Parfois, augmenter le CPU et la RAM n'est pas toujours la meilleure option. Parfois, il est préférable d'introduire un équilibreur de charge, car cela signifie non seulement que vous pouvez facilement exécuter plusieurs serveurs côte à côte, mais qu'il décharge la mise en cache et les demandes SSL. Certains autres avantages incluent:
LA SOURCE
- Mise en cache: l'appliance peut stocker du contenu qui ne change pas (comme des images) et les servir directement au client sans envoyer de trafic vers le serveur Web.
- Compression: réduit la quantité de trafic pour les objets HTTP en compressant les fichiers avant leur envoi.
- Déchargement SSL: le traitement du trafic SSL est exigeant sur le processeur d'un serveur Web, donc un équilibreur de charge peut effectuer ce traitement à la place.
- Haute disponibilité: deux appliances d'équilibrage de charge peuvent être utilisées en cas de défaillance d'une.
Conseils pour abaisser votre TTFB:
- Assurez-vous que votre base de données se trouve sur le même réseau ou un cloud SQL de qualité .
- Assurez-vous que votre base de données est lue dans la mémoire et JAMAIS JAMAIS le fichier SWAP !
- Utilisez un réseau de diffusion de contenu , il décharge les demandes du serveur et les tâches de compression.
- Utilisez Varnish Cache pour réduire la charge sur la base de données en mettant en cache les pages
- Comparez vos fichiers statiques sur le disque dur à l'aide de HDParm
- Analysez votre serveur à l'aide de l' outil d'analyse comparative des serveurs HTTP Apache
- Benchmark du site Web avec 10 passes avec plusieurs emplacements distants à l'aide de WebPageTest
