Howdy,
I wrote the core SOB code years ago -- at the time I think our goals
included:
-- Security: Server connects out to known clients.
-- Performance: State-full connections, minimal protocol overhead,
lots of caching, no encoding overhead
-- Simple: String keys, string data, integration with net cache flush
-- Insight: Lot's of traffic counters collected
-- Tcl aware: Expects to store/send UTF-8 strings only
-- Some special case stuff, e.g., the comment board code.
In general, SOB met these goals at the expense of:
-- Config complexity: Maintaining topology is rationale but tedious
compared to client-server HTTP connections through routers
-- Binary: Just strings
-- File system scale: SOB relies on rationale topology and/or key
management to avoid file system scale problems (i.e., too many files
in a directory).
The point on UTF-8 deserves a bit more explanation. In general, all
the parts of the "dci" module assumed everything is in UTF-8,
always. In a sense, it's best to imagine SOB (and NV, AV, etc.) as
really just a way to serialize Tcl data to/from some stable something
-- if it's not in memory, it's designed to be read directly into
memory with no encoding / translation / etc. In other words, the
lack of encoding and binary code support was by design, not an
oversight, which provided some benefits but -- as in the case of
trying to use SOB for thumbnails -- some downside.
-Jim
On Oct 25, 2007, at 9:12 AM, Michael Andrews wrote:
In general, I find the SOB model works well. The caching on the
server and the client provide unmatched performance. The NCF
provides a mechanism to flush the cache on updates. The Devil is
always in the details. How you set up multiple SOB servers and then
get the publishes to multiple SOB servers can certainly create
scaling and topology management issues.
Most sites to do not have the demands that AOL has - and a simple
SOB solution would be nice addition to any content distribution
system. However there are advantages to stateless systems. :-)
(How's that for diplomatic)
M
On Oct 25, 2007, at 10:19 AM, Dossy Shiobara wrote:
On 2007.10.25, Jay Rohr <[EMAIL PROTECTED]> wrote:
In general, I would not recommend using sob. It was developed for
very
specific requirements at AOL and it does not scale well under load -
volume or frequency. We are in the process of replacing it with
something else.
Okay, this is just plain misinformation. SOB works very well for
what
it was intended for, a low-write, high-read, distributed service for
small objects (thus, the name "SOB").
Any scaling issues AOL is having has to do with how it has since been
misused and/or operationalized.
-- Dossy
--
Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave
the Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
