DEVEL-A35 Dmitry Yemanov
Firebird 2.5
Architecture
Dmitry Yemanov
Firebird Project
http://www.firebirdsql.org/
1

DEVEL-A35 Dmitry Yemanov
Firebird 2.5
 Rationale
 First step in the Classic/SuperServer unification
 Codebase modernization
 Common threadable architecture
and more efficient multi-threading support
 A number of new features
 Intermediate release between v2.1 and v3.0
2

DEVEL-A35 Dmitry Yemanov
Threadability as a Primary Goal
 Major MT cleanup
 Only threadable platforms are supported
 Old synchronization logic is updated
 Generic thread safety everywhere,
starting from the API (both client and embedded)
 Better scalability
 No cooperative scheduling anymore
 Say “goodbye” to the global mutex
 Synchronization goes to the lower levels
3

DEVEL-A35 Dmitry Yemanov
Threadability as a Primary Goal
 Server layer / remote subsystem
 Worker thread pooling
 Asynchronous connection cleanup
 Unified listener code for SS and CS
 Lock management
 Non-blocking notifications
 No need in the static semaphores setup
 Per database lock tables
4

DEVEL-A35 Dmitry Yemanov
Effects for the Supported Architectures
 Classic Server
 Lock manager doesn't need explicit semaphores
and signals setup anymore
 fb_lock_mgr binary is deprecated on POSIX
 Services and automatic sweep are executed
as threads (less processes spawned)
 Server layer may determine broken network links
immediately and terminate the worker process
 libfbembed.so is thread-safe
5

DEVEL-A35 Dmitry Yemanov
Effects for the Supported Architectures
 SuperServer
 Better overall scalability and respond timings due
to a lower-level synchronization inside the engine
 SMP/multi-core hardware can be utilized efficiently
when multiple databases are accessed
simultaneously
 fbclient.so/.dll is thread-safe
6

DEVEL-A35 Dmitry Yemanov
Effects for the Supported Architectures
 Embedded Server
 Now based on the Classic architecture,
including all the benefits of the SuperClassic
 Multiple processes can safely access the database
 Official utilities (gbak, gfix, isql, etc)
can be used as well
 fbembed.dll is thread-safe
7

DEVEL-A35 Dmitry Yemanov
What is Super Classic?
 Architecture
 Single process, multiple worker threads (pooled)
 Per connection page cache and metadata cache
 A number of in-process optimizations
 Database access can be safely shared among
Classic, SuperClassic and Embedded processes
8

DEVEL-A35 Dmitry Yemanov
What is Super Classic?
Classic Embedded
SuperClassic Classic Embedded
Classic Embedded
Database
9

DEVEL-A35 Dmitry Yemanov
What is Super Classic?
 Benefits as compared to Classic
 Less kernel resources (but not memory) used
 Scalability limits are shifted
 Better performance due to local calls inside the lock
manager and other in-process optimizations
(25% performance boost in TPC-C)
 Server can be safely shutdown as a whole
 Possibility to enumerate attached databases/users
 Security database connection is cached
10

DEVEL-A35 Dmitry Yemanov
What is Super Classic?
 Benefits as compared to SuperServer
 Better scalability
(number of connections is not explicitly limited)
 Better concurrency on SMP/multi-core hardware
 More responsive under high load
11

DEVEL-A35 Dmitry Yemanov
What is Super Classic?
 Drawbacks
 Still ineffective memory usage
 High lock table contention (page locks),
requires careful tuning of the LM configuration
 Server crash affects all user attachments
 Doesn't make much sense on 32-bit systems
12

DEVEL-A35 Dmitry Yemanov
What is Super Classic?
 How to use on Windows
 The same binary as for the regular Classic
 Application: fb_inet_server.exe -a -m
 Service: instsvc install -m
 How to use on POSIX
 New fb_smp_server binary
 No need in [x]inetd
13

DEVEL-A35 Dmitry Yemanov
Combined Efforts
 Firebird team
 Synchronization inside the core engine
 SuperClassic and Embedded modes
 Updated lock manager
 Remote subsystem rework
 SAS Institute
 Concurrency testing, SuperClassic/Embedded
 RedSoft Corporation
 Concurrency testing and bugfixing
14

DEVEL-A35 Dmitry Yemanov
Evolution in Firebird 3.0
 Architecture
 Single server, different working modes:
- shared – multiple server processes (CS like)
- dedicated – standalone server process (SS like)
 Per database configuration
 Multi-threading abilities
 Full cross-attachment concurrency
 Prepared statements cache
15

DEVEL-A35 Dmitry Yemanov
Evolution in Firebird 3.0
Firebird 2.5
SuperServer SuperClassic Classic
Dedicated Shared
(in-process) (cross-process)
Firebird 3.0
16

DEVEL-A35 Dmitry Yemanov
Thank you!
Dmitry Yemanov
mailto:dimitr@firebirdsql.org
17