Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!newsfeed.internetmci.com!howland.reston.ans.net!nntp.coast.net!lll-winken.llnl.gov!osi-east2.es.net!cronkite.nersc.gov!qiclab.scn.rain.com!slc.com!servio!news
From: cohenb@slc.com (Bruce Cohen)
Subject: Re: The role of Smalltalk on a Server
In-Reply-To: mikej@justv.rchland.ibm.com's message of 8 Jan 1996 22:16:58 GMT
Message-ID: <COHENB.96Jan11101707@topdog.slc.com>
Lines: 87
Sender: news@slc.com (USENET News)
Nntp-Posting-Host: topdog
Reply-To: cohenb@slc.com
Organization: GemStone Systems, Inc.
References: <4ce8nh$rdp@locutus.rchland.ibm.com> <30EACE66.5D8A@bridge.bellsouth.com>
	<gollmann-0401961018270001@go.edvz.tuwien.ac.at>
	<4cjvhv$10ap@locutus.rchland.ibm.com> <marcs.821055386@servio>
	<4cs54q$605@locutus.rchland.ibm.com>
Date: 11 Jan 1996 18:17:07 GMT

In article <4cs54q$605@locutus.rchland.ibm.com> mikej@justv.rchland.ibm.com (Michael Jacobs) writes:

> Marc, Thank you for the overview of GemStone.  I am even more curious
> now to understand how a GemStone application scales to 1000's of
> users.

To be absolutely fair, you can't take an arbitrary Smalltalk program and
stick it into GemStone and expect it to perform well with 1000 users
executing it, especially if many of them are modifying object state as
well as accessing it.  There are aspects of the application schema that
become very important when you're sharing objects in a high-volume
environment.

What GemStone does is, first, make it possible to scale by providing a
concurrently-shared, transactionally-protected, image that can scale,
and second, give you some tools to handle the bottlenecks in your
schema.

> When I was thinking about the scaling problem, I was thinking about
> how a single computer could scale.  I would guess that a typical
> business application would result in an image size measured in
> megabytes.  I would conclude from this that one simply cannot have a
> copy of the image running for each user and still obtain a scale
> beyond 10's of users before a single system would run into paging
> problems.  The distributed Smalltalk solutions alleviate the paging
> problems by providing a shared image on t

It's unlikely (though not impossible) that any Smalltalk application is
going to run 1000 users on a single computer.  The worst case I know of
for GemStone is an application that runs a several hundred user object
server on a large SMP Unix machine, and does user interface to X
terminals.  Most application developers use multiple machines to split
the load.

GemStone partitions an application into client and server parts, and
allows the client Smalltalk image, the client's view of the server
Smalltalk image, and the server manager processes and object repository
files to live on separate computers.  A common situation is to run all
the server-side parts on one or more large Unix machines, and run each
client on a separate PC or Mac in the user's office.

> ver. This further assumes that the server Smalltalk is implemented
> similar to the client in that the virtual machine is a shared resource
> (ala DLLs on OS/2 and Windows) and the image is private for each user.
> Somehow, this approach must be abandoned to achieve a large scale
> solution.
> 
> [Q] What approach is taken to scale so large?  Multiple mid-tier
> servers?  Sharable images?

Each of the clients is a separate, unshared Smalltalk image. The
client's working area on the server is part private memory (for the
stuff the client has modified and is currently working on) and part
shared memory (for the stuff that all clients see as the same).  Objects
that are not actively being accessed are kept on disk; the memory area
used by the server image is actually a fixed-size cache for an image
that's as big as you have disk for (and the disk can be distributed
across many computers on a network).  In addition, the set of
server-side processes can be partitioned across multiple computers, with
one shared-memory cache for the images on each computer.

Each client has a transactional view of the shared image; when that
transaction is committed, GemStone automatically updates the client's
view so that it's consistent with the committed state of the shared
image (and uses as much of the shared memory as possible, for
efficiency), while merging in the changes the client has made to the
image.

The key to performance is partitioning the application, putting the
right objects in the client and the server so as to optimize for the
size and power of the computers involved and the capacity of the network
and number of users and mix of activities.  A general rule is to keep
the user interface objects in the client image and move the model
objects into the server; this tends to solve the 'fat client' problem,
and allow easy sharing of the model objects.

See our webpage: http://www.gemstone.com for data sheets, white papers,
and contact information if you want more details than I've given here.



-- 
-----------------------------------------------------------------------------
Bruce Cohen,                                 |   email:  cohenb@slc.com
GemStone Systems, Inc.                       |   phone: (503)690-3602
15400 NW Greenbrier Pkwy, Suite 280          |   fax: (503)629-8556
Beaverton, OR USA 97006                      |   web: http://www.gemstone.com
