Conseils stratégiques pour de grands systèmes applicatifs

L'expérience de notre équipe avec des systèmes d'application à  grande échelle basés sur le Web nous permet d'émettre quelques recommandations générales pour mettre en oeuvre de tels systèmes sur n'importe quelle plate-forme matérielle ou réseau :

• Evitez l'utilisation de routeurs ou de commutateurs. Utilisez des connexions point à 

point là  où c’est pertinent,
par exemple entre certains
systèmes. Le mode point à  point augmente
la bande passante aux niveaux
du câblage et des bus grâce au parallélisme.

Divisez votre trafic réseau et placez
les flux de données indépendants
sur leurs propres réseaux. Ne ramenez
pas tout dans un réseau unique
simplement parce que c’est plus
commode. Deux réseaux peuvent
donner de meilleures performances
et offrir une sécurité plus grande.

Dans la mesure du possible, utilisez
Ethernet 1 gigabit au lieu d’Ethernet
100 mégabits.

Là  où c’est raisonnable, utilisez des
tailles de trames/paquets géantes.
Standard Ethernet utilise une taille
de trame de 1 492 octets. Gigabit
Ethernet offre des trames allant jusqu’à 
8 996 octets. Quand les données
passent dans le réseau particulièrement
à  partir d’une base de données
dans laquelle la longueur de ligne dépasse
1 492 octets, les plus petites
tailles de trames demanderont d’utiliser
des trames multiples, au détriment
de la puissance de traitement.

Assurez-vous que le routeur ou le
hub est configuré correctement et
ne réduit pas votre paramétrage. Si
vous utilisez l’auto-configuration, le
handshaking (passage de témoin) diminue
jusqu’au plus petit dénominateur
commun quand la connexion se
produit. Par conséquent, si une extrémité
est réglée par inadvertance
sur 10 mégabits/half duplex et l’autre
est réglée sur 100 mégabits/full duplex,
le routeur descendra à  10 mégabits/
half duplex. Vérifiez vos paramètres
et vos tailles de trames après
la connexion, pour vous assurer que
tout se passe comme prévu.

Bien que la plupart des lignes de
communication Ethernet donnent
des temps de réponse raisonnables à 
environ 40 % d’utilisation, vous pouvez
obtenir un débit supérieur en
exécutant davantage de lignes à  environ
10-20 % d’utilisation. Souvent le
coût de cette capacité supplémentaire
est très petit et garantit que les
communications ne souffriront pas
d’engorgement.

Le serveur HTTP doit être capable de
réagir rapidement à  une variation de
charge. Par expérimentation, nous
avons constaté que le point optimal
consistait à  définir un nombre de
threads à  50 % du nombre d’utilisateurs
prévu. Vous constaterez parfois
que le serveur HTTP sature ; dans ce
cas, il peut être prudent d’en exécuter
un autre sur un port différent.