No subject

Technical Note:  In particular, it does not usually make sense to use Fork
with AuthBy SQL, AuthBy FILE, AuthBy LDAP or any of the other common
authentication methods provided with Radiator. Further, some SQL and LDAP
client libraries are not robust across forks. You might want to consider
using Fork with AuthBy EXTERNAL or a custom authentication module if it
needs to do significant amounts of IO, or to communicate with a remote
system.


Typically I would agree with the above.  You're not going to gain anything
if your auth lookup is all coming from the same data source/DB server.  Fork
would simply just process all of the requests and then the DB server would
end up handling all the queuing/answering back to the application.  If
anything you're probably going to cause a lot of unnecessary database
connections and resource usage with no performance gain.  If you are using
multiple different data sources, then perhaps you will have some type of
benefit.  In all of the testing I've done fork() has been really unstable
when making connections/queries with DBI.

In a large scale application it's best to just have multiple Radiator
servers and database replication partners that can hold snapshots of the
lookup data.  We do it here and it scales quite well...

While Radiator is indeed a PERL app, on a good server it's almost as
efficient with database as it's C counterparts since most of the time the
application is waiting for the database, not the other way around.

--
Robert Blayzor, BOFH
INOC, LLC
rblayzor at inoc.net
PGP: http://www.inoc.net/~dev/
Key fingerprint = 1E02 DABE F989 BC03 3DF5  0E93 8D02 9D0B CB1A A7B0

Base 8 is just like base 10, if you are missing two fingers.  - Tom Lehrer


--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.