| Subject | Re: [IB-Architect] Classic vs SuperServer was IB/FB Lock manager failures |
|---|---|
| Author | Jim Starkey |
| Post date | 2002-09-18T17:02:19Z |
At 12:25 PM 9/18/02 -0400, Paul Schmidt wrote:
not. Among them:
1. In classic, when process A requests a lock on dirty page
held by process B, it must send a signal to B. The OS
must context switch to B. B must then write out the dirty
page and downgrade the lock. The OS then context switches
back to process A which gets the lock then reads the page.
So classic has an interprocess signal, two context switches,
a page write and a page read. Superserver does nothing.
2. Creating an attachment on classic requires creating a new
OS process. SuperServer does not.
3. Before classic can do anything it must initialize itself,
attach the shared memory and semaphores for the lock manager,
open the database file(s), read the database header, scan
RDB$PAGES to find keep stuff, read RDB$RELATIONS,
RDB$RELATION_FIELDS, and RDB$FIELDS to compile a user
request, and read RDB$FORMATS for each table format version
it encounters. SuperServer does this only once.
4. Classic must compile every statement it sees, even if a
SQL statement had been compiled 10,000 times that day.
Compilation involves a precedence driver parse allocating
a language node per BNF production, a compilation process
requiring at least another language node per BNF production,
an optimization process involving stream, rivers, and
tributaries. SuperServer does the same damn thing, but
it doesn't need to.
SuperServer unlike classic, is constrained by the number of sockets
an OS will allow a process. Whether this is more or less than
the number of processes supported by an OS depends from OS to OS.
Classic has always suffered from scalability under a heavy
contentious update load. SuperServer handles that nicely.
If you believe, as I do, that the universal platform is the
web, the architecture has to handle very large number of very
short connections. Perhaps classic with connection sharing
is an answer. I'm betting on single process/multi-thread
architecture, albeit one that Borland's grubby, greasy fingers
have never fouled.
Jim Starkey
>between
>I also understand that SuperServer uses threads to switch back and forth
>queries, rather then processes. And that it's not superior to classic,just different
>internally (guess it was named by the folks in marketing).It's not that simple. Classic has many costs that SuperServer does
>
not. Among them:
1. In classic, when process A requests a lock on dirty page
held by process B, it must send a signal to B. The OS
must context switch to B. B must then write out the dirty
page and downgrade the lock. The OS then context switches
back to process A which gets the lock then reads the page.
So classic has an interprocess signal, two context switches,
a page write and a page read. Superserver does nothing.
2. Creating an attachment on classic requires creating a new
OS process. SuperServer does not.
3. Before classic can do anything it must initialize itself,
attach the shared memory and semaphores for the lock manager,
open the database file(s), read the database header, scan
RDB$PAGES to find keep stuff, read RDB$RELATIONS,
RDB$RELATION_FIELDS, and RDB$FIELDS to compile a user
request, and read RDB$FORMATS for each table format version
it encounters. SuperServer does this only once.
4. Classic must compile every statement it sees, even if a
SQL statement had been compiled 10,000 times that day.
Compilation involves a precedence driver parse allocating
a language node per BNF production, a compilation process
requiring at least another language node per BNF production,
an optimization process involving stream, rivers, and
tributaries. SuperServer does the same damn thing, but
it doesn't need to.
SuperServer unlike classic, is constrained by the number of sockets
an OS will allow a process. Whether this is more or less than
the number of processes supported by an OS depends from OS to OS.
Classic has always suffered from scalability under a heavy
contentious update load. SuperServer handles that nicely.
If you believe, as I do, that the universal platform is the
web, the architecture has to handle very large number of very
short connections. Perhaps classic with connection sharing
is an answer. I'm betting on single process/multi-thread
architecture, albeit one that Borland's grubby, greasy fingers
have never fouled.
Jim Starkey