vlsi

The goal is to make the following query perform an index range scan z_line_items on item_id column,
then broadcast the results to the slaves that would join z_orders table and check the order type.

Even though line_item scan is serial, the join of orders should go in parallel.

Oracle DB 11g is required. In Oracle 12c just adding parallel(n) is sufficient.

select sum(li.price)
  from z_line_items li
     , z_orders o

vlsi

import java.time.Duration;
import java.util.Optional;

public class Jre7Test {
        public static class MyClass {
                public Optional<Duration> optional(java.time.Duration duration) {
                        return Optional.of(duration);
                }

                public void say(String greeting) {

vlsi

# i7-4960HQ CPU @ 2.60GHz, jdk1.8.0_51
Benchmark                                                                   Mode  Cnt    Score    Error   Units
ControlFlowExceptionBenchmark.baseline                                      avgt   10    8,434 ±  0,374   ns/op
ControlFlowExceptionBenchmark.baseline:·gc.alloc.rate                       avgt   10    0,002 ±  0,006  MB/sec
ControlFlowExceptionBenchmark.baseline:·gc.alloc.rate.norm                  avgt   10   ≈ 10⁻⁵             B/op
ControlFlowExceptionBenchmark.baseline:·gc.count                            avgt   10      ≈ 0           counts
ControlFlowExceptionBenchmark.nonWritable                                   avgt   10   16,805 ±  1,247   ns/op
ControlFlowExceptionBenchmark.nonWritable:·gc.alloc.rate                    avgt   10  909,666 ± 61,399  MB/sec
ControlFlowExceptionBenchmark.nonWritable:·gc.alloc.rate.norm               avgt   10   16,000 ±  0,003    B/op
ControlFlowExceptionBenchmark.nonWritable:·gc.churn.PS_Eden_Space           avgt   10  90

vlsi

This is a result of running https://github.com/vlsi/microbenches/commit/34c694dcb48acce0a37334631747fb371d80c80f

1) Best result for testSingle is for java7u55+catch(AIOOBE), however java7's results are not stable

2) java 7 results are very unstable:
For isntance:
# Warmup Iteration   1: 548,557 ns/op
...
# Warmup Iteration   6: 102,104 ns/op
...

vlsi

This is a result logs of running

mvn release:clean release:prepare
mvn release:perform

in https://github.com/vlsi/pgjdbc/commits/sample_release branch

vlsi

-- This sample reproduces a bug of a "sudden" flip of a server-prepared statement in PG 9.2+
-- In this particular case, backend selects very bad index even though bind values are the same and the table is analyzed

TL;DR: if you want to know true execution plan for a query with bind variables, you must use "prepare...";
       then repeat "explain analyze execute" 6 times :)

-- Note: do not confuse "5 executions before pgjdbc starts to use server-prepared statements" with
--       "first 5 executions of a server-prepared statement before plan flip"

-- Here's discussion in pgsql-hackers list:

vlsi

Vladimir Sitnikov is currently working on performance and scalability of NetCracker OSS.
Telecommunication companies world wide use NetCracker OSS for enterprise and network automation.
Vladimir is keen on Java and database performance: Oracle, PostgreSQL. He’s one of the committers
in the PostgreSQL JDBC driver project, and architect of many performance improvements.

Abstract.

Common Java wisdom is to use PreparedStatements and Batch DML in order to achieve top performance.
It turns out one cannot just blindly follow the best practices. In order to get high throughput, you need
to understand the specifics of the database in question, and the content of the data.

vlsi

When builing large strings with lots of concatenations in PL/SQL, custom approach like "use varchar2(32000) buffer to reduce the number of dbms_lob calls" makes sense even for Oracle 12.1.0.2.0.

The response time improvement is 4..300+ times :) depending on the DB version and API you use.

Note that simple v_clob || TO_CHAR (SYSTIMESTAMP) || ', ' ==> v_clob || TO_CLOB(TO_CHAR (SYSTIMESTAMP) || ', ') trick (note the extra to_clob) makes 24 times improvement for 11g. The trick is bad for 12c where results in 1.5x degradation.

The code was published 4 year ago as an answer to "How to Quickly Append VARCHAR2 to CLOB": http://www.talkapex.com/2009/06/how-to-quickly-append-varchar2-to-clob.html?showComment=1343235921606#c9077980873875311325

vlsi

Current JMeter's JMX files are not human-readable, and it is hard to review "diff" between two versions of a script.

I suggest adding a human-readable comment to the start of the file, so the diff between scripts can be easier to understand:

<?xml version="1.0" encoding="UTF-8"?>
<!--
Test plan:
   Thread group (146 threads, 1:00:00 duration)
      login (http sampler /login)

vlsi

drop table vlsi;

create table vlsi(pk int4, type numeric, vc varchar(500), num numeric);

insert into vlsi(pk, type,vc,num) select s.x, round(x/1000), md5('||x)||md5('||x+1)||md5(''||x+2), mod(x, 1000)
  from generate_series(1,1000000) as s(x);

-- Several values exceeed 128 substr, so they require "table access"
insert into vlsi(pk, type,vc,num) select s.x+1000000, round(x/1000), lpad('a', 128, 'a')||'zxc'||s.x||'v', mod(x, 1000)
  from generate_series(1,10) as s(x);