[jira] [Resolved] (CALCITE-1086) Statement is unnecessarily sent from client in update (write) path

["Josh Elser (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CALCITE-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josh Elser resolved CALCITE-1086.
---------------------------------
       Resolution: Fixed
    Fix Version/s:     (was: next)
                   1.7.0

Fixed in https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=ea41b3412f099c8f1051f1b324b1ba03d644962a

> Statement is unnecessarily sent from client in update (write) path
> ------------------------------------------------------------------
>
>                 Key: CALCITE-1086
>                 URL: https://issues.apache.org/jira/browse/CALCITE-1086
>             Project: Calcite
>          Issue Type: Sub-task
>          Components: avatica
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>            Priority: Critical
>             Fix For: 1.7.0
>
>
> I've had my nose buried in profilers and Avatica evaluating the write performance. Using Phoenix as the golden child, it was found that, compared to HBase REST server (also doing updates over HTTP), Avatica was performing quite a bit slower (2-3x).
> The client was doing something like:
> {code}
> prepare()
> for x in 0..1000:
>   for x in 0..1000:
>     execute()
>   end
>   commit()
> end
> {code}
> One of the first big things that jumped out at me was that we were spending a significant amount of time deserializing Meta.Signature (and all of its internal classes: AvaticaParameter, ColumnMetaData, CursorFactory, Style, etc).
> When we're ultimately doing a {{PreparedStatement.executeUpdate()}} inside {{JdbcMeta.execute()}}, we completely ignore the Signature. This turns out to be relatively significant WRT the entire cost of the execute. At the 99th percentile, serialization was taking ~40% of the time of the entire execute RPC. My hunch is that if we can drop the Statement from the client (when they use executeUpdate(), anyways), we can get a nice reduction in update latency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)