now i switch the cipher to blowfish. as a result the percentage the server spends in the kernel went down to 3.5%-4.9%. my guess is that this is due to the quicker cipher. the apache process which is serving the file, however, bounces between 20-95% cpu usage. how come? how does ipsec change user-space so that the application needs more cpu? the used bandwidth is even worse then before: the server manages to push only 27.9M/s, which is slightly more then a quarter of its rated network throughput.
i cant see any bottelnecks in the server (like 100%cpu somewhere, swapping because of full RAM, etc). i start to suspect package fragmentation, windowsize/flow control or similar issues. are there /proc or /sys files to look at to get more information about such issues when doing ipsec? tcpdump is less helpful. btw: this is what i get when tcpdumping: 20:25:03.313692 IP 78.31.14.86 > 78.31.14.93: ESP(spi=0xc929dbe8,seq=0x100a8c), length 1476 20:25:03.313699 IP 78.31.14.93 > 78.31.14.86: ESP(spi=0xc4967810,seq=0x7bcd3), length 68 20:25:03.313734 IP 78.31.14.86 > 78.31.14.93: ESP(spi=0xc929dbe8,seq=0x100a8d), length 1332 20:25:03.313788 IP 78.31.14.86 > 78.31.14.93: ESP(spi=0xc929dbe8,seq=0x100a8e), length 1476 20:25:03.313812 IP 78.31.14.93 > 78.31.14.86: ESP(spi=0xc4967810,seq=0x7bcd4), length 68 20:25:03.313847 IP 78.31.14.86 > 78.31.14.93: ESP(spi=0xc929dbe8,seq=0x100a8f), length 1476 20:25:03.313887 IP 78.31.14.86 > 78.31.14.93: ESP(spi=0xc929dbe8,seq=0x100a90), length 1332 why the odd package size? MTU is 1500. there seems to be plenty of space. this is ONE huge file transmitted via http. On Tue, Dec 29, 2009 at 5:34 PM, Andreas Schuldei <[email protected]> wrote: > i suspect there is some ipsec internal bottleneck there. with an other > long-running test we were not able to push more then 40Mbyte/s over > the net, and cpu did not max out. there were no massiv kernel threats > and disks were far from their limit. > > can someone with more insight into ipsec explain what happens? > > this is an importan point. we need to get more performance (about > twice as much) out of these boxes then this. > > > > On Tue, Dec 29, 2009 at 2:55 AM, Andreas Schuldei > <[email protected]> wrote: >> so i configured ssh to bypass ipsec, set up ssh to use blowfish >> encryption and set up rshd on the test machine (which gave me >> goosebumps). >> >> r...@krista:~# time rcp bigfile teagan: >> >> real 0m8.738s >> user 0m0.008s >> sys 0m7.188s >> r...@krista:~# time scp bigfile teagan: >> bigfile >> 100% 325MB 65.1MB/s 00:05 >> >> real 0m4.945s >> user 0m3.716s >> sys 0m0.980s >> >> there is a real chance that rcp sucks on the security AND the >> performance level. so i retried with http (apache and wget): >> >> 100%[=====================================================================================================>] >> 341,218,664 36.8M/s in 8.8s >> >> 2009-12-29 01:53:20 (37.1 MB/s) - `bigfile.1' saved [341218664/341218664] >> >> that is the same result. i use a heavier cipher for ipsec then for ssh: >> >> AES_CBC-128/HMAC_SHA1_96, rekeying in 92 seconds, last use: 136s_i 145s_o >> >> what ciphers are faster that i could use? is it plausible that AES is >> that much slower then blowfish on an idle server with an up to date >> xeon cpu? these servers are connected to each other via a switch. >> >> /andreas >> > _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
