From: Giles Scott (gscott2IZZATnortelnetworks.com)
Date: Tue Feb 18 2003 - 12:24:00 EST
I just posted the information after Frank Cheong [chocobofrankIZZAThotmail.com]
request.
"
Hi,
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 ?
Frank
"
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 [mailto:JOHLAUIZZATdanskebank.dk]
Sent: Tuesday, February 18, 2003 11:49 AM
To: lb-lIZZATvegan.net
Cc: lb-lIZZATvegan.net; owner-lb-lIZZATvegan.net
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?
:-)
/Johnny
"Giles Scott" <gscott2IZZATnortelnetworks.com>
Sendt af: owner-lb-lIZZATvegan.net
18-02-2003 16:17
Besvar venligst til lb-l
Til: lb-lIZZATvegan.net
cc:
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).
http://www.nortelnetworks.com/products/01/alteon/2224/collateral/tolly_alteo
n0103.pdf
Giles Scott
Alteon GNPS
Nortel Networks
-----Original Message-----
From: Shawn Nunley [mailto:shawnIZZATnunleys.com]
Sent: Thursday, February 13, 2003 8:41 PM
To: lb-lIZZATvegan.net
Subject: RE: [load balancing] F5 Technical Specification
Tony,
Mind if I add a few comments? :)
-----Original Message-----
From: owner-lb-lIZZATvegan.net [mailto:owner-lb-lIZZATvegan.net] On Behalf Of tony
bourke
Sent: Wednesday, February 12, 2003 8:34 AM
To: lb-lIZZATvegan.net
Subject: Re: [load balancing] F5 Technical Specification
[tony]
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.
[shawn]
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.
[tony]
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.
[shawn]
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.
[tony]
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.
[tony]
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).
[shawn]
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.
[tony]
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
bottlneck.
Tony
On Tue,
11 Feb 2003, Malcolm Turnbull wrote:
>
> I would have thought they dont mention it 'cause it cause no one
should
> 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
various
> > F5 products including 520, 520 Appliance, Switch 1000 and e-commerce
> > controller ? As the specification that I have download from the
> > www.F5.com <http://www.F5.com> doesn't contains specification that
is
> > detailed enough. As least they haven't mention the number of
concurrent
> > connection that each model can substantiate.
> >
> > Thx & Rgds,
> > Frank
> >
>
>
>
-- -------------- -- ---- ---- --- - - - - - -- - - - - - - Tony Bourke tonyIZZATvegan.net____________________ The Load Balancing Mailing List Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l Archive: http://vegan.net/lb/archive LBDigest: http://lbdigest.com MRTG with SLB: http://vegan.net/MRTG Hosted by: http://www.tokkisystems.com
____________________ The Load Balancing Mailing List Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l Archive: http://vegan.net/lb/archive LBDigest: http://lbdigest.com MRTG with SLB: http://vegan.net/MRTG Hosted by: http://www.tokkisystems.com
_______________ 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: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l Archive: http://vegan.net/lb/archive LBDigest: http://lbdigest.com MRTG with SLB: http://vegan.net/MRTG Hosted by: http://www.tokkisystems.com
This archive was generated by hypermail 2.1.4 : Tue Feb 18 2003 - 12:30:57 EST