Re: [Seaside] Re: Yes, it works - and fast too! (was [Q] File Upload/Download Server, Comanche or Swazoo)
chunsj at embian.com
Sun Aug 3 14:34:05 UTC 2008
Though not directly related to squeak case, for perl case, we've got best
result on Gigabit network with 40-45MB buffer.
----- Original Message -----
From: Philippe Marschall <philippe.marschall at gmail.com>
To: Seaside - general discussion <seaside at lists.squeakfoundation.org>
Sent: 08-08-03 20:16:14
Subject: Re: [Seaside] Re: Yes, it works - and fast too! (was [Q] File Upload/Download Server, Comanche or Swazoo)
2008/8/3 Göran Krampe <goran at krampe.se>:
> Hi again!
> Janko Mivšek wrote:
>> Hi all,
>> Göran's work encouraged me to run benchmarks more carefully and
>> repeatably to minimize impact of OS file system performance and as you
>> can see, Kom and Swazoo are actually close in upload performance, about
>> Big apology to Squeak community for that original 1.5MB/s figure, which
>> obviously came out from only one test, instead of repeatable to avoid
>> other impacts. In new tests I didn't change Swazoo code, I just made an
>> additional upload demo on Aida.
>> Here are results in seconds of repeatable test for two files, 572MB and
>> 102MB ones:
>> 572MB file (600.037.00 bytes)
>> Kom/Seaside 92 98 117 (avg 5.9MB/s)
>> Swazoo/Aida 108 111 107 (avg 5.6MB/s)
>> Swazoo/Aida 67 68 66 (avg 9MB/s)
>> 102MB file (106.491.000 bytes)
>> Kom/Seaside 18 35 25 32 (avg 3.9MB/s)
>> Swazoo/Aida 16 16 17 16 (avg 6.6MB/s)
>> Swazoo/Aida 5 5 6 5 (avg 20MB/s)
>> As you can see for larger files we are very close while for smaller file
>> Swazoo is still faster. Also you can see that Kom results vary a lot
>> while Swazoo ones are stable. It seems that this is due to bigger amount
>> of garbage generation by Kom (this can also be seen from memory
>> consumption variations) while Swazoo garbage is minimal.
>> In any case we can conclude with quite certainty that on Squeak we
>> reached the upload speed limit near 6MB/sec. To be faster we will need
>> to optimize TCP socket and file VM modules.
> Hmmm, ok, I did two more things:
Could you put these in a new version of Kom, let's say KomHttpServer-gk.32?
> - Refactored away one buffer copy. Now the Kom code copies straight from
> the SocketStream inBuffer into the FileStream.
> - Raised the buffer size from 1 Mb to 10 (or 20, 30, it does improve
> numbers with a large buffer).
That sounds a bit extreme. We're talking about allocating a 10Mb
buffer for each upload, right?
More information about the seaside