Re: Any Good Way To Do Sync DB's?

On Monday 15 Oct 2001 13:35, Joseph Koenig wrote:
> Your solution sounds very interesting (Not the throw away NT
> part...)

That is where a signifficant part of the performance improvement would come
from, if performance was what you were after...

> ...does anyone else have any input on this? Would it work well?

It works great - I am using it on a number of servers. It also gives you a
much more secure setup, because you can pipe everything through a single
firewall with a squid accelerating proxy. That means that a hacker would have
to breach your firewall befure they would have even a remote opportunity to
penetrate deeper into your network and attack the web server.

> Any idea as to what amount of traffic it would be capable of handling?

Any amount of traffic, it just means that only two connections would be
served at any one time. If your query return and CGI page construction times
are very low (which they should be if you are using mod_perl on a decent
server), then you are unlikely to notice any slowdown. The excess hits would
just get queued and processed when back-ends become available. It would also
be a good idea to look through your scripts and attempt to connect the
database in Perl::DBI as late as possible (not at the beginning of the script
as a global variable, but just before the query is issued), and disconnect as
early as possible (as soon as the query is executed and the data retrieved).
This would not hog the connections to the PostgreSQL end as much.

Of course, this is all provided you use perl CGIs and mod_perl on Apache.
Otherwise, persistent connections don't come into the picture at all.

> If apache is only running in two instances, would that really keep the
> number of ODBC connections to 2 at max?

No, that would only keep the number of your connections from the WEB SERVER
to two max. ODBC connections from the rest of your network would be a
completely separate issue. Basically, if Apache only ever has two instances
running, then it can only ever serve up to 2 requests at any one time, and
hence the database server will never receive more than 2 simultaneous request
from the web server - UNLESS your CGIs make multiple database connections in
parallel. If they do, then you're fighting a loosing battle, and you might as
well give up.

If your CGIs only ever use one connection, then putting the web server behind
an accelerating squid proxy would actually help further, by not using the
Apache back ends to serve static documents, such as frames pages, gif/jpg
background or button images, etc. This means that only the actual CGI
requests would go to Apache. I have implemented this sort of a load-reduction
solution with a reduced number of active Apache servers in my last
consultancy contract, and it worked very well.

> By the way, I fully agree with throwing away NT --

Understandable...

> unfortunately this DB is part of their inventory and
> POS system that another company set up for them. They just finished
> investing about $200K in the system, so just telling them to get rid of
> it isn't quite an answer. Thanks for all of the input from everyone.

Hang on - if they have just invested $200K into this "solution", then why
exactly is an additional $5,500 for another licence a problem all of a
sudden???

Regards.

Gordan