[
https://issues.apache.org/jira/browse/PHOENIX-8007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18119541#comment-18119541
]
Tanuj Khurana commented on PHOENIX-8007:
----------------------------------------
*Wall* decomposition of *getIndexMetaDataCacheFromPTable* (async-profiler `-e
wall`, 6,891 samples):
{code:java}
| sub-path | % of path wall |
|---|---|
| `PhoenixConnection.getTable` → `getTableNoCache` (SYSTEM.CATALOG RPC) |
**58.5%** |
| `DriverManager.getConnection` (per-batch `PhoenixConnection` build) |
**27.2%** |
| `getConnectionUrl` (config resolution) | 6.0% |
| `combineProperties` (`Configuration.iterator`) | 4.9% |
{code}
*Lock*
the shared-`Configuration` monitor (`getConnectionUrl` + `combineProperties`)
is 49–57% of all lock contention
> Index metadata lookup on the server creates a new Server connection on every
> commit
> -----------------------------------------------------------------------------------
>
> Key: PHOENIX-8007
> URL: https://issues.apache.org/jira/browse/PHOENIX-8007
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 5.4.0, 5.3.1
> Reporter: Tanuj Khurana
> Assignee: Viraj Jasani
> Priority: Major
> Attachments: 7727-server-lock-flamegraph.html,
> 7727-server-wall-flamegraph.html
>
>
> PHOENIX-7727 added _phoenix.index.useServerMetadata_ (default true) to
> eliminate the client _addServerCache_ RPC by having the region server rebuild
> the I{_}ndexMaintainer{_} from its PTable cache per batch
> {_}PhoenixIndexMetaDataBuilder.getIndexMetaDataCacheFromPTable{_}. It builds
> a fresh PhoenixConnection per batch which contributes to wall latency and
> under concurrent load has lock contention. I have attached both wall and lock
> flamegraphs which show the contribution of new connection. I think we can
> create the connection lazily per region but we have to be careful if the
> connection is reaped and closed for example when cqsi closes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
