[
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)
