Hi everyone, If you have any questions or comments about the performance report or it's supporting documents, please feel free to post them here. I'm one of the engineers who helped to create the performance report, and I'll be actively monitoring this forum to answer questions. Mike Lowell

Other than a vendor comparison, I would be interested in having performance documents relating to common parameters that one applies such as perhaps Loose initiation or loose close on a Fast L4 profile thus causing PVA to be turned off. In my environmnent, i find that a lot of vips that i use i have to turn on or off some knobs which cause PVA acceleration to set to none, so be interested in getting that perfromance info as it applies to that config.

Good question. It sounds like you're a BIG-IP pro, so you know that BIG-IP has a lot of options. :) By my count there are over 2000 configurable options, and like any device, changing options can affect performance. The good news is we can change the vast majority of the knobs and dials and the impact is barely measurable, sometimes higher, sometimes lower, but generally small enough to fit inside a margin of error. For the few knobs that can have an impact, we usually have some idea of "how much" the impact can be. On the BIG-IP 8800 the performance for "full" and "partial" PVA acceleration is typically within 1% of being identical, due to the processing power of the BIG-IP 8800. The real change switching from "full" to "partial" is that CPU usage goes from 0% (i.e. handled entirely within PVA) to probably 30-40% for small responses, less than 20% for 8KB, and less than 5% for 64KB and larger. Generically speaking, for configurations that have "no" acceleration (software only), top-end performance is likely to be reduced by 5-35%, depending on response size. As an interesting data point, even assuming a worst-case-scenario the L4 performance of the BIG-IP 8800 is still a healthy margin above the competition. :) As always, I personally suggest that customers run their own performance tests to be sure all environmental factors are properly considered. For example, it's often not well appreciated how much server performance factors in. Similarly, many customers don't have a good idea of their response size mix, etc -- there are hundreds of factors like this. The only way to be sure everything is factored in is to test in your particular environment. Having said that, the relative performance between vendors should be similar to what you see in the report. I hope this helps! Mike Lowell p.s. I'll provide your feedback to the right people to look new documents in the future. Thanks!

Mike, Was there testing done to determine the maximum number of persistent SSL connections that could be established? I have an application that requires a large number of concurrent SSL connections (small number of TPS/connection) and was wondering if BIG-IP would fit the bill. Thanks, Jeff

I had an interesting question from my counterpart at SAP Labs. His question was, how does F5 compare in terms of the performance/price ratio? This gets interesting when you talk about disruptive innovators in the marketplace. Thanks and I look forward to your thoughts. Ron

Hi Jeff, Concurrent SSL connections was not tested. In general, the "hard limit" for SSL concurrency is based on the amount of memory that can be allocated to store SSL connection information. The practical limit for SSL concurrency depends on your threshold for latency. As concurrency increases so do the processing requirements for handling each connection. Depending on the particular implementation, factors that contribute to this increase in per-connection overhead may include: connection hash table collisions, memory fragmentation, session cache overflows, connection maintenance functions (checking for connection timeouts, for example), and more. Depending on implementation, the effects of increased overhead may start to appear with thousands, tens of thousands, or hundreds of thousands of connections. It's highly dependent on vendor implementation. All things considered, you're more likely to hit a "practical limit" that causes poor performance (high latency) than you are to hit a "hard limit" based on memory limits. With that in mind, the numbers that vendors have published thus far are based "hard limits". Without having more exact information to give you, I'd like to point out that you're likely to see practical performance limits that mirror the other SSL performance recorded in the performance report. In other words, if vendorX can process 48,000 SSL TPS, vendorY 28,000, and vendorZ 15,000, it's reasonable to expect vendorX has more processing power dedicated to SSL, and thus is likely to have an advantage in practical SSL concurrency as well. I hope that helps. Good luck! Mike Lowell

Any questions? Post'em

38 Replies

Mike_Lowell_108
Historic F5 Account
Feb 22, 2011
It's not double, it's more like 1.2m/1.9m for 8900/8950. If you want double, the 11050 is the way to go, or VIPRION can bring you even more. I'd suggest getting in touch with your local field engineer -- they'll be able to give you all the details.

Mike Lowell
ukiran22_113041
Nimbostratus
Feb 22, 2011
hi,

I'm looking for some guidance on HTTP RPS for 8950. I know for 8900 it is 1.2m. Is it roughly double of that for 8950. I looked through various datasheets and I found this information for 8900 but not for 8950. Is this something that you could help me with.

Jay
doc_hack_12696
Nimbostratus
Jan 13, 2010
We use F5 for a lot of internal applications and are about to start the tuning exercise for each of them. Is there a list of configurable options that we could tweak and test?
Jesse_42849
Historic F5 Account
May 12, 2009

Cookie persistence has less of an impact on performance than using the 'Standard' profile on the virtual. I would expect to see little improvement by just switching to simple persistence, but switching to the fastL4 profile will result in a significant performance improvement. A lot of extra processing is stripped away by moving to fastL4, so you will want to be sure that extra processing isn't being used before making the change.

--jesse
Mark_Porter_979
Nimbostratus
May 12, 2009
Hi Jesse

We're running 9.3.1. No iRules, so switching to fast l4 is a good option also.

mark
Jesse_42849
Historic F5 Account
May 12, 2009
Webguymark,

What version are you using? Are you using any other L7 functionality like iRules, or would you be able to switch your virtual servers over to the fastL4 profile at the same time as you switch to simple persistence?

--jesse
Mark_Porter_979
Nimbostratus
May 12, 2009
Hi Folks

Has anyone ever done a performance/LTM load comparison between using cookie-based and simple persistence? We have some older LTMs (1500 series) with ~350 virtuals, most of which have cookie-based persistence. I'm trying to figure out if it's worth the effort to change them to simple.
noel_65534
Nimbostratus
May 01, 2009
Thanks Mike. OK, I would try not to rely too much on those last minute tweaking of a few percent. I guess the planned configuration would hold, based on the estimated throughput of 200Mbps at its peaktime. (avg. data size 10KB with SSL offload.)

Noel
Mike_Lowell_108
Historic F5 Account
Apr 30, 2009
Actually I don't have any performance info for that. I can tell you that every "L7" performance number you've seen from F5 (data sheets, performance reports, etc) used an iRule, so although an HTTP Classification profile is probably slightly faster, I wouldn't worry about it unless you're running out of resources and need to dial-in the last few percent.
noel_65534
Nimbostratus
Apr 29, 2009
Hi Mike,

I am planning on using a redundant LTM 1500 for a web based mail application service. The planned configuration is to use a single virtual server and select a pool based on URI.

I was thinking of using iRules to do this. Since you wrote as follows, I would like to know if this suggestion was based on a performance reason and would like to know how much performance gain I could have by using HTTP Classification profile.

Mike wrote on 07/01/2008 1:47 PM

> For common tasks like selecting a pool of servers based on the HTTP URI you don't even need iRules -- I suggest using the httpclass profile (HTTP Classification profile) instead.

I understand that it might be difficult to compare iRules' performance since there would be many ways to implement a pool selection. What would you say, if you compare it to the L7 [1-inf] configuration : "HTTP 1.0 or HTTP 1.1 with 1 transaction per connection and OneConnect enabled", listed in the chart found under this thread. Or may be to a standard HTTP profile without iRule selection and OneConnect disabled.

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=40&postid=22989&view=topic

I just want some general numbers for planning purpose. Any advice and suggestive readings would be highly appreciated.

Noel