Server scaleability

[andy.burnett]

Do you have any metrics for scaling the servers? I realise that this is always a difficult problem to define, but I need some sense of whether the System Requirements as defined elsewhere on this site, support 10 users, 100 users or 1000 users.

The sort of applications I am looking at could best be thought of as threaded discussions. There will be an initial hit of the discussion threads being downloaded (although I am obviously guessing at the design at this stage). Then a lot of browsing around, and a smaller amount of writes back to the server.

Thanks
AB

[bloch]

Hi AB,

We've done some simulation studies here
recently. The results I can share
with you are from our in house builds
of the LPS (not LPS DR).

There are a few basic things in a Laszlo
app that will effect scalability and
server performance.

1) Application size
uncompressed
gzipped

2) Runtime data accesses
size
distribution

3) Runtime media accesses
size
media type
distribution

4) % of firsttime app accesses

At some point, in the future, we may provide tools for finding out this information from your app. For now, the best thing to do is look at the server log for a typical user session.

We've modeled one application so
far and I can provide details
on differing server configurations
outside this forum. This may seem a bit confusing as there's really too much
detail for me to post here.

(The configuration of the data back end has significant effects here. It matters whether the LPS is running on the same machine as the data source, how much processing is required for the data source to generate the XML, and whether or not the data source is "in-process" with the LPS (this is a new, unreleased feature)).

In a nutshell, the app was
300K uncompressed, 150k gzipped,
and we assumed 95% use was new users
(no client side cache).

A typical session was 10 minutes
and did 70 data requests of varying
sizes. We assumed one large ~80k
xml request per session and the
rest much smaller (.5k, 1k, 5k, 10k).
We didn't include any client
writebacks nor did we include any
runtime media requests.

We assumed that 50% of the days traffic came during 2 hours, another 25% came during another 3 hours, and the rest of the traffic was evenly spread about the day.

For a single 1Gig CPU, we expect
to handle anywhere from
~20,000 users per day to
~100,000 users per day

for this app depending on how
the back enddata base is accessed.
If the LPS is the bottleneck and you're using the new 'in-process' datasources,
you can get much closer to the 100k.

If you want to ask more
specific questions about scalability/performance give a holler.

Best,
Eric

[andy.burnett]

You say the machine has a 1Ghz processor, how much RAM was installed? Also, was the data source on the server or on a separate machine?

You mention 'run time media', just so I am clear, does that refer to accessing e.g. pictures and audio files, or is this a specific feature related to the lzx app? I guess I am trying to understand the difference between data access and media access. Is it simply that data must be XML and anything else is therefore media access?

[bloch]

We ran the JVM with 500mb virtual.
The machine had 1gig of memory but
I think you can do with less.

By 'data' I mean XML and by 'media' I mean
images, audio, video, pre-built 2d animation.

There are essentially 2 ways
to get media (and data) into the app: compile time inclusion (see the resources example) or runtime inclusion (see the dataimage2.lzx example for runtime images). Compile time has an effect on filesize/app download performance while runtime has an effect on runtime server cpu and bandwidth.

Runtime loadnig is more flexible and simply required by some apps.

One important thing to note.
We tested against JRE 1.4.1 and
Jetty 4.2.7 as well as Caucho
Resin 3.0 beta. Resin did slightly
better.

Best,
Eric