Hi. We have solved this problem. We had tuned TCP/IP stack in Linux Kernel but it hadn't helped us because there was very law value backlog in listen function int listen(int sockfd, int backlog); This function is used in nginx and lighttp demons. In nginx this value had been set to 511 and in lighttp to 1024. We set both value to 65535 or -1 and solve our problem. Now we have about 700Mbit per second instead 70. But now we got another trouble - our server under heavily load because ksoftirqd use 100% CPU. We suppose that this process is "bottle-neck". Can we tune this process? Thanks. 2008/9/26 Pekka Savola <pekkas@xxxxxxxxxx>: > On Fri, 26 Sep 2008, Vitaly Ivanov wrote: >>> >>> Output how? A single-stream output, or output to multiple (hundreds or >>> thousands?) clients? Where is the test client, in the same lan or >>> further >>> away in the network? >> >> Clients are the thousands HTTP browsers in the Internet. Both servers >> contain the same static content size from 2Kbytes to 1Mbyte. > > How many simultaneous users is the typical figure? > > Is polling enabled? How have you tuned FreeBSD performance? > > Have you been able to figure out what's the bottleneck on linux vs on > freebsd? Is it CPU (which process?), interrupts, disk-IO, ...? (top, > vmstat, etc. maybe help in that) > > One thing that is different in Linux/FreeBSD is rfc1323/window-scaling > support. I suspect you've already checked it, but I'd verify that both > systems are sending out and receiving similar-looking packets (for example, > similar MTUs, no fragmentation, no ICMP packet too bigs, ...) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
