J'ai supposé à tort que mes tests AB internes signifient que mon serveur peut gérer 1 k d'accès simultané à 3 k hits par seconde.

Ma théorie à l'heure actuelle est que le réseau est le goulot d'étranglement. Le serveur ne peut pas envoyer suffisamment de données assez rapidement.

Les tests externes de blitz.io à concurrence de 1k montrent que mes hits / s plafonnent à 180, les pages prenant de plus en plus de temps à répondre car le serveur ne peut renvoyer que 180 par seconde.

J'ai servi un fichier vierge de nginx et l'ai mis au banc: il est à l'échelle 1: 1 avec concurrence.

Maintenant, pour exclure les goulots d'étranglement IO / memcached (nginx tire normalement de memcached), je sers une version statique de la page mise en cache à partir du système de fichiers.

Les résultats sont très similaires à mon test d'origine; Je suis plafonné à environ 180 RPS.

Le fait de diviser la page HTML en deux me donne le double du RPS, il est donc certainement limité par la taille de la page.

Si j'utilise ApacheBench en interne depuis le serveur local, j'obtiens des résultats cohérents d'environ 4k RPS sur la pleine page et la demi-page, à des taux de transfert élevés. Taux de transfert: 62586,14 [kilo-octets / sec] reçus

Si je AB à partir d'un serveur externe, j'obtiens environ 180RPS - même que les résultats blitz.io.

Comment savoir que ce n'est pas une limitation intentionnelle?

Si je compare à partir de plusieurs serveurs externes, tous les résultats deviennent médiocres, ce qui m'amène à croire que le problème est dans le trafic sortant de MES serveurs, pas un problème de vitesse de téléchargement avec mes serveurs d'analyse comparative / blitz.io.

Je reviens donc à ma conclusion que mon serveur ne peut pas envoyer de données assez rapidement.

Ai-je raison? Y a-t-il d'autres façons d'interpréter ces données? La solution / optimisation consiste-t-elle à configurer plusieurs serveurs + un équilibrage de charge pouvant chacun servir 180 accès par seconde?

Je suis assez nouveau dans l'optimisation du serveur, j'apprécierais donc toute confirmation d'interprétation de ces données.

Trafic sortant

Voici plus d'informations sur la bande passante sortante: Le graphique du réseau montre une sortie maximale de 16 Mb / s: 16 mégabits par seconde. Ça ne sonne pas du tout.

En raison d'une suggestion sur la limitation, j'ai examiné cela et j'ai constaté que linode a un plafond de 50 Mbps (que je ne suis même pas près de toucher, apparemment). Je l'avais élevé à 100 Mbps.

Étant donné que linode limite mon trafic et que je ne le frappe même pas, cela signifie-t-il que mon serveur devrait en effet être capable de produire jusqu'à 100 Mbps mais est limité par un autre goulot d'étranglement interne? Je ne comprends tout simplement pas comment les réseaux à cette grande échelle fonctionnent; peuvent-ils littéralement envoyer des données aussi vite qu'ils peuvent lire sur le disque dur? Le tube réseau est-il si gros?

En conclusion

1: Sur la base de ce qui précède, je pense que je peux certainement augmenter mon 180RPS en ajoutant un équilibreur de charge nginx au-dessus d'une configuration de serveur multi nginx à exactement 180RPS par serveur derrière le LB.

2: Si linode a une limite de 50/100 Mbits que je ne frappe pas du tout, il doit y avoir quelque chose que je peux faire pour atteindre cette limite avec ma configuration de serveur unique. Si je peux lire / transmettre des données assez rapidement localement, et que linode dérange même d'avoir un plafond de 50 Mbits / 100 Mbits, il doit y avoir un goulot d'étranglement interne qui ne me permet pas d'atteindre ces plafonds que je ne sais pas comment détecter. Correct?

Je me rends compte que la question est immense et vague maintenant, mais je ne sais pas comment la condenser. Toute contribution est appréciée sur toute conclusion que j'ai faite.

Le problème était que je supposais que les pics du graphique linode.com étaient de vrais pics. Il s'avère que le graphique utilise des points de données moyens de 5 minutes, donc mon pic semblait être de 24 Mbits alors qu'en fait je touchais le plafond de 50 Mbits.

Maintenant qu'ils l'ont élevé à 100 Mbits, mes repères ont immédiatement atteint la nouvelle limite de trafic sortant.

Si seulement je l'avais remarqué plus tôt! Une grande partie de mon raisonnement reposait sur l'idée que je n'atteignais pas une limite de trafic sortant en raison de ce graphique.

Maintenant, je culmine à 370 requêtes par seconde, ce qui est juste en dessous de 100 Mbps, point auquel je commence à obtenir un "arriéré" de requêtes, et les temps de réponse commencent à augmenter.

Je peux maintenant augmenter la simultanéité maximale en réduisant la page; avec gzip activé, j'obtiens 600RPS.

Je rencontre toujours des problèmes lorsque j'atteins un pic et que l'arriéré de demandes en attente (limité par la bande passante) commence à s'accumuler, mais cela ressemble à une question différente.

Cela a été une excellente leçon d'optimisation / lecture de ces données / réduction des problèmes possibles. Merci beaucoup pour votre contribution!

Un peu tard maintenant que vous avez compris ... mais peut-être devriez-vous envisager de lire le blog ServerFault de temps en temps.

Je pense en particulier à ce post , où ils discutent pourquoi avoir un intervalle d'interrogation d' une seconde ne le coupe pas de temps en temps, lié à un problème très similaire à celui que vous aviez ..

Nous avons découvert que nous rejetions des paquets assez fréquemment sur des interfaces à 1 Gbit / s à des débits de seulement 10-30 Mbits / s, ce qui nuit à nos performances. En effet, ce taux de 10 à 30 Mbits / s est vraiment le nombre de bits transférés par 5 minutes convertis en un taux d'une seconde. Lorsque nous avons creusé plus près avec Wireshark et utilisé un graphique d'E / S d'une milliseconde, nous avons vu que nous éclaterions fréquemment le débit de 1 Mbit par milliseconde des interfaces dites à 1 Gbit / s.

Bien sûr, ça m'a fait réfléchir. Et je sais juste que j'éclate celui-là sur les autres SA dans ma boutique la première chance que j'ai, et il aura l'air incroyablement brillant et perspicace quand nous rencontrerons ce problème.

Qui sait, je peux même en laisser certains dans le secret. :)

Elle peut être limitée par le réseau, mais pas nécessairement simplement une question de bande passante. La latence de votre unité de test à distance aura un effet sur le nombre de connexions en attente à un moment donné (attendre 50 ms pour les accusés de réception est très différent de 0,5 ms localement) ainsi que sur la négociation et la stabilisation des tailles de fenêtre à mesure que la connexion progresse. Vous êtes également probablement exposé à une certaine quantité de perte de paquets - soit en fonction de la congestion, soit en tant que mécanisme de limitation de la bande passante de la part de votre opérateur (ou de ceux en amont).

Je suggère d'éliminer autant que possible de l'équation pour tracer une ligne de base raisonnable. Mesurez la bande passante de pointe, la latence et la perte de paquets de votre serveur en quelques points sur Internet en général. Aussi improbable que cela puisse paraître, essayez de rechercher «Test de trafic VoIP» ou similaire. Plusieurs fournisseurs de services VOIP ont des applications qui peuvent mesurer ces types de modèles (bidirectionnellement) avec un bon degré de précision. Une fois que vous avez des données empiriques valides sur la vitesse utile réelle de votre lien, vos résultats peuvent être validés.

En plus des tests de bande passante, il peut également être utile d'examiner une capture de paquets du trafic Web inférieur à la normale pour rechercher un nombre excessif de retransmissions ainsi que de mesurer le temps apparent que prend votre serveur pour répondre aux demandes (..si cela la valeur augmente considérablement en fonction du nombre de connexions, c'est un gros indice).