Forum Discussion
Mike_Lowell_108
Sep 11, 2007Historic F5 Account
Any questions? Post'em
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
38 Replies
- Mike_Lowell_108Historic F5 AccountIt's likely what you're seeing with the varying size of the reads are SSL record boundaries. Reading 500 bytes at a time is quite small. I suspect this is a really slow client machine or distant network connection? Another possibility would be that BIG-IP supports more ciphers than the server itself, so perhaps the communications between the client and BIG-IP is using a different cipher compared to the communications when testing client to server directly.
BTW, you might try changing the proxy buffer to a smaller value like 4k. This is just a shot in the dark, though. A tool like ssldump can read packet captures taken from BIG-IP and help to interpret SSL behaviors. If you use a common cipher (like RC4-MD5), you can use ssldump together with your SSL private key to actually decrypt the SSL connection and see the data, and more important, see if what (if any) SSL alerts are occurring.
I'm sorry I can't be more help. This sounds like an odd situation. :) If you can capture a tcpdump of a successful connection and a failed connection, I'm sure that would really help the support team to figure things out. If there is an example of good and bad behavior, then it's just a matter of figuring out what's different between the two to then solve the problem. :)
Good luck!
Mike Lowell - ajay_2551
Nimbostratus
Well there was no difference even reading more than 500 bytes every time. We'll try with "proxy buffer" settings and we also try to get some help from BigIP support. Thanks for your suggestions Mike. - ajay_2551
Nimbostratus
Mike,
We have contacted Big IP, we send our ethereal trace logs to them, but we are not getting accurate info/solution from them. Mean while we are spinning other threads to resolve this problem.
We have tried "proxy buffer high" to 4096, it didn't worked. But the problem looks like something to do with SSL packet size at BigIP (16k) and POS device(9k) only. According to Ethereal trace we found that
- Could able to transfer large chunk of data from POS device to server with out using SSL (just over http port 80), but failed to download the data when we use SSL.
- When we looked at ethereal trace we found “SSLV3 unreassembled packet”, then after some time it says "[TCP window Full]Encrypted Alert" after the initial handshakings.
- BigIP says we can not limit the size of SSL to 9k on our BigIP.
- We tried sending small chunk of data (around 5k) every time with little delay in between, kind of pagination, but we didn’t see any difference.
Is there any suggestions you can throw, kind of we are stuck in our production. - ajay_2551
Nimbostratus
Thanks Roger, we'll try your suggestion. Mean while can you pls. clarify few things for me, to enable me to explain the changes to our network team clearly.
- Is enabling Proxy MSS option is in TCP Profile options (what is virtual that you are suggesting)? Can you pls. elaborate on this?
- Can we fix the size of MSS at application server (we use IPlanet), so that we don't get into the problem with BigIp splitting the packets. - ajay_2551
Nimbostratus
Thanks Roger, we updated your suggestion to our network team, what we found out they did changes for MTU at Cisco router level and it didn't worked either. The one thing we found out after careful analysis of ethereal trace, that difference of SSL record length at BigIP (16k) and POS (9k) is not a problem at all, as the record length never hit 9k at any time. Any way we are implementing an alternative solution kind of dirty work to download small chunks many times, which is a performance issue, but can be operational. Appreciate if you or anybody have any other suggestions.
Leaving this problem unsolved, kind of sad and unchallenging....but given time frame and customer satisfaction we have to live with that. - sweta_kanguri_8
Nimbostratus
hi i am into support for web services in weblogic server, i want to know the differences between using load balncing algorithms(round-robin,random,weight-based) and using server affinity load balancing algorithms?
also differences between using HttpClusterServlet proxy and hardware load balancer(BIGIP)?
from,
sweta - hoolio
Cirrostratus
Hi Sweta,
The different load balancing algorithms are detailed in the LTM configuration guide on AskF5.com. If you take a look at the doc for your version and have questions, reply here.
Aaron - zafer
Nimbostratus
Hi Mike,
my customer also Global F5 customer
The customer has Redundant pair LTM 6400 and we put on the some other customer datacenter, we use simple irule for host based load balancing and enabled compression.
We saw 350-400 mbits throughput on peak time and Cpu usage was %60. So i want to sell Bigip to the datacener admin but he ask me everytime if we use irule we will have cpu problem (guy is alteon expert) his existing topology alteon load balance + Redline and he is happy.
i see same question on customers site if we use iRule what will be CPU usage.
Not: i have some spesification for L4,L7 ,compression,SSL and Throughput.
can we see same performance when we use all feature at same time
if you help me i will be very happy
if you want you can send me email directly
regards
zafer - Mike_Lowell_108Historic F5 AccountHi Zafer,
I encourage you to work with your local field engineer to help size deployments. When a product does more work, it requires more resources, and understanding the performance of a combined feature-set (SSL + compression + ...) is a fairly involved multi-dimensional problem (lots of variables, many things to consider).
Having said that, the relative advantage of the BIG-IP product versus competitors is still strong. If BIG-IP can handle more L4, L7, SSL, compression, and so on for individual tests, that also means BIG-IP can handle more in combined tests. For example, if BIG-IP handles 6Gbps of compression and 6Gbps of SSL in separate tests, where a competitor may handle 3Gbps of compression and 3Gbps of SSL in separate tests, neither vendor will achieve both metrics at the same time, but perhaps BIG-IP will achieve 4Gbps of SSL+compression, and the competitor will achieve 2Gbps of SSL+compression -- BIG-IP's advantage is the same whether you look at individual metrics or combined metrics.
About iRules performance, I've performed extensive tests of L7 performance on both BIG-IP and competitive platforms (including Alteon, Redline, and Foundry). If you compare similar platform models and feature-sets between products, BIG-IP's performance with iRules is consistently higher. However, if you're using iRules to do something uncommon, something that the competitors are unable to do at all, then there's of course no way to compare this directly to the competitors. For the "L7" tests that vendors in our market use as the baseline, it's inspecting an HTTP URL to select between different groups of servers. All vendors support this basic L7 feature-set, so it's a good baseline comparison. The advertised L7 performance of BIG-IP is based on this same sort of test, using iRules. As you've seen in the report(s), BIG-IP's performance using iRules for this task is very competitive against our competitors. The real key in judging L7 performance is to make sure there's a similar feature-set in use between platforms that are being compared. Based on my extensive testing, I'm very confident BIG-IP will come out ahead. :)
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. For more advanced tasks, my experience testing Alteon, Redline, Foundry, and more has shown that BIG-IP's performance is very competitive. If you're seeing 60% CPU on the BIG-IP, then you'll see more than 60% CPU on similar competitive hardware. If you see higher utilization on the BIG-IP compared to a similar competitive platform, then I suggest a different set of features must be in use (perhaps BIG-IP is acting as a full proxy, whereas the competitor is not, in which case it's appropriate to use a simpler non-full proxy mode on the BIG-IP).
Hope this helps, good luck!
Mike Lowell - ugurtanyildiz_9
Nimbostratus
Hi Mike
As a global customer,my company use F5.
In a current project we have redundant LTM 340 topology.
It was working properly but we have to run an irule now, and investigating the effect of running an irule on the performance.
I mean is there a report that shows the CPU usage of F5, when we run a basic irule,
I check out the forums however, could not find the answer,
I would be glad if you could help.
Thanks in advance,
ugur
Recent Discussions
Related Content
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects
