Products

Price/Order

Support

Partners

Testimonials

Test Results

About us

Contact
 Download speed comparisons
Bottom
 
Total posts: 11
 Author Download speed comparisons
Sebastian Zierer

26.09.2006 21:00:32
Registered user
Today I did a speed comparison when downloading big files in between IIS and rtc. The average download speed from IIS is about 180kb/sec, but with rtc I only get about 120kb/sec. I did this experiment several times, and IIS always appears to be about 20-40kb/sec faster. If I change MAX_SEND_BLOCK_SIZE to 1440*44 then I can get about 150kb/sec in rtc. But I couldn't find a value that gives me the 180kb/sec.

I did the speed measuring with GetRight and it can be seen in the speed graph very clearly. I basically paused the download, stopped IIS and started rtc and resumed the download. Then I went back to IIS and got the higher download speed again. I did this a couple of times and there was an obvious trend that IIS appears to be faster.

Well, maybe it is hard to compare download speeds when there is a lot of other activity in the internet. So I'm a bit reluctant to say that IIS is faster. But since you're so much into speed, I'd suggest that you try this as well and see if you get similar results.
Jerry Hayes

26.09.2006 22:31:49
Registered user
Sebastian,

May be a silly question, but is it the same server, same machine and sime file?
Sebastian Zierer

27.09.2006 06:46:12
Registered user
The server/machine is the same. I have two copies of the same file on the same hard drive, but I don't think this could be the reason for the difference.
Danijel Tkalcec [RTC]

27.09.2006 07:31:47
Registered user
1) To stay fair, you will need to use the exact same file, run the test inside your LAN and do it one-after-another (download the complete file from IIS, then RTC, then IIS, then RTC and use average results), since (a) hard drive access and (b) internet activity have a BIG impact on the speed.

2) MAX_SEND_BLOCK_SIZE parameter in the rtcFileProvider unit defines in how large blocks the file will be read from the drive, but it doesn't define the size of the chunks in which the data will be sent out to WinSock API. As you can see, drive access has a large impact on speed (reading more data at once already gave you better performance).

3) What you are looking for are parameters in the WSocket_rtc.pas unit:
 // Buffer used by WinSock to buffer outgoing data
  WSOCK_SEND_BUFFER_SIZE:integer=WSOCK_PACKET_SIZE*44;
  // Buffer used by WinSock to buffer incoming data
  WSOCK_READ_BUFFER_SIZE:integer=WSOCK_PACKET_SIZE*44;

  // max number of direct send loops (to speed up sending)
  WSOCK_MAX_DIRECT_SEND_COUNT:integer=2; // 20;

  // Max packet size sent out at once
  WSOCK_MAX_SEND_SIZE:integer=WSOCK_PACKET_SIZE*44;

You can experiment with those parameters to see what gives you the best performance and post the results of your tests here. I've set default parameters to use 64 KB buffers for sending, 64 KB for receiving and max 2 direct loops (each additional loop will require a few more bytes on stack and block the thread to one connection), since that's what I found to be an aceptable trade between memory requirements and performance, so that the Server can handle a few thousand active connections with 500 MB RAM.

Btw ... I'm not sure what you mean by "since you're so much into speed". Having optimized code doesn't mean you will get the highest performance when sending large files, it means your CPU usage will stay low with a high number of active connections. To get more bandwidth usage (better performance with large file downloads), you need to use more buffers, read larger file chunks, keep the file open while sending (check the implementation from Jerry Hayes) and allow more direct loops (avoid idle times waiting for windows messages between blocks) - all of which you can temper with in RTC (if you are so much into speed).

For me, things that matter the most are: (1) response times with normal sized data (99,9% of all packages will be below 64KB), (2) server stability and (3) the ability to serve several thousand active connections without problems (in case someone should try to flood the server with requests) - all of which I've tested thoroughly.

On a different note ... what is keeping you from using IIS?

You know that you can compile your RTC applications as ISAPI extensions and nobody is forcing you to use the RTC WebServer. If you need to serve large files and you want everyone to get max bandwidth possible, but you can't get that from a stand-alone RTC WebServer, take IIS. I don't mind. As for me, I'd rather have a Server I can rely on, even if it doesn't squeeze the last drop from my bandwidth for each connected user.

Best Regards,
Danijel Tkalcec
Danijel Tkalcec [RTC]

27.09.2006 10:55:00
Registered user
I've done a few tests now downloading a large file (60 MB) by using different parameter settings with the RTC WebServer and compared the results to IIS 5.1

With the RTC WebServer using the standard settings (64KB buffers), I got somewhere above 150 MBits (megabits, not kilobits) download speed over localhost. After increasing RTC setting to use 128KB for all sending buffers, I got the speed above 180 MBits, and ... the best performance I got with a RTC WebServer on my PC (1 GHz CPU) running on localhost was arround 200 MBits. The same file downloaded with IIS 5.1 on localhost went through with 200-210 MBits.

The most important difference in the current RTC implementation is now that it uses a non-blocking implementation, while IIS uses IOCP. I guess I could implement a new low-level socket layer to use IOCP instead of the current non-blocking async communication, but ... I'm not that much of a speed nerd (as someone might think), so I will leave this for RTC SDK 3.0 and invest my time in more useful things.

If you need the highest possable throughoutput for sending large files out (which will rarely be the case for any business application), you can compile your RTC applications into ISAPI extensions and use IIS as your WebServer.

Best Regards,
Danijel Tkalcec
Sebastian Zierer

27.09.2006 11:14:37
Registered user
Changing the params in WSocket_rtc.pas doesn't seem to change much. The best value for MAX_SEND_BLOCK_SIZE in rtcFileProvider seems to be 65536. Then I can get download speeds of 160kb/sec. This happens to be the same as the address space allocation granularity in Windows. So my theory about the lower speed is that some memory blocks need to be split up into two blocks and then later they will be put together again. Reading those 1296kb more each time greatly enhances speed, but reading a few kb more makes things worse than before.

File access speed doesn't seem to be an issue. If I create a buffer in memory instead, then I will get the same download speeds.

Well, I could use IIS for file downloading, but somehow I like rtc better. And for small files speed is excellent! Maybe there is another performance bottleneck that is just waiting to be found :-)
Danijel Tkalcec [RTC]

27.09.2006 11:28:42
Registered user
Since I get 150 MBit/s on localhost and 80 MBits between my 2 Internet Servers when using default RTC settings, the only bottleneck I see is non-blocking WinSock.

Also, there are two things you should consider:

1) Your results seem to be different from mine, since in my case it DOES make a difference when using larger buffers and reading more data at once. Could it be you are using Delphi 2005 or older and aren't using FastMM? The old RTL MM is always a bad thing in a Server, you should avoid it like a plague.

2) You've mentioned having a Server on the Internet now and you wrote in one E-Mail during the RTC WebServer load-test that your home Internet connection speed was 260 KB/sec, but you "only" got 230 KB/s from "www.realthinclient.com" during the load-test (while 100 other people were downloading files from the Server, with 350 active connections). Maybe you should check your Web hosting Service provider to see why you can't get more than 180 KB/s from your Server with IIS? Or did you expect to get only 180 KB/s from that Server?

Best Regards,
Danijel Tkalcec
Jerry Hayes

27.09.2006 12:01:08
Registered user
I think the fastmm is a great point.

Not sure how IIS handles it, but I know the RTC file libs open the file for each read; I've got some file libs that open the file once at the beginning and then close the filestream on transfer stop.  I did get some improvements with these.
Danijel Tkalcec [RTC]

27.09.2006 12:09:52
Registered user
Jerry, thanks for the pointer.

I've applied your approach now to the rtcFileProvider implementation, so that you can choose between using the old RTC approach (files being opened/closed for each read access) or using your approach with a file stream (opening the file on start and closing it when complete response is out or client disconenected). That's the approach which gave me 200 MBits throughoutput on localhost with the RTC WebServer, but I still had to use 256 KB buffers (with 64 KB buffers, I got 160 MBits when leaving the file open).

I made this as an optional compiler directive inside the "rtcFileProvider.pas" (disabled by default), so anyone who wants to keep their files open while they are being sent out can do it now with the standard rtcFileProvider implementation. I will upload this as the next RTC SDK 2.0 update, once I have a few options for the "Session lock" implemented (later today or tomorrow).

Best Regards,
Danijel Tkalcec
Sebastian Zierer

27.09.2006 12:17:01
Registered user
1) I'm using Delphi 2006 SP2 + Hotfix Rollup.

2) I get 230kb/s when I use GetRight with multiple connections. If I download Turbo Delphi from your server with one connection only, then download speed will be about 120kb/sec.
Danijel Tkalcec [RTC]

27.09.2006 12:44:51
Registered user
1) The only thing that is different in RTC than IIS is the API used. RTC uses async non-blocking WinSock, while IIS uses IOCP. If there was anything else (like badly written code), I wouldn't be able to get 150 MBits on localhost or 80 MBits inside LAN.

2) I get 214 KB/s when I download from my WebServer using a single connection over my home internet line (2 Mbits = 250 KB/s), so it's a relative thing. Your ISP could have a cap per connection or something else could be struggling your bandwidth. What performance do you get when using GetRight with your Server?

Did you run tests with RTC WebServer and IIS inside your LAN to see what performance you can get there and how much memory and CPU each of them uses for what performance?

Btw ... you will probably get higher performance when downloading a large file from a Server using Indy than you will get from the RTC WebServer, since Indy will push the file through as fast as it can, blocking a thread until it's completed, while RTC takes in account that there could be a few thousand other connections which also want "a piece of the cake", so it won't be blocking a thread for each active connection, but use a thread-pool and try to give all connections a fair chance to get what they came for.

There are a lot of ways one can handle communication and there are good and bad sides to every story. I chose the non-blocking approach, to get a Server which can handle virtualy unlimited number of connections, without bumping into Windows limits (like the max 2.000 threads limit).

I am considering the implementation of a new low-level socket layer using IOCP, but since that will not give you more than a few percent extra performance for sending large files out (which is not someting your Server will do very often), while putting a considerable ammount of workload on me (not to mention testing of a completely new low-level socket layer), I have decided to put this aside and work on things I find important, like ... keeping my customers happy by adding things they can use (XML-RPC, for example), instead of tryging to winn a silly performance race with IIS - especially since you can use the IIS WebServer for powering your RTC applications, as well as any other ISAPI-capable WebServer.

Best Regards,
Danijel Tkalcec