<concept xml:lang="en" id="GUID-62E1A29B-E95C-5E5B-969B-410A78114A3B"><title>Dynamic Compression</title><prolog><metadata><keywords/></metadata></prolog><conbody><section id="GUID-83A2D02E-143D-50AA-B26A-AAC3CAD72CD0"><title>Overview</title> <p>A contacts database will be compressed automatically by the server based on two compression thresholds. </p> <p>These thresholds are expressed in terms of the total number of Create, Update or Delete (CUD) operations performed on a contacts database since the last time the database was compressed. </p> <p>The first threshold is 16 CUD operations. Once this threshold is reached the server will request an “idle” compression. This type of compression will only result in a compression request (internal to the server) if there are no operations of higher priority carried out by the server within 1 second. </p> <p>The second threshold is 64 CUD operations. Once this threshold is reached the server will request an “immediate” compression. This type of compression will always result in a compression request. </p> </section> <section id="GUID-34843419-5945-5EE5-B3C0-2181D5A097CB"><title>Implementation Considerations</title> <p>Clients should still request database compression since short sessions with a database may not allow either of the CUD operation thresholds to be reached. </p> <p>There is no requirement to request compression during “bulk” operations (more than 64 CUD operations) but it is recommended to request a compression after any series of CUD operations, to ensure minimum fragmentation of the database. </p> </section> </conbody></concept>