RE: Vedr.: RE: [load balancing] F5 Technical Specification

From: Giles Scott (
Date: Tue Feb 18 2003 - 12:24:00 EST

  • Next message: Giles Scott: "RE: Vedr.: RE: [load balancing] F5 Technical Specification"

    I just posted the information after Frank Cheong []

    I just give out one of an example of technical spec which I of coz agree the
    no of session per second and the data rate (thru put) is of more important.
    But up to now, I still got no answer from anywhere regarding there
    information for F5 model, is that F5 never post this kind of information out
    ? If this is the case, is there any independent testing lab have done any
    testing and posted the result onto the web ?

    Read into the Tolly report what you want :-)
    But I would guess that the Nortel AAS2424 would also meet most of your
    requirements set out below.

    But there again I would say that :-)

    Giles Scott
    Alteon GNPS
    Nortel Networks

    -----Original Message-----
    From: Johnny Fribert Lauridsen []
    Sent: Tuesday, February 18, 2003 11:49 AM
    Subject: Vedr.: RE: [load balancing] F5 Technical Specification

    Very interesting reading,
    however, performance tests is not what makes me buy one box instead of the
    other. Should it be?
    Well, I tend to look at how it fits into our network first.
    If it cannot do a simple list of things, then its not interesting - e.g. it
    could be simple things as,
    - does it hook into our routing strategy - OSPF or whatever?
    - does it hook into our security strategy - TACACS or whatever?
    - does it support our local logging strategies - whatever they may be
    - does it have a good support plan
    - etc. etc.
    e.g. does it fit-into our environment?
    When we get past that part, then we can start looking at performance.
    Then we see all these tests and get a lot of information from the vendor.
    However, these tests never seems to fit into our environment.
    E.g. tests done with 200 clients with 1million session.
    What! We may, in one scenario have 10000 (simul) clients with 10000
    sessions (long-lived),
    10000 simul) clients with 40000 sessions (short-lived), 400 clients with
    4000 sessions (short-lived),
    etc. etc. Doesn't fit. Vendor might suggest that we can then do a simple
    mathematical equation
    to fit my scenario into the test-scenario. We all know (those of us that
    are implementing!) that this
    does not equate at all. There is no such mathematical formula when it comes
    to 'users' use
    of our IT systems.

    Then we have application specifics - not everything in the world is HTTP.
    I could go on :-)

    The lesson is - its good to have these vendor tests, but I seem to not be
    able to relate to them for
    my setups. However, if I found two or more boxes that could fulfill my
    needs, then, naturally,
    I would look at performance - however, then again, management might
    overrule, if they already
    have a good support plan with the other vendor.
    Makes sense, or am I blabbing?

    "Giles Scott" <>
    Sendt af:
    18-02-2003 16:17
    Besvar venligst til lb-l
            Vedr.: RE: [load balancing] F5 Technical Specification

    Don't want to sound like a salesperson ('cos I'm not) but
    The latest Tolly testing between Nortel, F5 and Cisco (the testing was
    sponsored by Nortel).
    Giles Scott
    Alteon GNPS
    Nortel Networks
    -----Original Message-----
    From: Shawn Nunley []
    Sent: Thursday, February 13, 2003 8:41 PM
    Subject: RE: [load balancing] F5 Technical Specification
    Mind if I add a few comments? :)
    -----Original Message-----
    From: [] On Behalf Of tony
    Sent: Wednesday, February 12, 2003 8:34 AM
    Subject: Re: [load balancing] F5 Technical Specification
    Concurrent connections in regard to regular load balancing isn't so much
    of a potential bottleneck... most systems can handle at least hundreds of
    thousands of connections without any issue.
    yes, that is true, it's not really a source of bottleneck. However, if you
    are exceeding the limit of concurrent sessions over the course of, say, 3-4
    hours, then you will of course see those clients needlessly renegotiating
    their connections every time they come back after a period of inactivity.
    Sometimes the capacity for 'concurrent' clients is useful even though it
    exceeds any reasonable estimation of actual
    *active* concurrent clients. Overhead is the enemy. If you can eliminate
    it, eliminate it.
    In the vast majority of cases, a system will either hit connections per
    second or throughput limitations before any TCP connection-related limit.
    Doing the three-way handshake, going through the network stack, doing the
    load balancing work or web server handoff, those all take up resources.
    Simply keeping open and active or inactive TCP session consumes very little
    in the way of CPU or memory resources.
    true again, but with a twist. Sure, it doesn't take a whole lot of memory
    to keep track of a million connections, but if you have to start 'swapping'
    things around to make one on the list 'active' you would kill performance.
    Handling very large numbers is, again, very useful to avoid unnecessary
    overhead. BTW, Malcolm, it takes a lot more than memory to keep track of
    sessions. NetScaler maxes out at 2.4 million concurrent HTTP sessions
    today, and that's a technological feat! I can't tell you what the F5 number
    is because I haven't seen it in print yet.
    The only exception that I can think of is the older Alteon/Nortel code
    without VMA, which limited per-port TCP connections to a certain amount
    (32,000 or 64,000, depending on the unit and if you had filtering enabled).
    The introduction of VMA increased that limitation typically 8 fold, which
    was plenty for just about every installation imaginable.
    SSL cards usually have limitations beyond the regular TCP session handeling
    because of the crypto work involved (which LVS doesn't contend with). It's
    not the TCP handling that it cares about, but rather the
    workload involved with juggling multiple encrypted sessions. That
    relatively low limitation can be an issue, although not too many sites are
    doing 10,000 concurrent SSL sessions (since many sites only do SSL for
    their e-commmerce or authentication, rather than the entire site).
    SSL cards are usually limited by a number of things, but I think the most
    important of these is concurrent sessions must be on par with TPS. I am not
    impressed with a recent offering I read about where the TPS number is really
    hot, like 5000 TPS, but the concurrent sessions is limited to some low
    number like 32,000 (or lower). That 5000 TPS would never be utilized unless
    it was some extremely fast automated client instead of browsers. I'm just
    saying those numbers should be in the same performance neighborhood. Our
    device is at 4400 TPS (well, 4800+ if you go by the Light Reading report,
    but we typically low-ball our claims so as not to disappoint!) and it
    handles 320,000 concurrent sessions... seems a bit more balanced to me.
    So unless you're using SSL, you'll likely never, ever hit TCP connections
    as a limit. Connections per second and/or bandwidth will likely be your
    On Tue,
    11 Feb 2003, Malcolm Turnbull wrote:
    > I would have thought they dont mention it 'cause it cause no one
    > ever get several million concurrent connections.
    > I would have thought F5 is similar to LinuxVirtualServer i.e. Every
    > 128MB of RAM = 1 Million concurrent persistent conections.
    > But obviously just a guess.
    > frank wrote:
    > > Hi,
    > >
    > > Does anyone have links for detailed technical specification for
    > > F5 products including 520, 520 Appliance, Switch 1000 and e-commerce
    > > controller ? As the specification that I have download from the
    > > <> doesn't contains specification that
    > > detailed enough. As least they haven't mention the number of
    > > connection that each model can substantiate.
    > >
    > > Thx & Rgds,
    > > Frank
    > >

    -------------- -- ---- ---- --- - - - -  -  -- -  -  -  -   -     - 
    Tony Bourke                    

    ____________________ The Load Balancing Mailing List Unsubscribe: Archive: LBDigest: MRTG with SLB: Hosted by:

    ____________________ The Load Balancing Mailing List Unsubscribe: Archive: LBDigest: MRTG with SLB: Hosted by:

    _______________ Vi goer opmaerksom paa, at denne e-mail kan indeholde fortrolig information. Hvis De ved en fejltagelse modtager e-mailen, beder vi Dem venligst informere afsender om fejlen ved at bruge svar-funktionen. Samtidig beder vi Dem slette e-mailen i Deres system uden at videresende eller kopiere den. Selv om e-mailen og ethvert vedhaeftet bilag efter vores overbevisning er fri for virus og andre fejl, som kan paavirke computeren eller it-systemet, hvori den modtages og laeses, aabnes den paa modtagerens eget ansvar. Vi paatager os ikke noget ansvar for tab og skade, som er opstaaet i forbindelse med at modtage og bruge e-mailen. _______________ Please note that this message may contain confidential information. If you have received this message by mistake, please inform the sender of the mistake by sending a reply, then delete the message from your system without making, distributing or retaining any copies of it. Although we believe that the message and any attachments are free from viruses and other errors that might affect the computer or IT system where it is received and read, the recipient opens the message at his or her own risk. We assume no responsibility for any loss or damage arising from the receipt or use of this message.

    ____________________ The Load Balancing Mailing List Unsubscribe: Archive: LBDigest: MRTG with SLB: Hosted by:

    This archive was generated by hypermail 2.1.4 : Tue Feb 18 2003 - 12:30:57 EST