[Seaside] Swazoo as reverse proxy?

[Philippe Marschall]

Hi

Let's make this discussion practical:

 ab -c 10 -n 10000000
http://127.0.0.1:8080/seaside/files/WADispatcherFiles/logo.png

That fires of apache bench using making 10 million requests, 10
requests a at a time, downloading a 6 Kbyte file served from Seaside
from memory. With Apache or Tomcat I get over 100 Mbytes/s without any
tuning (Apache writes a 700 MByte log file) either serving from disk
or memory (Tomcat only). Squeak / Swazoo 2 is not close to this
number, not even in the same order of magnitude.

About the parameters:
- A concurrency level of  10 unrealistically high IMHO, since Seaside
is a very inefficient framework your application will be toast long
before that. This is more to give Smalltalk a kind of advantage.
- 10 million requests is to make sure the server can handle a
sustained load. With Squeak I have the impression that performance
degrades over time. A higher value would probably be more realistic.

Cheers
Philippe

2008/2/8, Martin Kobetic <mkobetic at cincom.com>:
> I'm getting quite a bit off topic here, but I hope others find this also interesting.
>
> Lukas Renggli wrote:
> >> So, what do you think? Is it a good idea, do you see any obstacles?
> >
> > In my opinion Smalltalk is not competitive when it comes to
> > reading/writing bytes from/to pipes, sockets and files. There are
> > other systems that can handle that much more efficiently.
>
> Why do you think that Smalltalk is inherently not suitable for the task? There clearly are examples that a dynamic language doesn't automatically doom you to worse performance than servers written in C (http://www.sics.se/~joe/apachevsyaws.html). Of course performance is also highly dependent on how much of the protocol is actually implemented. Implementation handling only the trivial basics of a complex protocol can have an unfair advantage when competing with another implementation supporting most of it. And I have to admit that I don't know if the yaws benchmarks are fair in that sense. But, my point is that Smalltalk can move chunks of ByteArrays around with pretty much the same efficiency as C (using the same library calls after all), so I don't see anything that would automatically penalize it significantly performance wise.
>
> And it's not just about speed. HTTP is pretty complicated and I don't know if there's any implementation that supports all of it. And you might be surprised to find out what is and isn't supported by popular HTTP servers. For example I was a bit stunned to find out that Apache didn't support combined chunked and gzipped transfer encoding, which I'd consider fairly basic and also practical feature for a server in apache's league. Which gets me to the main point of my blurb here, that maybe the established giants of http serving which are considered a no brainer when deciding on the deployment infrastructure aren't such a clear cut in all circumstances.
>
> And considering something like SSL support. It's been a while since I configured SSL on apache, but from what I remember it isn't exactly the pinnacle of flexibility when it comes down to SSL configuration. SSL is quite malleable and can provide some pretty useful security services, but I doubt that shows when looking at it through the apache.conf glasses. Granted, setting up an SSL server that's 100% smalltalk is a no go, in all but trivial load cases. The computational requirements of a loaded SSL server easily max out even optimized assembler. However that's just the raw speed of the symmetric ciphers and hashes, and there's much more to SSL than that. So I wouldn't be surprised if a smalltalk level protocol implementation calling out to C or assembler for the cryptographic operations on entire buffers opened up some interesting and useful capabilities.
>
> Now, that said, I'm not saying that we should start a monumental battle with apache. Apache has a lot to offer and it would be a lot of work to match that. And then there's the perpetual effort to keep up the pace with the evolution. And of course there's also a lot of value in having something that works well and that somebody else takes good care of.
>
> But I'm a bit disillusioned about the notion that "there's everything you'll ever need in apache". And I'm far from convinced that you can't build a good HTTP server in Smalltalk. So let's not stop challenging today's preconceived notions. That's what yields the best ideas of tomorrow. Wasn't there a web framework once that sprung up from the same motivations ? :-)
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>