What is the purpose of the property, Server.Config.UStringPoolCapacity

  • 7006251
  • 09-Jun-2010
  • 11-Jul-2012

Environment


Business Service Manager
Business Service Manager 4.5

Situation

You need to tune the performance of BSCM jobs and you are using the "Copy properties from structure elements", option.

The, copy to, feature can cause a high volumes of config store access, the default attribute cache settings may to low and contribute to the performance issue.

The attribute cache is dynamic and will not cache attribute values if there are too many unique values.

For instance, an attribute that contained state names in a country would be an excellent choice to cache, an attribute value that contained an unbounded counter for the number of events in a system would be a bad choice.

By default, attribute values are cached until they reach 512 unique values, all values are then flushed from the cached and the attribute is marked as, not pooled. From that point forward, until an application restart, values for that attribute will not be cached.

Resolution

You can adjust the number of unique values cached.

You'll need to run some analysis first.

Create a server side operation that runs this script line:
formula.log.info(server.elementPersistence.cacheDetails)

Run the operation and examine the .../logs/formula.trc.

You should something like this:
2010-06-04 09:40:44,899 INFO Script.Operation 'cache_statistics' -
Entries: 2,804,335
Relationships: 2,720,984
Attribute cache item limit: 4,096
Attribute name set cache size: 272
Strings held: 1,821,119
Non-strings held: 180,260
String size: 15.86MB
Non-strings size: 4.13MB
Attribute cache overhead estimate: 54.42MB
Attribute cache overhead instances: 782,496
UStringPool: UString memory: 13,525.49KB bytes, 186598 strings
UString string pool: 186598
UString pools: 202
  + Auditable: always pooled, 0 strings
  - Client: not pooled, 177489 strings
  - Client Label: not pooled, 177489 strings
  - Drawing: not pooled, 0 strings
  + Flags: always pooled, 0 strings
  - GraphicStream: not pooled, 0 strings
  - LastChangedBy: not pooled, 0 strings
  - LastChangedOn: not pooled, 0 strings
  - MetamodelDefinition: not pooled, 460 strings
  + Rollup: always pooled, 10 strings
  + RollupDisseminates: always pooled, 0 strings
  + RollupParameters: always pooled, 7 strings
  - SVG_Drawing: not pooled, 145 strings

The plus sign, means always pool, minus sign, never pooled. The text, not pooled, means the field is cached, because either it had too many unique values, or the values were too large in byte size.

Now focus on the attributes, Client and Client label, they are marked, not pooled and have a large number of access attempts. There can be confusion here, because if an attribute is not pooled, the output shows the number of cache hits not the number of unique values.

To be clarify from the example, the Client attribute, has not been cached, and there has been, 177489, requests for it's values.

Before running the next test, you should capture the BSCM jobs run times, before and after setting the cache property.

In the ../config/formula.custom.properties, set this property and restart the application:
Server.Config.UStringPoolCapacity=50000

Let the system run for awhile, at least until the BSCM jobs have run a few times. Then check the cache statistics.

Statistic, shortened:
    Client: 44537 entries, 695.93KB
    Client Label: 44538 entries, 1,304.86KB

Now, both, Client and Client Label, have been cached, because they have fewer unique values than 50000, avoiding config store access for those values.

Most values are cheap to cache, but if you have a large number attributes with many unique values, you must determine if the trade off between memory and performance is acceptable.