|
Thanks for that document...
How do you make payload only 64 bytes? Is that include the TCP header
and HTTP header or not?
F5 is also use Linux 2.4 kernel, how could they get the new connection
/ per second count so high?
We are trying to twist the kernel code to see what can we do to make
the new connection number
go up. Anybody tried to tweak the kernel for improving the performance?
Also, what would limit the total number of connections? I tried to
add more memory and does not
seem help. May be some kernel parameter limiting it?
On Tue, Apr 14, 2009 at 2:06 PM, Malcolm Turnbull
<malcolm@xxxxxxxxxxxxxxxx> wrote:
> Jason,
>
> That's 50,000 connections per second or up to 850MB/s (not 15MB/s).
>
> We tried to following this coyote testing methodology (which they
> copied from from F5), the important bit is the keepalive setting....
> http://www.spirent.com/documents/atp/The_Tolly_Group-Public_Test_Report-1375.pdf
>
> Tolly offered to do the same for us .. a snip at $30,000
> So we hired some spirent kit and an engineer for a day... we were a
> bit rushed to get it done in a day but we were pretty happy that
> performance was comparable to Coyote and better than F5.
>
> The main thing for us was to ensure that our basic kit could:
> a) saturate a 1GB link with medium to large packets.
> b) handle 50K/s transactions consistently without a sweat.. small packet
> sizes.
> We also tested haproxy which we were pleasantly surprised by performance.
> Also unloading or loading netfilter contrack modules made no
> difference (as long as no rules were in place.)
>
> No real system with live random traffic will ever come close to these
> results due to the way ethernet/TCP/IP works.....
>
>
>
>
>
>
>
>
>
> 2009/4/11 <jason.faulkner@xxxxxxxxxxxxx>
>>
>> > I would like to test the way you test to see if I can get 50k/s and
>> > 10,000,000 concurrent connection. What kind of test condition do you
>> > use, clients? server? data size?
>> >
>>
>> The throughput numbers are cake. I push >15MB/s through multiple firewall
>> boxes; not this many concurrent connections, mind you, but a significatly
>> higher throughput. I wouldn't worry about it. Just get good CPUs and NICs
>> (multicore doesn't help).
>>
>> --
>> Jason Faulkner
>> Linux Systems Engineer
>> Mailtrust, a division of Rackspace
>>
>>
>>
>> _______________________________________________
>> Please read the documentation before posting - it's available at:
>> http://www.linuxvirtualserver.org/
>>
>> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
>> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
>
>
>
> --
> Regards,
>
> Malcolm Turnbull.
>
> Loadbalancer.org Ltd.
> Phone: +44 (0)870 443 8779
> http://www.loadbalancer.org/
>
> _______________________________________________
> Please read the documentation before posting - it's available at:
> http://www.linuxvirtualserver.org/
>
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
>
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
