[
https://issues.apache.org/jira/browse/TRAFODION-3280?focusedWorklogId=223357&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-223357
]
ASF GitHub Bot logged work on TRAFODION-3280:
---------------------------------------------
Author: ASF GitHub Bot
Created on: 04/Apr/19 23:43
Start Date: 04/Apr/19 23:43
Worklog Time Spent: 10m
Work Description: selvaganesang commented on pull request #1824:
[TRAFODION-3280] Reduce path length in Trafodion for improved performance and
scalability
URL: https://github.com/apache/trafodion/pull/1824
Removed/avoided the following APIs shown as hotspots when Trafodion is run
with OLTP kind of queries.
java.net.Socket.setSoTimeout
org.trafodion.jdbc.t4.T4LoggingUtilities.log
java.net.Socket.getLocalSocketAddress
java.lang.String.split
java.lang.String.replaceAll
java.lang.Class.getMethod
org.trafodion.jdbc.t4.TrafT4ResultSet.findColumn
Now socket.read waits for the network timeout. It can be configured via a
property networkTimeout or call to connection.setNetworkTimeout. If the
networkTimeout is not configured, a default value of 10 secs is assumed.
The caller is expected to set the timeout depending upon the operation being
performed like loginTimeout, queryTimeout. Socket.read will wake up for every
networkTimeout expiration and check if the timeout for the operation hasn't
exceeded. When it exceeds, SocketTimeoutException is thrown.
Changed the T4Statement and T4Restult classes to have "has a" relationship
with T4Connection for better understanding of the code. Earlier, it had "is a"
relationship with T4Connection.
JDBC driver was parsing the sql string passed to it by the application to
determine the type of SQL statement and to check if the sql string has
parameters. It doesn't parse the sql string anymore
and passes the sql string to SQL engine via mxosrvr. In case of
PreparedStatement, the JDBC driver will
set the sqlStmtType based on the query type returned. In case of Statement,
the JDBC driver will set the
sqlStmtType as SQL_TYPE_UNKNOWN.
Now, the PreparedStatement is always prepared for setting array values for
parameter for all
statement types such as IUD and select. SQL engine will report an error if
the array values are
not supported for any statement type.
Changed Hashtable to HashMap where possible with the assumption that the
JDBC connection
shouldn't be used from different threads. TrafT4Connection object needs be
made thread-safe.
Optimized org.trafodion.jdbc.t4.TrafT4ResultSet.findColumn by using HashMap
of columnName to
columnIndex. This should avoid excessive calls to
java.lang.String.equalsIgnoreCase.
Removed excessive calls to java.lang.Class.getMethod from TrafT4ResultSet.
When the statement type is TYPE_UNKNOWN, mxosrvr was executing the extra code
to load controls, GetHashInfo etc. GetHashInfo was corrupting the sqlString
by
truncating spaces in between the literals. Removed these code from mxosrvr
because it is specific to QueryStatsServer as part of NeoView and WMS.
There are many places in our code getenv is called repeatedly. Cleaned up
code so that
repeated getenv calls are avoided during prepare and execute operations.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 223357)
Time Spent: 2.5h (was: 2h 20m)
> Reduce path length in Trafodion for improved performance and scalability
> -------------------------------------------------------------------------
>
> Key: TRAFODION-3280
> URL: https://issues.apache.org/jira/browse/TRAFODION-3280
> Project: Apache Trafodion
> Issue Type: Improvement
> Components: sql-general
> Reporter: Selvaganesan Govindarajan
> Assignee: Selvaganesan Govindarajan
> Priority: Major
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> To improve OLTP kind of queries, a sample application was profiled to
> determine the unnecessary dominant functions in Trafodion. It is found that
> # JULIANTIMESTAMP was abnormally taking longer path length.
> # Unnecessary memset after malloc because new and delete operators were
> overloaded.
> This Jira will act as covering Jira for future enhancements too
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
