List:General Discussion« Previous MessageNext Message »
From:Simon J Mudd Date:March 17 1999 1:01pm
Subject:Re: beeing informed of changes in rows in a table (real-time prices)
View as plain text  
On Wed, 17 Mar 1999, Rick (Richard Lee-Morlang) wrote:

> "Severe load" depends on the magnitude of what you're doing.  I could see 50
> clients doing a select every second against a database be quite feasible,
> provided that the selects weren't too computationally expensive and the
> datasets being returned weren't too large. "too" is obviously a relative
> term, relative to a number of other things. :-) But something like this isn't
> unrealistic. Unless you have some more concrete numbers as to what you
> require, you could try simulating that kind of load on the server and see how
> it holds up.

The hardware I'm using on the database is a non-dedicated ultra-10 with
128MB of RAM.  I anticipate about 10-20 clients, and yes I'd like about a
1 second maximum delay.

Maybe you're right it's best to try things, but "polling" for data seems
the wrong way to do this.  At least in other "multi-event" problems the
solution (in unix) is use the select(2) on various file descriptors, and
wait for one to become ready, or a timeout to occur.  Obviously these
other problems aren't database related.

> As suggested by Ed Carp, using a process on the server to push data out to
> the clients makes a lot more sense, of course. And if you were using a method
> like this and needed near-realtime responses, you could turn on update
> logging in MySQL and have your push process watch the logfile for changes.
> Every time it sees a change, it issues a query to grab updated data and
> pushes anything it finds out to the clients.

This sounds "sensible" in the sense of distributing the updated data
correctly, but you have to develop (or use) other non-database related
software to get this.  At the end of the day, the clients at least
probably don't gain any benefit in seeing the database directly.

> I don't know if that qualifies as a dirty hack or not, but it would work, and
> I've done some similar things myself in the past with a lot of success.

I guess I was looking for an idea of whether the commercial databases
provided "add-in" which allowed this to be done without including the 
extra layers.  Sounds like they don't.

In the longer term I may have to go along the route you suggest, but for
the time being I'll just poll the database every second or so on each
client and keep an eye on the server's load.

Thanks for your comments.


Simon Mudd  ********  All Trading Brokers Europe  *********  Madrid, Spain
Switchboard: +34-91-592 8188    Fax: +34-91-592 8170   Direct: 91-592 8250
Work email: simon.mudd@stripped --- Home email: sjmudd@stripped

beeing informed of changes in rows in a table (real-time prices)Simon J Mudd17 Mar
  • Re: beeing informed of changes in rows in a table (real-time prices)Richard Lee-Morlang)17 Mar
    • Re: beeing informed of changes in rows in a table (real-time prices)Simon J Mudd17 Mar