Faith of Correspondents?

Bijan Parsia bparsia at email.unc.edu
Thu Nov 11 19:58:46 UTC 1999


On Thu, 11 Nov 1999, Lex Spoon wrote:

> Okay, I've got so much email, maybe this has already been addressed, but
> this pushes my buttons.

I'm going to feel free to push again.
 
> Bijan Parsia <bparsia at email.unc.edu> wrote:
> > Right now, it's *impossible* to write a web
> > server/web application that can handle multiple simlultanous requests
> (at
> > least, on the mac). 
> 
> Why can't it?  I just tried, and I'm downloading two different versions
> of osprocess off of the Squeak swiki, which is running on a mac.  Both
> download progress bars are updating simultaneously.

We're the *requests* truely simultaneous? Yes, the *serving* can happen,
but there is a period after receiving a request wherein the sever refuses
connections. C'mon. We see this all the time on the Squeak Swiki (which
has multithreaded PWS processing, so *that's* not what's causing
difficulty).

> > *That's* intolorable. But it's *still* a hard sell if
> > Squeak can't *well* handle the demands that something like (at least,
> > earlier versions of) WebStar could handle, at least *in principle*.
> 
> Why does Squeak have to be like WebStar?

*Earlier* versions of WebStar. And it doesn't. Indeed, it shouldn't. But
there is a minimal level of functionality necessary. That's all I meant. I
picked WebStar because it's actually written to an architechture like
Squeaks (i.e., the MacOS, with mostly cooperative threading, the use of
applescript cgis, etc.).
 
> The strength of a Squeak server, in my opinion, is that it's easy to
> write reasonably efficient programs for.

That's the hope, yes. That's what I'm trying to specify--what's reasonably
efficient. (Preferable on older hardware too.)

>  PWS is very similar in
> architecture to servlets and the python_module which are getting so much
> buzz, and it's good for the same reasons that those things are: it's
> easy to program to, and you end up with something that's pretty
> efficient (no new OS processes).

Yes. That's what I'm after. That's why I like it. But that hasn't happened
yet, *for me* on the Mac. Now, I haven't set up the latest Squeak, so my
data may be dated (except, of course, the mac prims haven't changed, and
we had that *weird* UI slowdown on 2.2-2.5, at least, on the windows
side--it was *real*, it just didn't manifest for everyone. And I had the
thread blowout problem on win95 and vm 2.1. So, I love the system, but
it's not rock-solid no-brainer, *yet*.)

> 
> 
> > And
> > 24x7 decent performance for small to medium sized websites should be a
> no
> > brainer, at least for simple stuff (static page serving). 
> 
> We've pretty much got this.  Performance on the swikis is quite fine
> except when:
> 
> 	- the OS flat out runs out of sockets (what can you do then?)
> 	- you do a search on a swiki, or a recent changes on a large swiki
>
> Neither of these has to do with networking.

Or when two simultaneous requests occur (on a mac). Multithreading the
serving/processing process *should* take care of the "search" problem. If
it doesn't, why not? Why is a *search* screwing up the acceptance of
connections (if it is?). Now, if the *searching* connection just times out
before the search completes, fine. Is that what you meant? But unless the
load is *insane*, *other* connections shouldn't time out, yes?  

I don't know about the socket consumption issue--but I thought you
measured disproportionate socket consumption. (But how does the system run
out of sockets? I thought it couldn't. It's not like file descriptors,
right? You can run out of space on the acceptance queue, and that *is* a
networking issue.)

> For the servers used by a few thousand people, Squeak has proven to fare
> extremely well.

Lex, *some* servers have. I've run servers for a lot less than a few
thousand people and had trouble. Newer, faster hardware helps a lot. It
covers up a multitude of sins, and perhaps makes them (For that hardware)
non-sins.

>  It's not really known how much higher it would scale. 
> Thus, while making things faster is always nice, let's remember that the
> current situation is plenty fast for most people's purposes!

Look, I'm not, and I didn't, argue that we should aim for speed above all
else. I'm just looking at the state of the art of a net generation ago,
and saying, Hey, we should be able to do that relatively, and that's
plenty of capacity for most needs, *so long as* it doesn't drop off too
quickly as one adds functionality. The latter issue *should be* a
framework issue, not a core networking issue. It's not clear to me that it
*is* that way, yet.

For example, with a room of about twenty, all with netted computers in
front of them, I tried to demonstrate the swiki. They managed to kill it
hard by lots of folks trying to get pages at once, and clicking multiple
times when it didn't work. No. That's shouldn't happen with 20 people. 20
people shouldn't be sufficent to Slashdot a server ;)

It's *peak* use that's the problem right now. And there has to be enough
speed and flexibility in the raw system to handle inefficiencies of at the
programmer's level. I.e., I should never have to worry about ListenLoop :)

.....Ok, I guess you pushed *my* button's, too :)

Cheers,
Bijan.





More information about the Squeak-dev mailing list