Skip to content

Conversation

@cezarfx
Copy link
Member

@cezarfx cezarfx commented Aug 27, 2021

Stats are collected on the client application, when system property
-Dcom.oracle.nosql.sdk.nosqldriver.stats.profile=[regular|full] is used,
for an interval of time, set by
-Dcom.oracle.nosql.sdk.nosqldriver.stats.interval=600 in seconds.

The following stats are collected for each type of request: count,
wire latencies, request and response sizes, errors, retries, retry delay,
rate limit delay. Also if rateLimiting is enabled and concurrent connections
number.

StatsConfig also provides an API to programmatically configure the statistics
collection, to selectively start and stop collection and get access to
collected statistics.

Stats are collected on the client application, when system property
-Dcom.oracle.nosql.sdk.nosqldriver.stats.profile=[regular|full] is used,
for an interval of time, set by
-Dcom.oracle.nosql.sdk.nosqldriver.stats.interval=600 in seconds.

The following stats are collected for each type of request: count,
wire latencies, request and response sizes, errors, retries, retry delay,
rate limit delay. Also if rateLimiting is enabled and concurent connections
number.

StatsConfig also provides an API to programaticaly configure the statistics
collection, to selectively start and stop collection and get access to
collected statistics.
Fixed throttle counter bug.
Misc javadoc and clearer param and var names.
 - renamed methods and fields
 - create full stats structure at the beginning to avoid sync locks.
 - switched avg calculation based on sum to be more accurate for smaller number of samples.
 - encapsulated writes and reads into their classes for moving sync on methods.
cezarfx and others added 6 commits September 13, 2021 19:20
Updated javadoc.
Updated javadoc.
Adding detailed per query stats into the new profile.
Renamed wireLatency to networkLatency, included Ms suffix for latency and delay entries to describe millisecond unit.
Renamed reqSize and resSize to requestSize and resultSize.
Add a stats log entry at end, just before shutdown.
Fixed several javadoc params and added a sample output.
Avoid NPE for Prepared statements without a driverPlan.
Get statement from QueryRequest when available inside the prepared statement.
Renamed wireLatency to networkLatency.
Using capital L for long numerals.
Fix initial message to conform to JSON.
/**
* Returns configuration object for statistics.
* Statistics, when enabled, contain information like errors, delays, retries
* and wire latency agregated on types of requests.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: agregated

* }
* </code></p>
*/
public interface StatsConfig {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is StatsConfig an interface? It seems like an unnecessary abstraction

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To hide away implementation details and avoid user distractions.

@gmfeinberg
Copy link
Contributor

gmfeinberg commented Oct 20, 2021

I still have some general comments:

  1. The relationship among StatsConfig, StatsConfigImpl, Stats and how a user gets/uses/configures stats is confusing. Usually in our system a "Config" class is created essentially as a complex options object to construction of another class, in this case Stats. This is not the case here. StatsConfig is an interface, StatsConfigImpl is a "live" implementation in that changes to it at run time will (I think) affect the running stats. This is confusing and not typical. I would expect a StatsConfig object (not interface) that is used to create Stats and is not live after that. Ultimately we may want direct user control over starting/stopping/acquiring stats and how that might happen is not clear either. Maybe I'm missing something from the spec

  2. I suggested separately to create a getName() interface on Request to avoid the calls like request.getClass().getSimpleName(). Is there a reason to not do this? It'd be simpler and more efficient. Minimally create a local method to do this (String getName(Request)). This approach would also make the mapping of request names more reliable than code like this:
    String requestClass = kvRequest.getClass().getSimpleName();
    requestClass = requestClass.endsWith("Request")
    ? requestClass.substring(0, requestClass.length() - 7) :
    requestClass;
    rStat = requests.get(requestClass);

  3. New files are missing Copyright headers

  4. Stats.java has no comments at all

@connelly38
Copy link
Member

1. The relationship among StatsConfig, StatsConfigImpl, Stats and how a user gets/uses/configures stats is confusing. Usually in our system a "Config" class is created essentially as a complex options object to construction of another class, in this case Stats. This is not the case here. StatsConfig is an interface, StatsConfigImpl is a "live" implementation in that changes to it at run time will (I think) affect the running stats. This is confusing and not typical. I would expect a StatsConfig object (not interface) that is used to create Stats and is not live after that. Ultimately we may want direct user control over starting/stopping/acquiring stats and how that might happen is not clear either. Maybe I'm missing something from the spec

After reading this again, I agree with George. StatsConfig should just be a class. No need for an Impl.

@gmfeinberg
Copy link
Contributor

I'm also confused about what the extra query stats are storing. Can you talk about them? I didn't expect stats per statement that would include the statement and driver side query plan

@cezarfx
Copy link
Member Author

cezarfx commented Oct 21, 2021

I'm also confused about what the extra query stats are storing. Can you talk about them? I didn't expect stats per statement that would include the statement and driver side query plan

The query request stats are too generic when trying to find out what query is doing something significant. The extra query stats show the query stats on a per query statement base. This way certain query can be identified by checking its stats.

@cezarfx
Copy link
Member Author

cezarfx commented Oct 21, 2021

  1. The relationship among StatsConfig, StatsConfigImpl, Stats and how a user gets/uses/configures stats is confusing. Usually in our system a "Config" class is created essentially as a complex options object to construction of another class, in this case Stats. This is not the case here. StatsConfig is an interface, StatsConfigImpl is a "live" implementation in that changes to it at run time will (I think) affect the running stats. This is confusing and not typical. I would expect a StatsConfig object (not interface) that is used to create Stats and is not live after that. Ultimately we may want direct user control over starting/stopping/acquiring stats and how that might happen is not clear either. Maybe I'm missing something from the spec

StatsConfig is the interface that allows users to enable/disable the collection of stats and set which stats to collect. It is live because users can start/stop or change collection at anytime, useful for debugging hard to reproduce or transitory issues.

  1. I suggested separately to create a getName() interface on Request to avoid the calls like request.getClass().getSimpleName(). Is there a reason to not do this? It'd be simpler and more efficient. Minimally create a local method to do this (String getName(Request)). This approach would also make the mapping of request names more reliable than code like this:
    String requestClass = kvRequest.getClass().getSimpleName();
    requestClass = requestClass.endsWith("Request")
    ? requestClass.substring(0, requestClass.length() - 7) :
    requestClass;
    rStat = requests.get(requestClass);

Adding a getName() would be another way to do it.

  1. New files are missing Copyright headers
    Adding headers.
  1. Stats.java has no comments at all
    Adding comments.

…o StatsControl.

Added copyright comments to new files.
Renamed: count to httpRequestCount, networkLatencyMs to httpRequestLatencyMs, countAPI to count for query requests and stmt to query.
Added stacktrace to log when there is an exception during stats logging.
Using request.getName() for all request types.
@gmfeinberg
Copy link
Contributor

@cezarfx There are javadoc warnings in mvn. See "mvn javadoc:javadoc"

public class StatsControlImpl
implements StatsControl {

static public final String LOG_PREFIX = "ONJS:Monitoring stats|";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where did this prefix come from? It seems a bit awkward. Why not just something simple like "STATS" or "STATISTICS" ?

@cezarfx cezarfx merged commit 752c1ea into main Nov 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants