[Précédent : Journal des
Evénements]
[Index]
[Suivant : ]
PF : Performances
"Combien de bande passante PF peut-il gérer ?"
"Quelle puissance machine est suffisante pour gérer mon
accès Internet ?" "How much computer do I need to handle my
Internet connection?"
Il n'y a pas de réponse facile à ces questions. Pour
certaines applications, un 486/66 avec une paire de bonnes cartes
réseau ISA pourrait filtrer et faire de la NAT à quelques
5Mbps, mais d'autres applications une machine beaucoup plus puissante
avec des cartes réseau PCI plus efficaces pourrait être
insuffisante. La vraie question n'est pas le nombre de bits par seconde
mais plutôt le nombre de paquets par seconde et la
complexité des jeux de règles.
Les performance de PF sont déterminées par plusieurs
variables :
- Nombre de paquets par seconde. Pratiquement le même traitement
doit être effectué sur une paquet avec une charge utile
de 1400 octets que sur un paquet avec une charge utile d'un octet.
Le nombre de paquets par seconde détermine le nombre de fois
que la table d'état et, au cas où il n'y a pas de
correspondance, les règles de filtrage doivent être
évaluées chaque seconde, déterminant ainsi
à quel point on sollicite le système.
- Performance du bus système. Le bus ISA a une bande passante
maximale de 8MB/sec, et lorsque le processeur y accède, il
doit diminuer sa vitesse à la vitesse effective d'un 80286
cadencé à 8Mhz, peu importe la vitesse réelle
du processeur. Le bus PCI a une bande passante effective beaucoup
plus grande et a moins d'impact sur le processeur.
- Efficacité de la carte réseau. Certaines cartes
réseau sont plus efficaces que d'autres. Les cartes
basées sur le Realtek 8139
(rl(4))
ont tendance a avoir de faibles performances alors que les cartes
basées sur l'Intel 21143
(dc(4))
ont tendance à avoir d'excellentes performances. Pour des
performances maximales, utilisez des cartes Ethernet gigabit
même si vous ne vous connectez pas à des réseaux
gigabit. Ces cartes ont une gestion de la mémoire tampon
beaucoup plus avancée que les autres cartes.
- Complexité et conception de votre jeu de règles. Plus
le jeu de règles est complexe, plus lent le pare-feu sera.
Plus vous utiliserez des règles keep state et
quick pour filtrer les paquets, meilleures les performances
seront. Plus le nombre de lignes devant être
évaluées pour chaque paquet, plus faibles seront les
performances.
- Mentionnons quand même deux éléments : le CPU et
la RAM. Vu que PF est un processus noyau, il n'utilisera pas
d'espace de pagination (swap). Donc si vous avez suffisamment de
RAM, il fonctionne sinon il se met en mode panique à cause de
l'épuisement de
pool(9)
exhaustion. Des quantités énormes de RAM ne sont
guère nécessaires. 32MB devraient permettre de
contenir 30 000 états ce qui un nombre énorme pour des
applications SoHo. La plupart des utilisateurs trouveront qu'une
machine "recyclée" est plus que suffisante pour un
système PF. Un système cadendé à 300Mhz
pourra gérer un très grand nombre de paquets
rapidement, dans la mesure où il a des bonnes cartes
réseau et un bon jeu de règles.
Les utilisateurs demandent souvent des benchmarks PF. Le seul benchmark
qui compte vraiment est la performance de votre système
dans votre environnement. Un benchmark qui ne réplique pas
votre environnement ne vous aidera pas à planifier correctement
votre système pare-feu. La meilleure action possible est de
tester PF vous-même dans les mêmes conditions réseau
ou du moins dans les conditions les plus proches possibles que votre
pare-feu actuel sur le même matériel.
PF est utilisé dans certaines applications très
conséquentes et à haut trafic, et les développeurs
sont des "power users" de PF. Il y a donc beaucoup de chance pour que PF
fonctionne dans votre environnement avec des performances correctes.
[Précédent : Journal des
Evénements]
[Index]
[Suivant : Gestion du Protocole FTP]
www@openbsd.org
Originally [OpenBSD: perf.html,v 1.12 ]
$Translation: perf.html,v 1.5 2004/02/19 20:31:29 saad Exp $
$OpenBSD: perf.html,v 1.5 2004/02/20 06:33:11 jufi Exp $