Aby zmierzyć wydajność dla protokołu TCP, emulowano 2400 połączeń klienckich do serwera WWW, każde z nich żądało obiektów o rozmiarze rzędu 512 kB - poprzez firewall. Test był powtarzany w różnych wariantach konfiguracyjnych. Jak się okazało, pracując tylko jako firewall, SRX 580 jest produktem doskonałym. Transport ruchu HTTP odbywał się z łączną prędkością 78Gb/s. Nie sprawdzano wydajności ruchu przez NAT, niemniej - biorąc pod uwagę zachowanie systemu przy testach UDP - nie wydaje się prawdopodobne, aby wydajność spadła. Czas reakcji systemu był stały przez cały czas wykonywania testu, użytkownicy otrzymywali dane w średnim czasie 131 milisekund.

Po włączeniu detekcji włamań zachowanie systemu radykalnie się zmieniło. Nawet bez prób włamania, łączna wydajność spadła z 78 Gb/s w okolice 30 Gb/s. Na użytek testu uruchomiono 252 sygnatury ataku rekomendowane przez Junipera (reprezentujące poważne i krytyczne zdarzenia w sieci). Niestety, użytkownicy potrzebujący detekcji nieautoryzowanych wtargnięć muszą być przygotowani na wyraźny spadek wydajności, zanim nawet jakiekolwiek próby wejścia będą miały miejsce. Juniper potwierdza te dane, podając spodziewaną wydajności rzędu 30 Gb/s. Uruchomienie tej samej konfiguracji z obsługą NAT i IDS daje niemal te same wyniki, co samo zapobieganie włamaniom. Więcej, czasy odpowiedzi były tylko nieznacznie wyższe niż gdy SRX 5800 został skonfigurowany tylko jako firewall - użytkownicy otrzymywali dane z opóźnieniem rzędu 160 ms lub niższym.

Wszystkie te testy zostały przeprowadzone wg ustawień rekomendowanych przez Junipera, dobranych, aby wypośrodkować bezpieczeństwo i wydajność. Ważną cechą tych reguł bezpieczeństwa jest to, że identyfikują w sieci szkodliwy ruch do serwera, ale nie wykrywają szkodliwych połączeń serwer-klient. Ponieważ większość ruchu testowego stanowił HTTP, oznacza to, że urządzenie większość czasu spędziło, szukając pakietów atakujących serwer WWW (ruch do serwera stanowił ok. 650 Mb/s). Reszta pakietów (ponad 29 Gb/s ruchu przychodzącego z serwerów) nie została w ogóle zbadana, pomijając pewne poszukiwania anomalii protokołu i inne możliwe próby ataku niskiego poziomu.

Po dodaniu zabezpieczeń połączeń serwer-klient z biblioteki sygnatur, wydajność spadła do 8 Gb/s. Wniosek jest oczywisty: należy uważać, ustalając politykę IPS, dobranie złych elementów może obniżyć wydajność do nieakceptowanego przez nas poziomu.