Firebird 2.5 Architecture, by Dmitry Yemanov (in English)

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

http://www.mindthebird.com	2798
http://mindthebird.com	370
http://firebird-pl.blogspot.com	101
http://www.slideshare.net	25
http://pnv82.blogspot.com	24
http://translate.googleusercontent.com	20
http://folami.nghelong.com	4
http://osdb.ru	3
http://www.mindthebird.it	2
http://fomay.blogspot.com	2
http://www.mindthebird.com.	1
http://webcache.googleusercontent.com	1

Firebird 2.5 Architecture, by Dmitry Yemanov (in English)

by Nataly Polyanskaya on Oct 19, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

12 Embeds 3,351

Statistics

Firebird 2.5 Architecture, by Dmitry Yemanov (in English) — Presentation Transcript