Performance onhttps://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/redshift/performance/Recent content in Performance onHugoen<link>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/redshift/performance/srs_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/redshift/performance/srs_concurrency_troubleshooting/</guid><description><h2 id="concurrency-troubleshooting">Concurrency Troubleshooting</h2> <p>Hitting up against quota limits may indicate that quota adjustments are required. Exceeding quota limits may cause a Redshift query to fail or reduce performance. In the worst case, significant throttling can impact the performance of all your Lambda services in the region.</p> <p>Redshift 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, <strong>429 Too Many Requests</strong>.</p></description></item><item><title/><link>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/redshift/performance/srs_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/redshift/performance/srs_lambda_tuning/</guid><description><h2 id="lambda-tuning">Lambda Tuning</h2> <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:</p> <p><img src="https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/redshift/performance/ssf_lambda_tuning.png" alt=""></p> <p>The <strong>Concurrent executions</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.</p></description></item><item><title/><link>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/redshift/performance/srs_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/redshift/performance/srs_sample_benchmarks/</guid><description><h2 id="sample-benchmarks">Sample Benchmarks</h2> <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):</p> <table> <thead> <tr> <th>Rows x Cols</th> <th># Ops</th> <th>dc2.large (24 nodes)</th> <th>ra3.4xl (3 nodes)</th> <th>ra3.4xl (7 nodes)</th> <th>ra3.16xl (7 nodes)</th> </tr> </thead> <tbody> <tr> <td><strong>1M x 6 cols</strong></td> <td>6M</td> <td>1.6</td> <td>1.7</td> <td>1.5</td> <td>1.2</td> </tr> <tr> <td><strong>10M x 6 cols</strong></td> <td>60M</td> <td>6.0</td> <td>6.3</td> <td>2.8</td> <td>3.3</td> </tr> <tr> <td><strong>100M x 6 cols</strong></td> <td>600M</td> <td>44.3</td> <td>49.8</td> <td>23.4</td> <td>15.1</td> </tr> </tbody> </table></description></item><item><title/><link>https://docs.protegrity.com/cloud-protect/4.0.0/docs/aws/redshift/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/redshift/performance/ssf_performance_considerations/</guid><description><h2 id="performance-considerations">Performance Considerations</h2> <p>The following factors may cause variation in real performance versus benchmarks:</p> <ul> <li><strong>Cold startup:</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.</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>Lambda memory:</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.</li> <li><strong>Cluster size:</strong> Cluster size may make a significant difference depending on the workload.</li> <li>Number of security operations (protect or unprotect).</li> <li><strong>Lambda concurrency and burst quotas:</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.</li> <li><strong>Size of data element:</strong> Operations on larger text consume time.</li> </ul></description></item></channel></rss>