Page History

...

Going forward, if the "V2" implementation matures, and can replace librecords (both internal and for APIs), it would be good to rename / replace the APIs above with the API names from Proposal #3 (below). This avoids having to migrate to yet another stats API, so while reviewing this, make sure the proposed APIs below will suffice.

Proposal

...

3a: Make new librecords based stats APIs

Finally, I'd like to propose adding a new set of APIs to ts/ts.h, exposing the librecords APIs to plugin writers. My proposed APIs are as follows:

  typedef enum
    {
      TS_STAT_TYPE_NULL = 0,
      TS_STAT_TYPE_INT,
      TS_STAT_TYPE_FLOAT,
      TS_STAT_TYPE_STRING,
      TS_STAT_TYPE_COUNTER,
    } TSStatDataType;

  typedef enum
    {
      TS_STAT_PERSISTENT_NULL = 0,
      TS_STAT_PERSISTENT,
      TS_STAT_NON_PERSISTENT
    } TSStatPersistence;

  typedef enum
    {
      TS_STAT_SYNC_SUM = 0,
      TS_STAT_SYNC_COUNT,
      TS_STAT_SYNC_AVG,
      TS_STAT_SYNC_TIMEAVG,
      TS_STAT_SYNC_MSECS_TO_SECONDS,
      TS_STAT_SYNC_MHR_TIMEAVG
    } TSStatSync;

  inkapi int TSRegisterStat(const char *the_name, TSStatDataType the_type, TSStatPersistence persist, TSStatSync sync);

  inkapi INKReturnCode TSStatIntIncrement(int the_stat, INK64 amount);
  inkapi INKReturnCode TSStatIntDecrement(int the_stat, INK64 amount);
  inkapi INKReturnCode TSStatFloatIncrement(int the_stat, float amount);
  inkapi INKReturnCode TSStatFloatDecrement(int the_stat, float amount);

  inkapi INKReturnCode TSStatIntGet(int the_stat, INK64* value);
  inkapi INKReturnCode TSStatIntSet(int the_stat, INK64 value);
  inkapi INKReturnCode TSStatFloatGet(int the_stat, float* value);
  inkapi INKReturnCode TSStatFloatSet(int the_stat, float value);

...

 CONFIG proxy.config.stat_api.max_stats_allowed INT 512

Performance with new APIs

This proposal exposes a few features of the internal librecords, but not everything. I believe the above would allow easy integration with existing stats, and also allow for plugin developers to use most features that the internal ATS core can use. This has the advantage of making it possible to move code out from the core and into a plugin, without losing  functionality or changing current behaviour. Implementing these in a future rewrite of the stats system would not be difficult, and if we decide to totally ditch these stats features in v3.0 or v4.0, we'd want new APIs anyways I think.

Performance with librecords

I've benchmarked the above APIs, with incrementing 2,000 stats out of a pool of either 10,000 or 50,000 total stats, for every request (in a plugin). For the first test (10k total stats), the librecords based APIs are slightly faster than the V2 stats. With 50,000 stats, the V2 stats are about 10% faster. I attribute this difference to the more advanced synchronization handlers that librecords provides, but I haven't honestly spent a lot of time trying to optimize anything. 10% is not a huge difference, and 50,000 stats is an incredible amount of stats to carry. For a slightly more reasonable setup (10,000 stats, which is still huge), the performance is very compteitive.

...