At 03:29 PM 11/1/01 -0500, Bob Murdoch wrote:

>At 10/31/2001 01:11 PM, Jim Starkey wrote:
>>they're welcome at Netfrastructure if they have enough money
>
>I've been seeing you mention Netfrastructure quite a bit, and it sure
>sounds wonderful. Is 'Netfrastructure' the name of a product, a company,
>or a desert topping? (I did check the website, actually a couple of times
>over the last ~six months, but still came up empty).
>
>The question of 'enough money' is for me to know and you to find out <g>.
>

OK, under the guise of an architectural comparison to avoid the
Wrath Of Helen, here is the scoop on Netfrastructure.

Netfrastructure is an "web deployment engine". It is a complete,
integrated, encapulated environment for highly portable, multi-instance
Internet applications. Netfrastructure contains a content store
(a euphonism for database engine), an integrated search engine,
a Java virtual machine, and a page generation engine. All components
share a single role-based security model.

Netfrastructure applications are multi-instance in two senses. First,
a Netfrastructure application can be distributed, installed, administered,
and upgraded with no more than a browser. Second, Netfrastructure
applications can support any number of application instances, each
with indepedent content and distinctive appearance. Customization
of an instance is non-destructive -- the actual application is unchanged
-- and survives application upgrade.

The essential idea is that Netfrastructure separates the three
elements of a web application -- logic, appearance, and content
-- so each can be managed independently then merged at runtime.

The Netfrastructure content store is a distant relative of Interbase/
Firebird. The engine is multi-generational in memory but not on
disk. There is no analog of sweep or funny rules about oldest
peculiar transacation. The beast is natively JDBC and written
in C++. The Java virtual machines runs inside the content
store like a big, fat stored procedure. Triggers are written
in Java. Netfrastructure doesn't have stored procedures, per se,
since everything is a stored procedures. It does have external
ODBC and JDBC interfaces, but I don't let anybody use them.

The content store is a radical architectural departure from
Interbase, and is based on the observation that memory is now
infinite and free. My, things change. The basic model is an
in-memory database, a disk for back fill, and a scavenger thread
to kick crud out of memory.

An extremely important part of the content store is caching of
compiled requests. Vastly reduces overhead.

The search engine is essentially Alta Vista semantics. Any
field can be marked searchable. Typical search times are small
numbers of milliseconds. Search is generally multi-table, though
I also implemented non-sanctioned SQL "matching" operator to
make Greg happy.

The Java virtual machine has a few interesting characteristics.
An esoteric feature is a non-blocking garbage collector. The
most interesting one from a developers perspective is dynamic
class loaded. Recompile an application class and the server
will deprecate the old version in place and load the new version
without restarting the server.

But the most important part of the JVM is that application code
can go straight from Java code into the content store with a
single call. No thread switches, content switches, network
traffic, or data copying.

The whole thing is fine grain multi-threaded. It works just
fine on multi-processors.

Applications are written as extensions of a comprehensive
builtin base application. The base application contains
everything necessary to:

-- Display and navigate a database by primary/foreign
key links.
-- Package an application for distribution. The package
file contains data tables, the role model, sequences,
triggers, indexes, filtersets, templates, images,
application attributes, etc. Package files can be
written to a file or FTP server and are platform
independent.
-- Install a packaged application from a local file or
FTP server.
-- Clone an application instance
-- Perform automatic scheduled application backups
-- Manage roles, accounts, permissions, etc.

Triggers are supported for pre/post insert, pre/post update,
pre/post delete, and post commit. The later, although with
an inter-server "service" feature supports application level
replication. It could probably support load balancing, but
the sucker is so fast it isn't necessary.

By and large Netfrastructure is screamer. A recent benchmark
involved taking a static snapshot of the documentation database,
requiring:

Traversing 370 urls,
Executing 2,653 queries
Returning 3,853 records
Evaluating 6,283 templates
Expanding 4,065 templates
Generating 370 html pages.

The elapsed time ranged from 11 seconds on a crapola Compaq
500 MHz AMD K6 w/ 56 mb memory running Redhat 6.1 and Apache
to 4 seconds on a 1.3 GHz Athlon 256 mb running NT 4.0 and
IIS. That's 92 pages per second on a $1,495 machine with
the client, the engine, and the web server on a uniprocessor.
Take off the client, move the web server to a separate system,
and toss in a second processor, and I suspect it could crank out
about 400 pages per second, probably enough to run Amazon.

The content store can write about 5,000 non-indexed records
per second on a sustained basis. Although it doesn't yet
accelerate disks, cached records are processed at something
a little above 100,000 records per second.

The image, consisting of:

Content store (multi-user, transaction based rdms)
Java virtual machine
Page generation engine
Search engine
Word -> html converter
Other good and sundry stuff

is about 1 MB. OK, a bit big, but not exactly bloatware.

Oh, it is also natively SQL. Sigh.




Jim Starkey