darkone
01-12-2004, 10:58 PM
Introduction to the madness:
I saw discussion on some other forum (which I'm not allowed to post on) Obiviously IIS, which is working in kernel mode (so it's near impossible to beat.. atleast for an army of one) Io beats IIS in single transfer rates, but is likely to lose the race when it comes up to scalability.
I've pasted single transfer rates here many times before... so I guess it would be pointless, to post them once again. And what does a single transfer tell about daemons performance on real life scenarios? Absolutely nothing. It's much better to exaggerate when setting test parameters.
Parameters:
What would be good test parameters? Let's assume you're running big fileserver on 100mbit connection. And as usual, our fileserver has hardware accelerated SCSI RAID0+1, , and lots of ram to cache files on. So amount of time spent waiting for file io is negligible, and does not affect total transfer time (same as copying from cache). Userbase consists of 10000 users of which, average of 900users are expected to be online and downloading. (Total of 1800active sockets)
Test1:
Now that test parameters are known, and set so that it's possible to run the test on 'normal' computer, we are ready to go.
Set ncftpget as background process to download single file to /dev/null on remote computer. (When all clients are downloading same file, lack of hardware accelerated io or limited amount of memory do not show up in test results) You might consider to wait one or two seconds after every 100requests, so you don't spawn 1000clients that are all trying to connect simultaniously. All clients connected and downloading? Good... you have completed first part of test :)
Test2:
Now that we know that daemon is able to serve those 900clients, we'd most certainly like to know, wheter output rate is limited by daemon (software/cpu) or by network. This can be done by setting up one local transfer. If output speed for single local transfer is higher than for the average for a single transfer over network, we have proven that transfer speeds are not limited by hardware/software.
100mbit * 1024 / 8 / 900 = ~14kb/s
Each network client has ~14kb/sec of bandwidth available => local transfer should be atleast 15kb/sec.
My results:
Network clients: average 14kb/sec, filesize 435242304bytes (varies between 9 & 16kb/sec) Without local client cpu usage averages at ~22% (jumping between 17 & 26) Server doesn't feel lagged.
Local client: average 26990,55Kbytes/sec, filesize 85964896 bytes (Only transfer, that I had patience to wait until end) Result is 1800times more than required. Cpu usage at ~90%, total bw ~39mb/sec.
Conclusion:
On my hardware (Win2K3, Intel Pentium IV 1.8GHz, 512Mb, ATA-100, Intel eepro-100), throughput on 100mbit network is not limited by amount of connections or by hardware.
Other daemons?
I'm not even going to try to run tests on other daemons. Only very few of them would would be able to handle the required amount of connections, and my prior experience with sofware doesn't hint to that they would be able to outperform io (excluding IIS). If someone wants to prove me otherwise, feel free to do so.
Ps. If you actually read this thread, write some short reply, so I'll know wheter to post this kind of crap in the future... just felt like I had a thing or two to say about performance, and how to measure it :D
I saw discussion on some other forum (which I'm not allowed to post on) Obiviously IIS, which is working in kernel mode (so it's near impossible to beat.. atleast for an army of one) Io beats IIS in single transfer rates, but is likely to lose the race when it comes up to scalability.
I've pasted single transfer rates here many times before... so I guess it would be pointless, to post them once again. And what does a single transfer tell about daemons performance on real life scenarios? Absolutely nothing. It's much better to exaggerate when setting test parameters.
Parameters:
What would be good test parameters? Let's assume you're running big fileserver on 100mbit connection. And as usual, our fileserver has hardware accelerated SCSI RAID0+1, , and lots of ram to cache files on. So amount of time spent waiting for file io is negligible, and does not affect total transfer time (same as copying from cache). Userbase consists of 10000 users of which, average of 900users are expected to be online and downloading. (Total of 1800active sockets)
Test1:
Now that test parameters are known, and set so that it's possible to run the test on 'normal' computer, we are ready to go.
Set ncftpget as background process to download single file to /dev/null on remote computer. (When all clients are downloading same file, lack of hardware accelerated io or limited amount of memory do not show up in test results) You might consider to wait one or two seconds after every 100requests, so you don't spawn 1000clients that are all trying to connect simultaniously. All clients connected and downloading? Good... you have completed first part of test :)
Test2:
Now that we know that daemon is able to serve those 900clients, we'd most certainly like to know, wheter output rate is limited by daemon (software/cpu) or by network. This can be done by setting up one local transfer. If output speed for single local transfer is higher than for the average for a single transfer over network, we have proven that transfer speeds are not limited by hardware/software.
100mbit * 1024 / 8 / 900 = ~14kb/s
Each network client has ~14kb/sec of bandwidth available => local transfer should be atleast 15kb/sec.
My results:
Network clients: average 14kb/sec, filesize 435242304bytes (varies between 9 & 16kb/sec) Without local client cpu usage averages at ~22% (jumping between 17 & 26) Server doesn't feel lagged.
Local client: average 26990,55Kbytes/sec, filesize 85964896 bytes (Only transfer, that I had patience to wait until end) Result is 1800times more than required. Cpu usage at ~90%, total bw ~39mb/sec.
Conclusion:
On my hardware (Win2K3, Intel Pentium IV 1.8GHz, 512Mb, ATA-100, Intel eepro-100), throughput on 100mbit network is not limited by amount of connections or by hardware.
Other daemons?
I'm not even going to try to run tests on other daemons. Only very few of them would would be able to handle the required amount of connections, and my prior experience with sofware doesn't hint to that they would be able to outperform io (excluding IIS). If someone wants to prove me otherwise, feel free to do so.
Ps. If you actually read this thread, write some short reply, so I'll know wheter to post this kind of crap in the future... just felt like I had a thing or two to say about performance, and how to measure it :D