Re: [Seaside] Re: Yes, it works - and fast too! (was [Q] File Upload/Download Server, Comanche or Swazoo)

"S.J.Chun" chunsj at
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>
   To: Seaside - general discussion <seaside at>
   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>:
> 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
>> 5-6MB/s.
>> 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)
>>   Squeak:
>>     Kom/Seaside   92  98 117 (avg 5.9MB/s)
>>     Swazoo/Aida  108 111 107 (avg 5.6MB/s)
>>   VW:
>>     Swazoo/Aida   67  68  66 (avg 9MB/s)
>> 102MB file (106.491.000 bytes)
>>   Squeak:
>>     Kom/Seaside   18  35  25  32 (avg 3.9MB/s)
>>     Swazoo/Aida   16  16  17  16 (avg 6.6MB/s)
>>   VW:
>>     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 mailing list