tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Hartung" <>
Subject Re: Database load balancing?
Date Mon, 24 Feb 2003 16:36:25 GMT
> From: "Vic Cekvenich" <>
> Sent: Monday, February 24, 2003 4:02 AM
> Subject: Re: Database load balancing?

> Try caching first; with or

Yeah, that's what I would try first. Especially if it's read only data, make
it an issue to not hit the database at all, and then you won't have to scale
the back end as much.

And caching can mean many things. Caching not just in memory, but even
entire pages. It depends on how dynamic that actual pages are, not just the

Heck, just sticking a caching proxy in front of your site can do wonders!

At the application level, though, your basic logic can be:

Get Request
IF !memoryCache THEN
    IF !fileCache THEN
        Create fileCache from DB
    END IF
    Create memoryCache from File
server out of memory.

Whole bunch of syncrhonization issues and other stuff that makes this
not-so-trivial, plus the cache cleaning threads, data expiration etc to add

Finally, it may not even work with your application.

> Replication could slow you down.

It all depends on the application. It depends on how much incoming data
there is, and how up to date you must keep the mirrors. Are they allowed to
be out of synch at all? Probably.

>From a Java level, you can have your data come into a JMS queue, where the
listeners update the master DB and also the mirrors. The real trick is doing
any bulk synchronization should they get out of the synch outside of the JMS
process. Of course, this could be accomplished with simply a bulk copy of
the masters data files.

The biggest problems happen when the producer and consumer of the data are
the same person (like a BBS), where folks expect "instant feedback" from
their messages. But, if your staff creates the data out of the view of the
consumers, then your consumers have no expectations of when new data will
appear in the system, so a delay between data submission and site update can
be minutes or hours or even days.

But, anyway, cache first. Overall I think it's a "less complicated"


Will Hartung

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message