https, TTFB, load testing

[Thomas Bassetto]

Je regardais les performances d'une des pages d'une nouvelle web app
sur laquelle je vais travailler et le résultat est accablant :
https://www.evernote.com/shard/s21/sh/0d4c9873-822e-4d9a-9b3f-9f672cf515db/99c5f07dd976690b3f4655c5a76d097a

J'ai plusieurs questions :
- La connexion https nous fait perdre du temps, mais nous ne voulons
pas nous en passer. Savez-vous s'il existe des astuces pour minimiser
le temps pris pour la négociation entre Nginx et le navigateur ?
- Vous voyez d'autres soucis ? (Le gros trou au milieu est du à une
connexion secure websocket. Nous avons notre propre protocole par
dessus wss:// avec un handshake puis vient enfin la première frame
avec des informations sur ce que l'on doit charger comme assets
supplémentaires… Évidemment, nous allons retravailler cette partie.)
- Connaissez-vous un bon service de load testing ? J'ai en trouvé qui
font bêtement un GET sur une URL donnée, mais je voudrais simuler des
centaines de connexion venant de "vrais" navigateurs (chargements des
images, des CSS, initialisation de la connexion websocket, etc.) sans
avoir à louer un botnet… :)

Merci !

--
Thomas

[Anthony Ricaud]

On 14 May 2014, at 16:26, Thomas Bassetto <tbas...@gmail.com> wrote:
> Je regardais les performances d'une des pages d'une nouvelle web app
> sur laquelle je vais travailler et le résultat est accablant :
> https://www.evernote.com/shard/s21/sh/0d4c9873-822e-4d9a-9b3f-9f672cf515db/99c5f07dd976690b3f4655c5a76d097a
>
> J'ai plusieurs questions :
> - La connexion https nous fait perdre du temps, mais nous ne voulons
> pas nous en passer. Savez-vous s'il existe des astuces pour minimiser
> le temps pris pour la négociation entre Nginx et le navigateur ?

J’essayerais plutôt de diminuer le time to first byte d’abord. Il parait bien long par rapport aux autres requêtes. Sinon je n’ai pas trop regardé cela mais je me rappelle que Google a fait plein de trucs sioux avec SSL.

> - Vous voyez d'autres soucis ? (Le gros trou au milieu est du à une
> connexion secure websocket. Nous avons notre propre protocole par
> dessus wss:// avec un handshake puis vient enfin la première frame
> avec des informations sur ce que l'on doit charger comme assets
> supplémentaires… Évidemment, nous allons retravailler cette partie.)

Concaténation de vos css et JS évidemment (2 à 6). Je ne vois pas ce qu’est 7 mais ça me semble être un JS d’un service de fonts vu 8. Bon bah pas de font externe ça améliore les perfs :)
Est-ce que le JSON de 9 pourrait être intégrer dans le HTML directement pour sauver une requête ?
Si vous faites du websocket, vous avez déjà une cible de navigateurs modernes. Est-ce que vous pourriez du coup faire du SPDY/HTTP2 (je ne sais plus comment ça s’appelle de nos jours) et donc avoir les assets pushés par le serveur directement ?

> - Connaissez-vous un bon service de load testing ? J'ai en trouvé qui
> font bêtement un GET sur une URL donnée, mais je voudrais simuler des
> centaines de connexion venant de "vrais" navigateurs (chargements des
> images, des CSS, initialisation de la connexion websocket, etc.) sans
> avoir à louer un botnet… :)

Si c’est une nouvelle version d’un service existant, une iframe invisible c’est pas mal :D

[Gaël Métais]

Bonne idée cette iframe invisible :)

Sinon, je ne connais pas d'outil qui permette d'utiliser un navigateur pour des tests de montée en charge. Mais tu as la possibilité d'enregistrer les requêtes faites par un navigateur pour les rejouer à l'identique (en multipliant les instances). Le Scenario Recorder de Gatling par exemple.

Pour les tests de websockets, il y a peu d'outils. Neotys (qui nous avait fait une préz) sait le faire, mais leur solution est payante.

Je remarque sur la waterfall que le navigateur télécharge plusieurs fichiers en parallèle sans ouvrir de nouvelle connexion, donc vous êtes déjà en SPDY, non ? Si c'est le cas, alors tu peux te pencher sur le push d'assets comme le disait Anthony.

Pas d'idée pour ta question principale, l'accélération du https.

Gaël

Le 14 mai 2014 17:16, Anthony Ricaud <ant...@ricaud.me> a écrit :

On 14 May 2014, at 16:26, Thomas Bassetto <tbas...@gmail.com> wrote:
> Je regardais les performances d'une des pages d'une nouvelle web app
> sur laquelle je vais travailler et le résultat est accablant :
> https://www.evernote.com/shard/s21/sh/0d4c9873-822e-4d9a-9b3f-9f672cf515db/99c5f07dd976690b3f4655c5a76d097a
>
> J'ai plusieurs questions :
> - La connexion https nous fait perdre du temps, mais nous ne voulons
> pas nous en passer. Savez-vous s'il existe des astuces pour minimiser
> le temps pris pour la négociation entre Nginx et le navigateur ?

J'essayerais plutôt de diminuer le time to first byte d'abord. Il parait bien long par rapport aux autres requêtes. Sinon je n'ai pas trop regardé cela mais je me rappelle que Google a fait plein de trucs sioux avec SSL.

> - Vous voyez d'autres soucis ? (Le gros trou au milieu est du à une
> connexion secure websocket. Nous avons notre propre protocole par
> dessus wss:// avec un handshake puis vient enfin la première frame
> avec des informations sur ce que l'on doit charger comme assets

> supplémentaires... Évidemment, nous allons retravailler cette partie.)

Concaténation de vos css et JS évidemment (2 à 6). Je ne vois pas ce qu'est 7 mais ça me semble être un JS d'un service de fonts vu 8. Bon bah pas de font externe ça améliore les perfs :)
Est-ce que le JSON de 9 pourrait être intégrer dans le HTML directement pour sauver une requête ?
Si vous faites du websocket, vous avez déjà une cible de navigateurs modernes. Est-ce que vous pourriez du coup faire du SPDY/HTTP2 (je ne sais plus comment ça s'appelle de nos jours) et donc avoir les assets pushés par le serveur directement ?

> - Connaissez-vous un bon service de load testing ? J'ai en trouvé qui
> font bêtement un GET sur une URL donnée, mais je voudrais simuler des
> centaines de connexion venant de "vrais" navigateurs (chargements des
> images, des CSS, initialisation de la connexion websocket, etc.) sans

> avoir à louer un botnet... :)

Si c'est une nouvelle version d'un service existant, une iframe invisible c'est pas mal :D

--
--
Liste de diffusion sur les performances web : http://groups.google.com/group/performance-web
Plus d'informations : http://performance.survol.fr/
Se déinsinscrire : performance-w...@googlegroups.com
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes performance-web.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse performance-w...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/d/optout .

[Thomas Bassetto]

Salut,

Merci pour vos retours ! On utilise déjà SPDY mais WPT (d'où provient
la capture) ne l'utilisait peut-être pas lors du test (je ne sais pas
plus quel navigateur j'avais sélectionné). Je vais regarder de plus
près le Scenario Recorder de Gatling.

--
Thomas

> Pour obtenir davantage d'options, consultez la page
> https://groups.google.com/d/optout.

[Raphael Luta]

Salut,

Quand je regarde ton waterfall, le temps de connexion TCP semble de l'ordre de 100 ms donc apparemment tu testes avec un client loin de ton serveur.
Dans ces conditions, ce qui t'apportera le plus gros gain en TTFB est tout simplement d'utiliser un CDN pour diminuer ta latence réseau entre le client et le serveur.
Une nouvelle connexion TLS/SSL coute au minimum 3x la latence réseau entre le client et le serveur (1x pour le handshake TCP et 2x pour le handshake TLS)

-- raphael