On Monday 10 November 2003 05:12 pm, Nathan Seven wrote: > Well, like I said- I'm new to AOLServer so I'm going > off of the tuning docs: > http://www.aolserver.com/docs/admin/dbadmin.html > > Speaking of external drivers: > "It is likely, however, that this distributed > approach, i.e. a separate process per database > connection, will improve overall database throughput, > even with the additional communication overhead. We > expect this performance improvement because > vendor-supplied database client libraries, running > within a multi-threaded server, must limit concurrency > via resource locks."
This is an ancient document wow ... AFAIK there's no evidence that this hypothetical statement has proven to be true for either the Oracle or PostgreSQL client library. And when the proxy daemon driver was first introduced that additional communication overhead mentioned above turned out to be horrendous, though it got greatly speeded up soon after that discovery. I remember because I'm the one who flagged that fact when comparing throughput of that driver + Sybase vs. the internal driver and Oracle. Long time ago ... > I'm using FreeBSD as my OS, and it's got several > threading models. The "sane" one will not distribute > threads to different CPUs (eliminating any gain from > SMP). > The 1-1 thread-proc model and the KSE model are both > new to 5.x, which I'm a little hesitant to use... > So- if I end up going with stable-FreeBSD, all SMP > value will be lost unless I can break the DB stuff in > to different procs (vs different threads). Ummm ... your database is a separate process, it's just the driver that's going to run in the threaded environment. PostgreSQL spawns a new process for each connection so FreeBSD should make fine use of both processors. Generally you'll be asking AOLserver to initiate several connections and pool them, which means several backend processes in the PG case. Much, much more time is spent in the RDBMS than in the driver or PG client library. This combined with the fact that each PG backend runs in a separate process is why the hypothetical argument above is bogus for PG and always has been. > My experience with either is limited and they *are* > pretty feature-comparable, but the specific advantages > that made me choose Firebird over Postgresql are > these: > Shadow-db functionality. This is a good point. > SPs without linked-in-interpreters. (less code to have > to trust) PL/pgSQL is trustworthy, I'd describe this as a bogus reason in practice (being a very experienced PG person). > Simpler administration. (for me anyway) What do you think is simpler? The main issue with PG is having to run a VACUUM job to recover old tuples - Interbase does this automatically (they both use the same multigenerational, non-overwriting approach to tuple storage, unlike Sybase or Oracle which use overwriting storage managers). I just ns_sched a Tcl proc that does the VACUUM once a night and having done that ... there's no administration involved unless you've got a rapidly growing database that requires you watch disk space etc. > And well- it just leaves a little more "robust" of a > taste in my mouth, Interbase is likely the > largest-deployed-db on the planet. PG's gotten extremely good in the last three-four years. There's far more active development than with Interbase - which in a way is an argument supporting your good feelings. i.e. Interbase is solid and not changing much, PG is solid but each version adds a bunch of new functionality that could in theory make it less stable until it is better tested, though in practice this has not been the case. Still, I generally run a version or so behind the latest release with PostgreSQL just to let other people verify new versions are stable. Another major feature missing from PG is some form of tablespace concept that lets you put indexes and tables on different filesystems (in general, different disk spindles) which can help performance. That will be coming in a few months. At the moment you're stuck using the Unix "ln -s" command to manage where things are placed if you need to. On the other hand, with today's huge cheap disks and insanely cheap RAM I've never had to do that in practice. Unless you're looking at 100s of megabytes of stuff I'd say forget I even raised this issue (and I don't know if InterBase implements tablespaces or their equivalent anyway). > But- like I said, the differences between both are > minor, so if I had to use Postgresql, I could. Try it ... I think you'll like it. The PG lists are very helpful, and for AOLserver + PG issues both this list and the forums over at our OpenACS project are full of people who use the two together day in and day out, for paying client websites. -- Don Baccus Portland, OR http://donb.furfly.net, http://birdnotes.net, http://openacs.org -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
