https://docs.protegrity.com/cloud-protect/4.0.0/docs/gcp/api/performance/Recent content in Performance onHugoenhttps://docs.protegrity.com/cloud-protect/4.0.0/docs/gcp/api/performance/performance_considerations/Mon, 01 Jan 0001 00:00:00 +0000https://docs.protegrity.com/cloud-protect/4.0.0/docs/gcp/api/performance/performance_considerations/<h2 id="performance-considerations">Performance Considerations</h2> <p>The following factors may affect performance benchmarks:</p> <ul> <li><strong>Cold startup:</strong> Cloud Function spends additional time on the initial invocation to decrypt and load the policy into memory. This time can vary depending on the policy size. Once the Function is initialized, subsequent “warm executions” should process quickly.</li> <li><strong>Size of policy:</strong> The size of the policy impacts cold start performance. Larger policies take more time to initialize.</li> <li><strong>Cloud Function memory:</strong> GCP provides more virtual cores based on the memory configuration. The initial configuration of 2048 MB provides a good tradeoff between performance and cost with the benchmarked policy. Memory can be increased to optimize for your individual cases.</li> <li><strong>Number of security operations (protect or unprotect)</strong>.</li> <li><strong>Cloud Function max instances and concurrency quota:</strong> The instance limit affects how functions are scaled. By default the limit is not set to allow handling any traffic pattern. The instance limit can be set to prevent abnormally high request levels. Cloud Functions are also subject to maximum quota for concurrent invocations and request rate.</li> <li><strong>Size of data element:</strong> Operations on larger text consume time.</li> </ul>https://docs.protegrity.com/cloud-protect/4.0.0/docs/gcp/api/performance/log_forwarder/Mon, 01 Jan 0001 00:00:00 +0000https://docs.protegrity.com/cloud-protect/4.0.0/docs/gcp/api/performance/log_forwarder/<p> <ol id="toc"></ol> <script> // JavaScript to generate the table of contents from H2 headings document.addEventListener("DOMContentLoaded", function () { //get all h2 headings within the 'main' element and generate a toc with links to them //excluding h2 heading 'Feedback' if it exists const toc = document.getElementById("toc"); const headings = document.querySelectorAll("main h2"); headings.forEach(heading => { if (heading.textContent === "Feedback") { return; // Skip the 'Feedback' heading } const li = document.createElement("li"); const a = document.createElement("a"); const id = heading.textContent.toLowerCase().replace(/\s+/g, '-'); heading.id = id; // Set the id for the heading a.href = `#${id}`; a.textContent = heading.textContent; li.appendChild(a); toc.appendChild(li); }); }); </script> <h2 id="log-forwarder-performance">Log Forwarder Performance</h2> <p>Log forwarder architecture is optimized to minimize the amount of connections and reduce the overall network bandwidth required to send audit logs to ESA. This is achieved with batching and aggregation taking place on two levels. The first level is in protector function instances, where audit logs from consecutive requests to an instance are batched and aggregated. The second level of batching and aggregation takes place in the log forwarder function before audit logs are forwarded to ESA. This section shows how to configure the deployment to accommodate different patterns of anticipated audit log stream. It also shows how to monitor deployment resources to detect problems before audit records are lost.</p>