| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859 |
- -------------------------
- SuperClassic architecture
- -------------------------
- Firebird 2.5 offers a new working mode, also known as the SuperClassic architecture.
- Generally speaking, it's some kind of a compromise between Classic and SuperServer
- targeted to shift the scalability limits of the regular Classic Server and provide
- slightly better performance, as well as some features priorly unique to SuperServer.
- Architecturally, SuperClassic is implemented inside a single server process, with
- user attachments being served by threads. Similarly to SuperServer, these worker
- threads are shared, i.e. the server maintains a thread pool and never uses
- more threads than a number of active user requests running at the moment.
- However, unlike SuperServer which shares the page cache and metadata cache between
- attachments, SuperClassic uses the model of private per-connection caches, similarly
- to the regular Classic, thus inheriting its memory usage implications.
- Being implemented inside a single process, SuperClassic offers some benefits as
- compared with the regular Classic:
- * Less OS kernel resources are used (e.g. desktop heap on Windows), it should
- allow better scalability in terms of a number of user attachments
- * Better performance due to the local calls (instead of IPC) inside the lock
- manager and other in-process optimizations
- * Server can be safely shutdown as a whole, all active attachments are gracefully
- disconnected
- * It's possible to enumerate attached databases and users via the Services API
- * Security database attachment is shared, thus allowing faster user connections
- The drawbacks are the following:
- * Somewhat ineffective memory usage (same as for Classic)
- * High lock table contention (due to page locks), so it requires careful tuning
- the lock manager configuration (again, same as for Classic)
-
- * Server crash affects all user attachments (same as for SuperServer)
- * It doesn't make much sense on 32-bit systems, because the total page cache size
- (for all attachments) must fit the 2GB process address space limit
- Please note that SuperClassic opens the database file in the shared mode, allowing
- other Classic, SuperClassic or Embedded processes to access the database file at the
- same time.
- On Windows, SuperClassic shares the same binary fb_inet_server.exe with Classic.
- A new command line switch -m (multi-threaded) should be used for fb_inet_server.exe
- to start SuperClassic as an application, or for instsvc.exe to install SuperClassic
- as a service.
- On POSIX, a new binary fb_smp_server is introduced to run the server in the
- SuperClassic mode. It should be installed as a system daemon, [x]inetd is not required.
|