From mboxrd@z Thu Jan 1 00:00:00 1970 From: Milan Zamazal To: Dirk Bergstrom Cc: "'gnats-devel@sources.redhat.com'" Subject: Re: persistent DB connections (was: RE: modular database backends) Date: Mon, 11 Jun 2001 11:53:00 -0000 Message-id: <873d97ypvy.fsf@blackbird.zamazal.org> References: X-SW-Source: 2001-q2/msg00163.html >>>>> "DB" == Dirk Bergstrom writes: DB> 1) keep the current model, adding a separate, persistent, DB> "database daemon". each connection would spawn a new instance DB> of gnatsd, which would connect to the database-daemon as needed. DB> i happened across sqlrelay DB> ( http://www.firstworks.com/sqlrelay.html ), a GPLed package which DB> appears to do just what's needed for the database daemon. Since the addition the modular database backends feature would allow this automatically, there'll be nothing to stop you doing this once it is implemented. DB> 2) a persistent daemon that handles setting up the connection to DB> the client, and holds open a connection (or several connections) DB> to the database. as new requests come in, the daemon would fork DB> off a child to handle each one, up to some preset limit. I can imagine a very busy BTS where performance problems can arise. If you can *prove* that the overhead of reading configuration is a significant part of the performance problem, I'll consider the possibility of making a persistent daemon. DB> 3) something like apache -- a master process forks several DB> persistent daemons, which take turns handling connections. each DB> child daemon holds a database connection, and services many DB> requests before shutting down. IMHO unnecessarily complicated: >>>>> "PN" == Peter Novodvorsky writes: PN> Other approaches are good, but hey, do some BTS's handle more PN> then 10 connections at time? Really? AOL! Regards, Milan Zamazal -- _/_\_/_ o _\_/_\_ o _/_\_/_ o _\_/_\_ o BEWARE! -<_|_|_|_><-- -<_|_|_|_><-- -<_|_|_|_><-- -<_|_|_|_><-- *Bugs* are / \ / o \ / \ o / \ / o \ / \ o approaching!