Summary for testing IBProvider with Firebird 2.5

Automatic load testing of IBProvider is being performed almost 7×24 with minimum server down time, so we ceased to give special attention to it.

However, certain things can be interesting for those who have already been using our provider in critical systems or those who have only been searching for a reliable solution to access Firebird and InterBase.

Load testing

During summer 2016, we were performing «big» multithreaded load testing of our OLE DB provider.

Configuration

• IBProvider 3.30.0.21186 (64bit, vc14xp)
• Firebird 2.5.6.26993 (64bit, SuperClassic, modified, built in VS2015)
• Connection via localhost
• Windows Vista x64, Q6600, 8GB, dedicated RAID0 4x1TB (RS2BL040)

Features

• Usage of our own Firebird client (dbclient_type=fb.direct)

Testing mode overview

• Tests were run in 4 threads
• Use of the connection pool
• Intensive use of asynchronous loading

Duration

• The tests worked from June 4 to August 2, 2016
• Firebird has worked 960 hours of processor time. Process overview: screenshot1, screenshot2
• The testing system has worked 579 hours of processor time. Process overview: screenshot3, screenshot4

Database statistics

Database "d:\database\IBP_TEST_FB25_D3_all.GDB"
Database header page information:
        Flags                   0
        Checksum                12345
        Generation              44209884
        Page size               8192
        ODS version             11.2
        Oldest transaction      44023029
        Oldest active           44023030
        Oldest snapshot         44023021
        Next transaction        44023046
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      161122
        Implementation ID       26
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Jun 4, 2016 17:13:01
        Attributes

    Variable header data:
        *END*

The point where circularity earlier occurred inside Firebird (CORE-4384) was successfully passed through.

About 790 thousand test were performed.

The tests were discontinued because of power supply problems.

Stress testing

Periodically, when tests are started multiple times on the same database, load testing becomes stress testing — memory shortage error occurs (OUTOFMEMORY).

It is also quite a useful testing mode that tests the quality and general tolerance of the code to non-routine situations.

When working with Firebird via fbclient.dll, you are at risk of getting AV inside the process. For example, with such stack:

fbclient.dll!get_numeric_info(const char** ptr=0x00000000)  Строка 923 + 0x15 байт    C++
fbclient.dll!UTLD_parse_sql_info(int* status=0x00000000, unsigned short dialect=2, const char* info=0x00000000, XSQLDA* xsqlda=0x1bbe4e10, unsigned short* return_index=0x0391f498)  Строка 226 + 0x11 байт C++
fbclient.dll!iterative_sql_info(int* user_status=0x00000000, void** stmt_handle=0x00000002, unsigned short item_length=62868, const char* items=0x10074764, short buffer_length=0, char* buffer=0x00000000, unsigned short dialect=1, XSQLDA* sqlda=0x1bbe4e10)  Строка 5575 + 0x13 байт  C++
fbclient.dll!isc_dsql_prepare(int* user_status=0x0391f7a0, void** tra_handle=0x1c962398, void** stmt_handle=0x1a7761d8, unsigned short length=26, const char* string=0x09b90f10, unsigned short dialect=1, XSQLDA* sqlda=0x1bbe4e10)  Строка 3580    C++
_IBProvider_v3_vc14xp_i.dll!ib_v5::t_ib_statement_v5::prepare(db_obj::t_db_operation_context& op_ctx={...}, db_obj::t_db_stmt_result_kind stmt_result_kind=db_stmt_result_kind__selectable, structure::t_basic_const_str_box<wchar_t> stmt={...}, db_obj::t_db_row* const row=0x1b1e17c8, const unsigned int pr_flags=0)  Строка 210 + 0xc2 байт    C++
_IBProvider_v3_vc14xp_i.dll!ibp::t_ibp_command::prepare3(db_obj::t_db_operation_context& op_ctx={...}, db_obj::t_db_stmt_result_kind stmt_result_kind=db_stmt_result_kind__selectable, structure::t_basic_const_str_box<wchar_t> text={...}, const unsigned int expected_params_count=0)  Строка 103 C++
_IBProvider_v3_vc14xp_i.dll!ib_sql_pstmt::t_ib_sql_pstmt_select_table::prepare_clone_impl(ibp::t_ibp_operation_context& op_ctx={...})  Строка 363 + 0x52 байт  C++
_IBProvider_v3_vc14xp_i.dll!ib_sql_pstmt::t_ib_sql_pstmt_select_table::prepare_sql_impl(ibp::t_ibp_operation_context& op_ctx={...})  Строка 340    C++
_IBProvider_v3_vc14xp_i.dll!ibp_sql_pstmt::t_ibp_sql_pstmt_std_base::prepare_sql(ibp::t_ibp_operation_context& op_ctx={...})  Строка 116   C++
_IBProvider_v3_vc14xp_i.dll!ibp::t_ibp_command_pstmt_data::prepare(ibp::TIBPCommand* const pCommand=0x32d400c0, const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >& command_text={...}, structure::t_smart_object_ptr<ibp::t_ibp_transaction,structure::t_sptr_traits<ibp::t_ibp_transaction> >& spTrans={...})  Строка 107   C++
_IBProvider_v3_vc14xp_i.dll!ibp::TIBPCommand::Prepare(unsigned long __formal=0)  Строка 54  C++
    ibp_oledb_test_vc14_Win32_Release_xp.exe!oledb_lib::t_db_command::prepare_ex(structure::t_str_parameter<wchar_t,std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > text={...}, oledb_lib::t_db_row* pRow=0x00000000, unsigned long describe_flags=1)  Строка 135 + 0x18 байт  C++

The problem is usually relevant to 32-bit processes with limited address space of 2GB (4GB on a 64-bit platform).

In this particular case, the test process had this state:

However, 64-bit processes are also not protected from such troubles.

General recommendations on working with Firebird

• Use 64-bit server builds
• If working with server via fbclient.dll, better do this from a 64-bit process
• Connect to Firebird via a built-in provider client. To do this, enter «dbclient_type=fb.direct» in the connection string

To sum it up

Generally, all the experiments prove the only critical problem of IBProvider:

And it is really amazing taking into account the total volume and complexity of its code.

We have strove for this all 16 years from the moment the project was launched.