[Seaside] Swazoo as reverse proxy?
mkobetic at cincom.com
Fri Feb 8 20:27:59 UTC 2008
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 ? :-)
More information about the seaside