<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Performance on</title><link>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/</link><description>Recent content in Performance on</description><generator>Hugo</generator><language>en</language><atom:link href="https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/index.xml" rel="self" type="application/rss+xml"/><item><title>Performance Considerations</title><link>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/ssf_performance_considerations/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/ssf_performance_considerations/</guid><description>&lt;h2 id="performance-considerations">Performance Considerations&lt;/h2>
&lt;p>The following factors may cause variation in real performance versus benchmarks:&lt;/p>
&lt;ul>
&lt;li>&lt;strong>Cold startup:&lt;/strong> The Lambda spends additional time on the initial invocation to decrypt and load the policy into memory. This time can vary between 400 ms and 1200 ms depending on the policy size. Once the Lambda is initialized, subsequent “warm executions” should process quickly.&lt;/li>
&lt;li>&lt;strong>Size of policy:&lt;/strong> The size of the policy impacts cold start performance. Larger policies take more time to initialize.&lt;/li>
&lt;li>&lt;strong>Noisy neighbors:&lt;/strong> There are many multi-tenant components in the Cloud. The same request may differ by 50% between runs regardless of Protegrity. A single execution may not be the best predictor of average performance.&lt;/li>
&lt;li>&lt;strong>Lambda memory:&lt;/strong> AWS provides more virtual cores based on the memory configuration. The initial configuration of 1728 MB provides a good tradeoff between performance and cost with the benchmarked policy. Memory can be increased to optimize for your individual cases.&lt;/li>
&lt;li>&lt;strong>Cluster size:&lt;/strong> Cluster size may make a significant difference depending on the workload.&lt;/li>
&lt;li>&lt;strong>Number of operations&lt;/strong> Number of protect, unprotect and reprotect security operations.&lt;/li>
&lt;li>&lt;strong>Lambda concurrency and burst quotas:&lt;/strong> AWS limits the number of concurrent executions and how quickly lambda can scale to meet demand. This is discussed in an upcoming section of the document.&lt;/li>
&lt;li>&lt;strong>Size of data element:&lt;/strong> Operations on larger text consume time.&lt;/li>
&lt;/ul></description></item><item><title>Sample Benchmarks</title><link>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/ssf_sample_benchmarks/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/ssf_sample_benchmarks/</guid><description>&lt;h2 id="sample-benchmarks">Sample Benchmarks&lt;/h2>
&lt;p>The following benchmarks were performed against different cluster sizes.
These are median times of approximately five runs each.
The query unprotected six columns per row (first_name, last_name, email, postal_code, ssn, iban):&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>Rows x Cols&lt;/th>
 &lt;th># Ops&lt;/th>
 &lt;th>Small&lt;/th>
 &lt;th>Medium&lt;/th>
 &lt;th>Large&lt;/th>
 &lt;th>XL&lt;/th>
 &lt;th>2XL&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;strong>100K x 6 cols&lt;/strong>&lt;/td>
 &lt;td>600K&lt;/td>
 &lt;td>5.1&lt;/td>
 &lt;td>4&lt;/td>
 &lt;td>4.2&lt;/td>
 &lt;td>4.3&lt;/td>
 &lt;td>4.3&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;strong>1M x 6 cols&lt;/strong>&lt;/td>
 &lt;td>6M&lt;/td>
 &lt;td>11&lt;/td>
 &lt;td>10&lt;/td>
 &lt;td>11&lt;/td>
 &lt;td>10&lt;/td>
 &lt;td>11&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;strong>10M x 6 cols&lt;/strong>&lt;/td>
 &lt;td>60M&lt;/td>
 &lt;td>21.5&lt;/td>
 &lt;td>21.5&lt;/td>
 &lt;td>20.5&lt;/td>
 &lt;td>24.5&lt;/td>
 &lt;td>29&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;strong>100M x 6 cols&lt;/strong>&lt;/td>
 &lt;td>600M&lt;/td>
 &lt;td>-&lt;/td>
 &lt;td>-&lt;/td>
 &lt;td>49.5&lt;/td>
 &lt;td>56.5&lt;/td>
 &lt;td>87&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table></description></item><item><title>Concurrency</title><link>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/ssf_concurrency/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/ssf_concurrency/</guid><description>&lt;h2 id="concurrency">Concurrency&lt;/h2>
&lt;p>Snowflake provides guidance on the maximum concurrent requests to the Protegrity API.
However, reaching this maximum request depends on additional factors, such as, cluster
use and available resources. In addition, depending on the query plan, individual
batches may be processed serially across different UDFs.&lt;/p>
&lt;p>The formula for theoretical maximum Snowflake concurrency is N * C * M * E * P:&lt;/p>
&lt;ul>
&lt;li>&lt;strong>N&lt;/strong> - # of servers in the cluster (e.g. 2xl = 32, xl = 16)&lt;/li>
&lt;li>&lt;strong>C&lt;/strong> - # of CPUs. This is typically 8, but depends on the hardware.&lt;/li>
&lt;li>&lt;strong>M&lt;/strong> – parallelism multiplier (fixed to 8)&lt;/li>
&lt;li>&lt;strong>E&lt;/strong> - # of external functions invoked&lt;/li>
&lt;li>&lt;strong>P&lt;/strong> - # of queries in running in parallel&lt;/li>
&lt;/ul>
&lt;p>The following table shows this calculation for a single query.&lt;/p></description></item><item><title>Concurrency Tuning</title><link>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/concurrency-tuning/ssf_concurrency_tuning/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/concurrency-tuning/ssf_concurrency_tuning/</guid><description>&lt;ol id="toc">&lt;/ol>
&lt;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);
 });

 });
&lt;/script>



&lt;p>

 




	






 
 
 






 &lt;h2 id="lambda-tuning">Lambda Tuning&lt;/h2>
&lt;p>AWS maintains quotas for Lambda concurrent execution. Two of these quotas impact concurrency and compete with other Lambdas in the same account and region:&lt;/p></description></item><item><title>Log Forwarder Performance Tuning</title><link>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/cp_aws_log_forwarder_tuning/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/cp_aws_log_forwarder_tuning/</guid><description>&lt;h2 id="log-forwarder-performance">Log Forwarder Performance&lt;/h2>
&lt;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 protect function instances, where audit logs from consecutive requests to an instance are batched and aggregated. The second level of batching takes place in Amazon Kinesis Stream where log records from different protect function instances are additionally batched and sent to log forwarder function where they are aggregated. 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.&lt;/p></description></item><item><title/><link>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/concurrency-tuning/ssf_api_gateway_tuning/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/concurrency-tuning/ssf_api_gateway_tuning/</guid><description>&lt;h2 id="api-gateway-tuning">API Gateway Tuning&lt;/h2>
&lt;p>AWS maintains a Throttle quota for the API Gateway. By default, API Gateway limits concurrent requests to 10,000 requests per second and throttles subsequent traffic with a &lt;strong>429 Too Many Requests&lt;/strong> error response. This quota applies across all APIs in an account and region.&lt;/p>
&lt;p>The API Gateway default quota may need to be increased based on the Concurrency table in &lt;a href="https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/concurrency-tuning/ssf_lambda_tuning/">Lambda Tuning&lt;/a>. Keep in mind that hitting quota limits effectively throttles any other API services in the region.&lt;/p></description></item><item><title/><link>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/concurrency-tuning/ssf_cold_start_perf/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/concurrency-tuning/ssf_cold_start_perf/</guid><description>&lt;h2 id="cold-start-performance">Cold-Start Performance&lt;/h2>
&lt;p>Cold-start vs warm execution refers to the state of the Lambda when a request is received. A cold-start undergoes additional initialization, such as, loading the security policy. Warm execution applies to all subsequent requests served by the Lambda. The following table shows an example how these states impact latency and performance.&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>Execution state&lt;/th>
 &lt;th>Avg. Execution Duration&lt;/th>
 &lt;th>Avg. Total (w/ network latency)&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;strong>Cold execution&lt;/strong>&lt;/td>
 &lt;td>438 ms&lt;/td>
 &lt;td>522 ms&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;strong>Warm execution&lt;/strong>&lt;/td>
 &lt;td>&amp;lt; 2ms&lt;/td>
 &lt;td>84 ms&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>


&lt;div class="alert alert-info" role="alert">
&lt;h4 class="alert-heading">Note&lt;/h4>

 &lt;ul>
&lt;li>Cold execution time will vary based on the physical size of the security policy. A large security policy will result in longer cold startup times.&lt;/li>
&lt;/ul>


&lt;/div></description></item><item><title/><link>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/concurrency-tuning/ssf_concurrency_troubleshooting/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/concurrency-tuning/ssf_concurrency_troubleshooting/</guid><description>&lt;h2 id="concurrency-troubleshooting">Concurrency Troubleshooting&lt;/h2>
&lt;p>Hitting up against quota limits may indicate that quota adjustments are required. Exceeding quota limits may cause a Snowflake query to fail or reduce performance. In the worst case, significant throttling can impact the performance of all your API Gateway or Lambda services in the region.&lt;/p>
&lt;p>Snowflake is tolerant of a certain ratio of failed requests and automatically retries. If a high percentage of requests fail, then the query may abort and the last error code will display in the console. For example, 429 Too Many Requests.&lt;/p></description></item><item><title/><link>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/concurrency-tuning/ssf_lambda_tuning/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/concurrency-tuning/ssf_lambda_tuning/</guid><description>&lt;h2 id="lambda-tuning">Lambda Tuning&lt;/h2>
&lt;p>AWS maintains quotas for Lambda concurrent execution. Two of these quotas impact concurrency and compete with other Lambdas in the same account and region:&lt;/p>
&lt;p>&lt;img src="https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/snowflake/performance/concurrency-tuning/ssf_lambda_tuning.png" alt="" title="Lambda Quotas">&lt;/p>
&lt;p>The &lt;strong>concurrent executions&lt;/strong> quota cap is the maximum number of Lambda instances that can serve requests for an account and region. The default AWS quota may be inadequate based on peak concurrency based on the table in the previous section. This quota can be increased with an AWS support ticket.&lt;/p></description></item></channel></rss>