[Précédent : Journal des Evénements] [Index] [Suivant : Gestion du Protocole FTP]

PF : Performances

"Combien de bande passante PF peut-il gérer ?"
"Quelle puissance de machine est suffisante pour gérer mon accès Internet ?"

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 requièrent une machine beaucoup plus puissante avec des cartes réseau PCI plus efficaces. La vraie question n'est pas le nombre d'octets par seconde mais plutôt le nombre de paquets par seconde et la complexité des jeux de règles.

Les performances de PF sont déterminées par plusieurs variables :

• Nombre de paquets par seconde. Pratiquement le même traitement doit être effectué sur un 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'états 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 sera le pare-feu. 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 sera grand, plus les performances seront faibles.
• Mentionnons tout de 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 du pool(9). Des quantités énormes de RAM ne sont guère nécessaires. 32Mo 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 avec un trafic important, 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]