README.superclassic 2.6 KB

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