Re: New ad server system

From: Zak Power <zak_at_hackers-for-hire.com>
Date: Wed 18 Oct 2000 15:57:43 -0500

BRAD JENSEN <brad_at_elstore.com> WROTE:
> It would seem to me that the real bottleneck is disk
> IO. Perhaps you are already caching the ads in RAM,
> but if not, why not load each gif or other format ad
> into memory and keep it there.

Actually in my whole life I have seen very few servers
which max out their discs before their bandwidth or
CPU, so far we've seen only TCP-IP stack related
bottle-necks, and broke them.

It does so little disc access so far. A pair of SCSI-II
discs, one for OS & our toy, and one for data.

Having the data in a good format for rapid
search-through is important too. To only access what
you have to, in order to serve the ad. And doing all
the logging & extra processing AFTER the ad is
served...

> If you have 2,000 currently running ads at 30K each,
> it would only take 64K. Then run your database
> updates into memory with periodic updating of disk.

We are doing this! However since disc access is still
light we've not seen a big impact yet. The option is
there, though. It works just like you described, it
mirrors the data that is on the disc, in a RAM-disc.
The data fields all have "sync" fields which represent
the updating of the data sets across the cluster.

There's also the "fast CGI" concept which helps a
little wee bit, to keep the executables persistent and
queued up for the next serve.

There is an experimental "NO WEB SERVER" mode also,
where it handles it's own port allocation etc. and
doesn't need a web server. It just binds to port 80,
spawns children ad servers which read the HTTP request
line, do some thinking, and serve an ad, very
efficient. But most of the users seem to like having an
actual web server there also, it can be handy.

> Another option would be to use a big RAM drive, since
> PCs are now supporting gigabytes of memory. However,
> I'd think a straight memory cache of the image would
> be faster. Perhaps a RAM drive for the database updates
> and log files, and in-memory cache for the images. Or
> write the log files to disk, but buffer up 64k or more
> for each write.

Yep, a 1 Gb swap partition too, but that should tend
not to come into play except under really heavy load.

There is an ACCOUNT object (for each user), which
contains SETS of OBJECTS (ads), and CHANNELS used to
control the serving. For any given serve, only 1
account, 1 set and 1 object should need to be accessed.
Writing is restricted to a couple of bytes here or
there unless the user is actively configuring stuff. So
the actual "active data" is not that large. Log-type
data doesn't count since it is only written after serve
(zero wait state) and only read during reporting... so
all those files can stay on a normal disc and don't
benefit much from being on a RAM-disc.

To minimize maintainance we've been setting it up to
keep 30 days of records on-hand and to archive the rest
elsewhere. It's still accessible, just not right on the
front-line cluster. As time goes on we can mabye make
this more flexible, but this way it doesn't require the
user to do anything by default, to keep the data volume
in order. An impression is deemed to expire after 30
days (it's distinct again). Works so far. Can make
adjustments as needed.

> It's been our experience in the past that buffering up
> your own writes and reads can give orders of magnitude
> improvement in performance for i-o bound applications.

I hope we hit a 10MBPS, mabye 100MBPS traffic rate, I
would be satisfied with that, if the bottle-neck per
box is the speed of the actual bandwidth, I'd be happy.
Then the users can just cluster multiple boxes
together. If we're lucky it'll be able to handle X MBPS
of traffic regardless of the type of traffic, I think
we can reach this goal. That puts the limitations
elsewhere, gets us off the hook... ;)

> I'm assuming in this that the image is not being
> cached on intermediate servers.

Some users are and some aren't. Those that are should
be aware of the issues involved there and understand
it's outside their control once they fire off a
redirect.

Zak Power / ZENCOR
http://www.hackers-for-hire.com/~zak
(800)-759-9826 / (416)-820-3304





Received on Wed Oct 18 2000 - 15:57:43 CDT