Scalability

I am investigating Smalltalk (esp. Squeak) for web development. I am new
to Smalltalk.

I know it is early yet for Swazoo to determine performance and
scalability. However, I would like to ask a question.

What options are being or will be pursued for scaling websites built
with Swazoo? Will there be options for distributing processes.

How will Swazoo handle a very busy website. While no one can insure
(predict) the success of a website and how many hits it will get. No one
wants to insure it's failure by it's inability to scale to handle the
volume.

This isn't meant to say anything about Swazoo. It's just an exploratory
question attempting to learn about Swazoo and where it is heading. I
think it would be wonderful for Smalltalk to have an excellent and
scalable tool for developing websites.

Any help appreciated.

Jimmie Houchin

Hi:

Welcome.

Unlike other languages, the cost of change in Smalltalk is low, and with
the proper methods (XP), it remains fairly constant.  What that means is
that we can follow some simple rules to insure the system starts out on the
right foot, and can change it safely and radically as needed.  In ST, we
usually start with 3 simple rules:

1. Make it work - get the basic model functioning
2. Make it right - enforce all of the business (or system) rules
3. Make it fast - if we need better performance, profile execution,
redesign and rebuild, which aren't expensive in ST.

That might give you a glimpse inside the ST development process.  Couple
that with the XP rules and you have a flexible and extensible system.

To touch upon some of the specifics, ST is a very mature
development/execution environment that has lots of tools to do system
tasks.  All of the dialects offer different tools and I am only familiar
with the tools offered in VisualWorks, GemStone/S and to a lesser extent,
VisualAge.  In VW for example, there is ST to ST communication facilities
that use IIOP to do some incredible distributed stuff.  If you haven't seen
it, it's worth the download.

As to scalablity, EZBoard is an all ST site that gets ~4M page views per
day.  Those folks wrote their own, and Swazoo isn't there, yet. ;-)
However, it does show that you can run a high volume site in all
Smalltalk.  They run on Linux-Intel, FWIW.

Good luck with your explorations!  I'm sure other team members will have
more to say.  Cheers!

Jimmie Houchin wrote:

--
Thanks!!

Joseph Bacanskas [|]

--- I use Smalltalk.  My amp goes to eleven.

Hello, thanks for the reply.

I am coming from a Zope/Python background. I have studied Java some but
really don't like it.

I am very pro open source software but do not necessarily have anything
against commercial software. Squeak is my first experience with
Smalltalk, and I haven't done much with it other than read the parts of
the Squeakbook. I'll be ordering some Smalltalk books soon.

The creator of Zope is a Smalltalk fan. Zope has some characteristics of
Smalltalk. Zope has an object database in which it stores all of it's
Zope objects. It encourages keeping all of the website development
within the ZODB which could be seen as similar to an image. However
because Python does not use such a system or have such a philosophy Zope
itself is partially within the ZODB and partially on the filesystem.
Also the development tools aren't up to Smalltalk standards.

I am downloading VisualWorks now to take a look at it.

Since VisualWorks has VisualWave why would someone choose Swazoo over
VisualWave for web app development? What are the differences? Can they
be used together?

One primary concern I have with VisualWorks is if I develop my site with
VisualWorks, what will deployment costs be? Since those are not
publically available, it is unknown.

The reasons you mention below are what draw me to Smalltalk and also to
web development with Smalltalk.

If I can transparently distribute processes in order to scale a website
that would be great. It seems VisualWorks offers that from what I can
see. I don't know yet where Squeak/Commanche are on that yet.

I look forward to seeing the fruit of this project.

Hopefully someday I could be a productive member here. :)

Thanks again.

Jimmie Houchin




Joseph Bacanskas wrote: [snip original message]
> --
> Thanks!!
>
> Joseph Bacanskas [|]
>
> --- I use Smalltalk.  My amp goes to eleven.

In general, the main path towards scalability is ensuring that you can have
multiple servers without needing cross-communication between them. Within a
single server it's nice to have good performance, but for high-end
scalability it's far more important to be able to add an indefinite number
of servers without the load on each growing in proportion to the number of
servers. IMHO the best way to do this is outside of the app server. We try
to maintain statelessness in the server, and use round-robin DNS or a
front-end load-balancer to distribute the work.

At 07:47 PM 10/25/00 -0500, Jimmie Houchin wrote:
>Since VisualWorks has VisualWave why would someone choose Swazoo over
>VisualWave for web app development? What are the differences? Can they
>be used together?

The current implementation of VisualWave is built around the paradigm that
you paint a GUI using the standard (although augmented) VisualWorks
client-server tools and VisualWave will generate HTML automatically from
that. This is very cool functionality, but is primarily useful to those who
already have existing VisualWorks applications.

Swazoo at the moment consists primarily of a front-end HTTP server into
which multiple back ends could be plugged. The most complete back-end right
now is AIDA, which has the paradigm of using objects assembled by
programmers into page constructs that then generate HTML. Kind of like
building DOM trees programmatically, although at a higher level. IMHO this
is very cool for programmers, but also not the way the majority of web work
is done today.

Real soon now Wave may be able to support the paradigm in which pages are
built using standard HTML tools, with the ability to include special tags
and/or code within them that specifies information to be supplied/used at
the server end.

As I understand it, Swazoo really wants to be the primary web server. Wave
can act directly as a web server, but is more likely to be deployed as a
back-end to some other web server (Netscape, IIS, Apache). This is for both
political reasons and for performance (we can let the web server serve
static pages, GIF's, etc directly without going through Smalltalk).

Swazoo and Wave currently don't work together. I would like that to change.

>One primary concern I have with VisualWorks is if I develop my site with
>VisualWorks, what will deployment costs be? Since those are not
>publically available, it is unknown.

The current set of licenses comes in three categories, which I will roughly
describe in my incomplete understanding as follows
"standard client-server users" - (small) per end-user deployment charge.
Most appropriate for big companies developing internal apps. Unlikely to be
appropriate for web stuff.
"VAR" - basically a distributor agreement, free up-front but with a
negotiated percentage of revenue downstream. Currently used for third-party
developers as well, although it has some issues there.
"server" - free up-front, per-server deployment fee. This is the one that
makes the most sense for web applications.

Cincom does not publicize these, but they're not particularly secret. You
can get the information fairly easily by talking to a sales rep. Yes, this
is sub-optimal. We're working on it.