Fine tuning via Preferences

  • Set Memory Limit %
  • Change/Set the DataBlock Size
  • Set Store Cache MRU Min/Max
  • Set Store Segment Growth Size, defaults to 512 Kb. Store Segment size dictates the amout of disk space the Store pre-allocates to store its member data when it is doing bulk write operations (LRU data offload to disk). Performance isn't much impacted with the Segment size as Store pretty much does data layout in-memory, most "perceived disk I/O" operations are done in memory using the MRU cache and involving mathematical disk offset calculations. Disk I/O is prevented when data fits in-memory to keep Store's performance optimal.
  • Persist Value in Store's Key Segment, the closest thing to a Clustered index in SQL/RDBMS. It is recommended to set Store's IsDataInKeySegment flag true when member Value being stored is fair sized, however, if it is big as in it may occupy more than the set DataBlock size (defaults to 512 bytes), then keep this false so member Value's serialized data is stored in the Data Segment. When member Value's data is in Key segment, Store is able to compact all the members' Key/Value pair data of B-Tree Node page within a contiguous allocated space on disk. This means Store performance will be optimal during I/O as it will be able to do a bulk, one swipe disk read/write action for both Keys & Values of the Node page. The member Value will also be always available when get accessor is invoked as it is loaded part of the B-Tree Node page. If member Value's data is saved in the Data Segment, it will get loaded into the cache during the 1st Value getter call by the code (a.k.a. - delayed loading). This approach is optimized for storing large sized entities, however, it is recommended to fine tune and measure performance/utilization based on the Preferences & target Host PC "resources" as required by the application.
  • Set Store B-Tree Node Slot Size, defaults to 200 member items per B-Tree Node. Set this to your desired amount, however, be aware that the bigger the Node size, the bigger the amount of memory required to buffer an individual Node page when it gets loaded from disk. Store's MRU algorithm will keep the memory utilization at bay, but if individual Node page takes up huge amount of memory then it may still give a noticeable perf/utilization impact.
  • Set StoreFactory's Store Count in Pool
  • Set Encoding
  • Set Max Collection Count
  • Memory Extender Mode
  • Increasing maximum opened files. If this profile is set, SOP internally calls WIN32 "_setmaxstdio" in order to update the maximum number of opened files to allow application to adjust it. SOP manages virtualization and implements MRU algorithm on opened File Streams thus, although the number of opened Files can't reach the thousand range typically because of the host computer's limited resources, SOP still, can offer a decent, very high performance because of MRU algorithm based opened File stream virtualization.

Last edited Jan 9, 2013 at 6:41 AM by grecinto, version 1


No comments yet.