Project:
| View Revisions: Issue #20515 | [ Back to Issue ] | ||
| Summary | 0020515: OBCriteria creates contention at JVM | ||
| Revision | 2017-02-15 13:13 by alostale | ||
| Description | OBCriteria is still adding more overhead than OBQuery, after fix 0020485 it is slower. Note this measurement is just for overhead and not for query itself. Profiling attached test cases, it can be seen most of the time is spent in class loading triggered by Hibernate criteria (cpu-time.png). An additional problem is this classloading is synchronized by class name (lock-monitor.png), this in practice means, concurrent threads needs to wait these locks to be released in order to execute the criteria. The problem is the className SessionFactoryImpl.getImplementors receives [1] is not actually a classname but entity name, so ReflectHelper.classForName finally performs a locking Class.forName [2] [1] https://github.com/alostale/hibernate-orm/blob/3.6.3-patched/hibernate-core/src/main/java/org/hibernate/impl/SessionFactoryImpl.java#L827 [^] [2] https://github.com/alostale/hibernate-orm/blob/3.6.3-patched/hibernate-core/src/main/java/org/hibernate/util/ReflectHelper.java#L192 [^] |
||
| Revision | 2017-02-15 13:03 by alostale | ||
| Description | OBCriteria is still adding more overhead than OBQuery, after fix 0020485 it is slower. Note this measurement is just for overhead and not for query itself. Profiling attached test cases, it can be seen most of the time is spent in class loading triggered by Hibernate criteria (cpu-time.png). An additional problem is this classloading is synchronized by class name (lock-monitor.png), this in practice means, concurrent threads needs to wait these locks to be released in order to execute the criteria. |
||
| Revision | 2017-02-15 12:42 by alostale | ||
| Steps To Reproduce | Execute attached test cases which executes 50000 times a very simple sql comparing times between OBCriteria and OBQuery. These 50000 executions are done splitting them from 1 to 8 threads. The results in a laptop with 8 cores are: Criteria with 1 threads done in 14985 ms Criteria with 2 threads done in 13768 ms Criteria with 3 threads done in 14811 ms Criteria with 4 threads done in 14988 ms Criteria with 5 threads done in 15200 ms Criteria with 6 threads done in 15388 ms Criteria with 7 threads done in 15311 ms Criteria with 8 threads done in 15401 ms Query with 1 threads done in 3728 ms Query with 2 threads done in 1743 ms Query with 3 threads done in 1287 ms Query with 4 threads done in 1187 ms Query with 5 threads done in 1121 ms Query with 6 threads done in 1067 ms Query with 7 threads done in 1000 ms Query with 8 threads done in 955 ms Here we can see OBCriteria overhead is 5 times OBQuery's. But not only that, but parallel executions do not improve throughput in criteria's case. |
||
| Revision | 2017-02-15 12:42 by alostale | ||
| Description | OBCriteria is still adding more overhead than OBQuery, after fix 0020485 it is slower. Note this measurement is just for overhead and not for query itself. |
||
| Revision | 2017-02-15 12:38 by alostale | ||
| Steps To Reproduce | See 0020485 | ||
| Revision | 2017-02-15 12:38 by alostale | ||
| Description | OBCriteria is still adding more overhead than OBQuery, after fix 0020485 it is twice slower. Note this measurement is just for overhead and not for query itself. |
||
| Copyright © 2000 - 2009 MantisBT Group |
 |