Hi, Herouth.
On Mon, 22 Mar 1999, Herouth Maoz wrote:
|o| > As some of you may know, I'm hacking Ascend RADIUS 2.01 to look up a
|o| > PostgreSQL database for authentication and log to PG for accounting.
|o| > Normally, RADIUS fork()s once for Accounting and fork()s for each
|o| > Authentication request. That's a lot of fork()ing and establishing
|o| > connections to the backend. It's slow, but it's better than junking
|o| > whatever code I've written so far.
|o| >
|o| > If anyone can give a better suggestion, I'm all ears. Also, if anyone
|o| > wants the code when it's done, try asking. ;^)
|o|
|o| Why don't you try to synchronize access to the connection between the
|o| various processes? You know, lock it in an exclusive lock, on an
|o| inter-process basis, such that when one process accesses it, the others
|o| have to wait. Or you can have a few connections open, so that the
|o| bottleneck is wider. You know, like you would treat any shared object in an
|o| inter-process environment?
It kinda defeats the purpose of allowing RADIUS to fork() if I do locking.
I've no benchmarks to prove it, but if I allow it to execute one process
at a time via locking, that would probably slow the other processes down.
(ie. Should the waiting process block? If so, when will it try again? Are
the overheads to establishin a connection really that big?)
L L Richi Plana 8^) ,-,-. ,-,-. ,-,-. ,-,-. ,-
LL LL Systems Administrator / / \ \ / / \ \ / / \ \ / / \ \ / /
LLLLL Mosaic Communications, Inc. \ \ / / \ \ / / \ \ / / \ \ / /
LLLLL mailto:richip@mozcom.com `-'-' `-'-' `-'-' `-'-'
------------------------------------------------------------------------
P G P Key available at http://www2.mozcom.com/~richip/richip.asc
Tired of Spam? Join this CAUCE! http://www.cauce.org/