Join Firebird!

Join Firebird Foundation to support Firebird SQL development and receive multiple bonuses

Follow Us

Select your media preference

Newsletter

Subscribe to Firebird’s Newsletter to receive the latest news

Developer's Report: QA Stress Testing & Tools Development
December 2013 - January 2014

December 2013
  • Found ability for DoS attack when run script with a lot of connect commands with invalid password:
    there was no delay ~5-7 seconds between such attempts on some cases of config parameters
Result: confirmed and fixed by Alex Peshkoff
  • Descending indexes can be very inefficient in lookup/scan (found while testing INSERT performance)
Result: CORE-4302, fixed by Vlad Khorsun
  • Re-checked some old queries on which FB v3 had problems before (CORE-4261, etc)
Result: no problems anymore, a few performance related questions directed to Dmitry Yemanov
  • FB hangs on preparing of some queries, unable to establish new connect or asking MON$ tables during such prepare
Result: confirmed by Dmitry Yemanov
  • FB crashes when attempt to solve Einstein task (too complex 'where' condition)
Result: CORE-4293, fixed by Dmitry Yemanov
  • Resumed comparing results FB vs MS SQL vs ORA on misc. queries
Result: found that recursive CTE member can not be referred inside derived table, no explanation yet 
  • Engine crashes when attempt to recreate table with FK after syntax error before such recreating
Result: CORE-4304
  • Poor performance of LIKE operator when when declared length of varchar field is long (e.g 32760) but string and pattern are both short ('q' and '%q%')
Result: CORE-4306
  • Tested special build ("RFC: Data page allocation algorithm" by Vlad Khorsun)
Result: server crashes when nbackup is running during updates, validation errors when DML was interrupted via kill (reported to Vlad Khorsun)
  • Found some issues about cursor stability during update tables (results mismatches with other RDBMS)
Result: test cases added to CORE-3362, regression is fixed by Vlad Khorsun
 
January 2014
  • Continued testing special build ("RFC: Data page allocation algorithm" by Vlad Khorsun)
Result: number of nbackup related errors were found, reported to Vlad Khorsun
  • Heavy-load test after applying Vlad's patch about page allocation (extents)
Result: no errors in SS, deadlock encountered in CS after ~9 hours of running
  • Tested the extents build on a database with master-detail tables
Result: extents built is better in selects from single table and especially in hash joins
  • Restore on LI-V2.5.3.26730 of production metadata (LI-V2.5.3.26546) was unexpectedly too long
Result: fixed by Dmitry Yemanov
  • Benchmarked analytical functions performance (linux ext4 mount options (sync vs async) and tempfiles setting)
Result: performance noticably drops as soon as TempCacheLimit is exhausted, even when temp directory if mapped to /dev/shm
  • Benchmarked hash join in v3.0 vs merge join in v2.5; also hash vs nested loops (both in v3.0)
Result: found some cases when hash join loses in performance, reported to Dmitry Yemanov
  • Server crashed with coredump at the disconnection time
Result: reported to Dmitry Yemanov, stack traces are provided
  • Deadlock while 10 connections are simultaneously querying MON$DATABASE and the database is under high load
Result: reported to Dmitry Yemanov, stack traces are provided
  • Benchmarked restoring of big database (48 Gb) on v2.5 vs v3.0, with and without services
Result: v2.5 without services is extremely slow, times are equal when services are used
  • Benchmarked parallel inserts from 10 isqls, v3.0 vs v2.5 (both in SuperClassic)
Result: v3.0 is faster than v2.5 when inserting 10^6 rows (no indexes, no sequences)

Pavel Zotov
Moscow, Russian Federation
December 2013 - January 2014

December 2013
  • Found ability for DoS attack when run script with a lot of connect commands with invalid password:
    there was no delay ~5-7 seconds between such attempts on some cases of config parameters
Result: confirmed and fixed by Alex Peshkoff
  • Descending indexes can be very inefficient in lookup/scan (found while testing INSERT performance)
Result: CORE-4302, fixed by Vlad Khorsun
  • Re-checked some old queries on which FB v3 had problems before (CORE-4261, etc)
Result: no problems anymore, a few performance related questions directed to Dmitry Yemanov
  • FB hangs on preparing of some queries, unable to establish new connect or asking MON$ tables during such prepare
Result: confirmed by Dmitry Yemanov
  • FB crashes when attempt to solve Einstein task (too complex 'where' condition)
Result: CORE-4293, fixed by Dmitry Yemanov
  • Resumed comparing results FB vs MS SQL vs ORA on misc. queries
Result: found that recursive CTE member can not be referred inside derived table, no explanation yet 
  • Engine crashes when attempt to recreate table with FK after syntax error before such recreating
Result: CORE-4304
  • Poor performance of LIKE operator when when declared length of varchar field is long (e.g 32760) but string and pattern are both short ('q' and '%q%')
Result: CORE-4306
  • Tested special build ("RFC: Data page allocation algorithm" by Vlad Khorsun)
Result: server crashes when nbackup is running during updates, validation errors when DML was interrupted via kill (reported to Vlad Khorsun)
  • Found some issues about cursor stability during update tables (results mismatches with other RDBMS)
Result: test cases added to CORE-3362, regression is fixed by Vlad Khorsun
 
January 2014
  • Continued testing special build ("RFC: Data page allocation algorithm" by Vlad Khorsun)
Result: number of nbackup related errors were found, reported to Vlad Khorsun
  • Heavy-load test after applying Vlad's patch about page allocation (extents)
Result: no errors in SS, deadlock encountered in CS after ~9 hours of running
  • Tested the extents build on a database with master-detail tables
Result: extents built is better in selects from single table and especially in hash joins
  • Restore on LI-V2.5.3.26730 of production metadata (LI-V2.5.3.26546) was unexpectedly too long
Result: fixed by Dmitry Yemanov
  • Benchmarked analytical functions performance (linux ext4 mount options (sync vs async) and tempfiles setting)
Result: performance noticably drops as soon as TempCacheLimit is exhausted, even when temp directory if mapped to /dev/shm
  • Benchmarked hash join in v3.0 vs merge join in v2.5; also hash vs nested loops (both in v3.0)
Result: found some cases when hash join loses in performance, reported to Dmitry Yemanov
  • Server crashed with coredump at the disconnection time
Result: reported to Dmitry Yemanov, stack traces are provided
  • Deadlock while 10 connections are simultaneously querying MON$DATABASE and the database is under high load
Result: reported to Dmitry Yemanov, stack traces are provided
  • Benchmarked restoring of big database (48 Gb) on v2.5 vs v3.0, with and without services
Result: v2.5 without services is extremely slow, times are equal when services are used
  • Benchmarked parallel inserts from 10 isqls, v3.0 vs v2.5 (both in SuperClassic)
Result: v3.0 is faster than v2.5 when inserting 10^6 rows (no indexes, no sequences)

Pavel Zotov
Moscow, Russian Federation