Performance issue on PA-5050 with profile active

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Performance issue on PA-5050 with profile active

L1 Bithead

I've ran into an interesting throughput issue with a PA-5050 in my lab, maybe someone can shed some light on this strange behaviour.

The setup: PA-5050 running 4.0.7
Two aggregated trunks: AE1 & AE2
AE1 assigned to VSYS1 (Server VSYS)
AE2 assigned to VSYS6 (Client VSYS)

The test:
FTP download test from a Windows2003 machine (with FileZilla) in VSYS1 to an XP client in VSYS6. Both machines
are connected with a single GigE connection.
The test files on the FTP server:
- 70MB ZIP file
- 200MB EXE file
- 400MB ISO file

I get a consistent 60% bandwidth usage "ceiling" (no peaks, no drops) during the downloads of this files, which is what can be expected for a GigE connection without jumbo frames active.

Now the fun stuff: when I activate a (any) profile (being it either IPS, AV, Anti Spyware or even only URL filtering) and this on the matching security rule (in either VSYS1 or VSYS6) I get the following bandwith usage values (measured on the XP workstation) during the transfer:
- 70MB ZIP file: 5% bandwidth, but fluctuates between 0,5 and 15%
- 200MB EXE file: 5% bandwidth ceiling (no drops, no peaks)
- 400MB ISO file: 60% bandwith usage (ie "normal")

If I enable a profile in both VSYS1 and VSYS6, the throughput drops by half:
- 70MB ZIP file: 2,5% bandwidth, but fluctuates heavily between 0,2 and 8%
- 200MB EXE file: 2,5% consistently
- 400MB ISO file: 60% bandwith usage

Any thoughts as why I see such a major throughput drop in this PA-5050 box when I activate a profile ?

3 REPLIES 3

L6 Presenter

I suggest that you open a support case so that we can debug this behavior.

Thank you,

Benjamin

L4 Transporter

It's possible this is not really a throughput issue but a TCP windowing/latency issue.  Activating profiles introduces a small amount of latency that can affect throughput for single flows at very high bandwidth if not properly accounted for.  You can try tweaking the TCP windowing or running more flows through the box to get maximum throughput.

Not sure if this is the case in your lab, but it is something I have seen in high throughput environments in the past.  Might be worth checking into.

Cheers,

Kelly

Hi Kelly,

Thanks for the suggestion. I have no traffic going through the box, only the ftp test traffic. I tested multiple ftp connections, and indeed the throughput doubles with each stream (from 5% bandwidth usage to 10% with 2 simultaneous ftp downloads).

I also did some sniffer traces and I don't see anything out of the ordinary there.

I'll do some more tests today and open up a case via our integrator

Thanks!

  • 2257 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!