Swazoo as reverse proxy?

Hello Web Smalltalkers,

I'm thinking for a while to add a reverse proxy support to Swazoo so
that we won't need Apache anymore, at least for all but the very large
websites. And such "all but" sites are probably 99%, and that means that
Swazoo is able to serve those 99% of our sites, but you could safely
switch to Apache later when needed.

Another advantage is that you are running everything in Smalltalk and
have therefore a control down to the last bit sent to the TCP socket.
Not to mention that you don't need to learn some other setup like
Apache, which is not the easiest thing to learn.

Reverse proxying will also allow load balancing of many images behind
the Swazoo, or run many different sites, each on its own image, etc.

So, what do you think? Is it a good idea, do you see any obstacles?

Best regards
Janko


--
Janko Mivšek
Maintainer of Swazoo
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> 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.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>>>>> "Janko" == Janko Mivšek <[hidden email]> writes:

Janko> I'm thinking for a while to add a reverse proxy support to Swazoo so
Janko> that we won't need Apache anymore, at least for all but the very large
Janko> websites. And such "all but" sites are probably 99%, and that means
Janko> that Swazoo is able to serve those 99% of our sites, but you could
Janko> safely switch to Apache later when needed.

I've wanted this, although just for testing.  I really would like to be able
to test "in the small" completely with Smalltalk, and then deploy "in the
large" with an Apache reverse-proxy instead.

Removing Apache while testing would be useful to me.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

As a data point, we are currently moving from proxying apps with apache to F5 balancers, I would never want to have a net facing server actually be in the image that runs my app, I just don't want to reinvent the wheel in terms of load handling, balancing and security.

Cheers!

-Boris (via BlackBerry)

----- Original Message -----
From: [hidden email] <[hidden email]>
To: Seaside - general discussion <[hidden email]>
Sent: Fri Feb 08 06:23:52 2008
Subject: Re: [Seaside] Swazoo as reverse proxy?

> 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.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 2/8/08, Janko Mivšek <[hidden email]> wrote:

> I'm thinking for a while to add a reverse proxy support to Swazoo so
> that we won't need Apache anymore, at least for all but the very large
> websites. And such "all but" sites are probably 99%, and that means that
> Swazoo is able to serve those 99% of our sites, but you could safely
> switch to Apache later when needed.

Does Swazoo support SSL connections?  If not, I would say it's not
worth it, since you'll need some external service to provide
HTTPS->HTTP proxying.

Avi
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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.

Swazoo is not there to compete with Apache, but to help our web
frameworks to easier compete with other frameworks. As we are proud on
Smalltalk as a simple dev.environment yet able to cope with most complex
problems, let be proud for our web stuff too, and here the Swazoo's role
is to preserve that simplicity. Namely, simplicity is one of biggest
reasons why we are competitive to others.

But let me repeat, not for everything, because after Swazoo stops to be
performant enough, you can always switch to Apache. So, you start simple
with Swazoo and have an open path to the most demanding web serving with
Apache or other web servers.

Apache is more performant, no doubt, and will always be, but that's not
the point, the point is that for most of our web server needs Swazoo is
just good enough, but much simpler for Smalltalkers to use than Apache.

Janko

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Boris Popov wrote:

> As a data point, we are currently moving from proxying apps with apache
> to F5 balancers, I would never want to have a net facing server actually
> be in the image that runs my app, I just don't want to reinvent the
> wheel in terms of load handling, balancing and security.

That's actually one of main goals: running a Swazoo reverse proxy in a
separate image to isolate web facing server from actual web apps.

Best regards
Janko


--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Don't get me wrong, but aren't you setting yourself on the path of having to re-implement much of Apache and Co?

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Avi Bryant wrote:

> Does Swazoo support SSL connections?  If not, I would say it's not
> worth it, since you'll need some external service to provide
> HTTPS->HTTP proxying.

Swazoo 1 on VW supported it while Swazoo 2 not yet. But I would say SSL
is a special case, one of which then justifies use of Apache from the start.

Best regards
Janko



--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Boris Popov wrote:
> Don't get me wrong, but aren't you setting yourself on the path of having to re-implement much of Apache and Co?

Not everything, just most needed stuff, for us Smalltalkers, that is :)

Janko


--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Janko Mivšek ha scritto:
>
> Boris Popov wrote:
>> Don't get me wrong, but aren't you setting yourself on the path of
>> having to re-implement much of Apache and Co?
>
> Not everything, just most needed stuff, for us Smalltalkers, that is :)

Isn't that a little too NIHish? ;)

I was thinking of steering KomHttpServer in the opposite direction
instead: not a full fledged webserver, just something that allows you to
create dynamic HTTP content from a Squeak image.

        Giovanni
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Giovanni Corriga wrote:
> Janko Mivšek ha scritto:
>>
>> Boris Popov wrote:
>>> Don't get me wrong, but aren't you setting yourself on the path of
>>> having to re-implement much of Apache and Co?
>>
>> Not everything, just most needed stuff, for us Smalltalkers, that is :)

Besides that, everybody re-implements themselves all the time. Did not
Apache redo much of what it did when going from 1 to 2? Are they not
continuing to do so as they seek to improve themselves?

As Apache and any other tool continue to develop, adding features,
removing cruft, rewriting things better, they to overtime have rewritten
much of what was, is and will be. :)

I believe that many such things if they were in Smalltalk would
ultimately be much more maintainable and hopefully capable.

If Apache, et al., were all written in Smalltalk, bug fixing, security
auditing and fixing of security problems, etc. would be much easier.

Most of us are here because we believe that Smalltalk is a superior
language and environment to model and develop simple and complex
applications in. If that is not so, then why are we here?

The world of software is a moving target. Apache is not standing still,
nor is Apache alone in the world of web servers. Nor has development of
other servers ceased because we have a quality web server in Apache.

So why should we not continue to improve the tools that we have control
over, can fix bugs in, etc.? Does anyone here wish to audit Apache for
bugs or security problems? No. Does Apache have bugs and security
problems? Quite possibly. Software isn't perfect.

> Isn't that a little too NIHish? ;)

I don't think so. There are advantages to having things implemented in
the language or environment you use. It isn't so much that Apache wasn't
written by our community but rather isn't natively usable by our natural
tools and environments. There is tremendous benefit and synergy for
staying in the Smalltalk environment and tool chain. Swazoo provides for
the Smalltalk developer capabilities that Apache does not.

I am not a professional programmer. I have limited time to study, learn,
use the software tools at my disposal. I am greatly advantaged to be
able to stay in Smalltalk. Everything I learn is applicable to anything
else I do. Not so with learning, Python, Django, Plone, Apache, wsgi,
PostgreSQL, subversion, Squid, Varnish, Memcache, and on and on. Just to
mention some other available options.

We have the option of learning from others successes and failures.

Swazoo doesn't need to be Apache. It doesn't need to interface with any
other languages. There are many Apache features that are not relevant
when web serving is kept in the Smalltalk context. But within that
context we can be reasonably competitive with most anything that Apache
and ???? have to offer.

Swazoo would have the advantages of being smaller and simpler in
implementation to Apache, et al., while offering similar feature to
users of Smalltalk. Thereby providing us with a solution that is better
for auditing and securing.

Then there is the oft heard argument even here in the Seaside list,
premature optimization. I will argue that it is often premature
optimization to go with Apache.

What does Apache buy us? Performance, security.
Performance, we'll grant you. But if that is the sole reason, then you
may be optimizing prematurely.
Security. Apache should be reasonable secure. But are you saying Swazoo
is not?

Apache is a very complex piece of software. Security is not a guarantee
just because you use Apache.
http://httpd.apache.org/security_report.html links to several pages with
security vulnerabilities in Apache.

Even Apache 1.3 still has things being discovered.
 Update Released: 19th January 2008
 Affects: 1.3.39, 1.3.37, 1.3.36, 1.3.35, 1.3.34, 1.3.33, 1.3.32,
1.3.31, 1.3.29, 1.3.28, 1.3.27, 1.3.26, 1.3.24, 1.3.22, 1.3.20, 1.3.19,
1.3.17, 1.3.14, 1.3.12, 1.3.11, 1.3.9, 1.3.6, 1.3.4, 1.3.3, 1.3.2,
1.3.1, 1.3.0

And this is on a piece of software very old and reasonably locked down.

I have great respect for Apache and would not rule out using it. But
neither do I believe that its use is expected, anticipated or required
justs because it exists and is a common default web server.

Enough ranting and rambling.

Smalltalk enables people in ways that other software does not. The more
we can remain within our enabling technology and accomplish the things
we seek to do the better. When we have to step out in order to be
enabled then fine. If not, then why?

I just believe that with Smalltalk we can often do better than what
currently exists. If we have someone willing and able, then we ought to
cheer them on. It improves and enhances our ecosphere, not diminishes
it. Nor does it diminish the accomplishments of Apache or any other such
software NIH. (NIH could be read in this context, Not Implemented Here)

Whew!

Jimmie
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

"Janko Mivsek" <[hidden email]> wrote

> So, you start simple
> with Swazoo and have an open path to the most demanding web serving with
> Apache or other web servers.

For a newbie like me, a simple easy way to start is a big plus. Without
Comanche and WAKom I might not even have gotten started with Seaside. If it
can serve static file-system content even better. If it continues to work
well into small deployments, even better. Simple browser-based front-end for
common configuration, better still :-)

+1 from folks like me.

Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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 <[hidden email]>: _______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Feb 9, 2008 12:20 AM, Janko Mivšek <[hidden email]> wrote:

I like it, and I'd use it.

Whilst NIH is something to be wary of, dogmatic avoidance of NIH can result in the stifling of innovation, and software mono-culture.

Regards,
Stuart.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 2/8/08, Janko Mivšek <[hidden email]> wrote:

> So, what do you think? Is it a good idea, do you see any obstacles?

For what it's worth: what would be most interesting to me is a proxy
that could cope with a very dynamic set of backend servers.  For
Dabble DB, for example, there are 10s or 100s of thousands of
potential backend webservers (Squeak images), which might be
added/removed/moved at any time, most of which won't be running (and
so need to be lazily started if a request comes in for them), and
which may shut themselves down again at any time without notice.  An
effort in the Ruby world that comes closer to what we need that
anything I've seen is SwitchPipe: http://switchpipe.org/ .  However,
it has the same problem that many proxies do, which is to assume that
there is a finite and static set of backend services, and require a
configuration file for each one.

If this kind of thing could be done in clean Smalltalk code rather
than in the mess of Apache rules and scripts we have now, it would be
great.

Avi
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> But let me repeat, not for everything, because after Swazoo
> stops to be performant enough, you can always switch to
> Apache. So, you start simple with Swazoo and have an open
> path to the most demanding web serving with Apache or other
> web servers.
>
A smooth way to scale. Its a welcome option,

        cheers,

Sebastian

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2008/2/8, Giovanni Corriga <[hidden email]>: That's the way to go IMHO.That's what people use it for.

Cheeers
Philippe

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > I was thinking of steering KomHttpServer in the opposite direction
> > instead: not a full fledged webserver, just something that
> allows you
> > to create dynamic HTTP content from a Squeak image.
>
> That's the way to go IMHO.That's what people use it for.
>
> Cheeers
> Philippe

+1, it's just too easy to install Apache to serve all the static content and
non Smalltalk stuff.  No need to take on Apache, better to recognize Squeak
as a small part of the overall platform and keep the server as simple as
possible.

Ramon Leon
http://onsmalltalk.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside