You are helping the QA team to roll out a new load-testing tool to test the scalability of your primary cloud services that run on Google Compute Engine with Cloud Bigtable. Which three requirements…

Question

Options

• AEnsure that the load tests validate the performance of Cloud Bigtable.
• BCreate a separate Google Cloud project to use for the load-testing environment.
• CSchedule the load-testing tool to regularly run against the production environment.
• DEnsure all third-party systems your services use are capable of handling high load.
• EInstrument the production services to record every transaction for replay by the load-testing tool.
• FInstrument the load-testing tool and the target services with detailed logging and metrics

• A
  52% (29)
• C
  29% (16)
• D
  13% (7)
• E
  7% (4)

Explanation

A (Correct answer) - Ensure that the load tests validate the performance of Cloud Bigtable. At first thought, it seems Bigtable is managed service seamlessly scaling, there is no need to load test it. But you probably already know, there are many factors impacting the Bigtable performance. The common one of them, poorly designed table structure. With poorly performed BigTable, the cluster would continue to scale, add more and more nodes, as the load increasing, cost more and more. Not matter how good is the cluster managed, this is exact situation that needs to prevent. In fact, tests validate the performance of Cloud Bigtable is one of the most important testing goals for BigTable performance. B (Correct answer) - Create a separate Google Cloud project to use for the load-testing This is a good practice for least privileges and separation of responsibilities. C - Schedule the load-testing tool to regularly run against the production environment. You should not do load testing RGULARLY against production environment; In fact, somebody has suggested Load test in production should avoid entirely. D - Ensure all third-party systems your services used are capable of handling high load This is out of scope - it's beyond your control. You may test them, but you cannot control them. If you have doubts the third-party dependencies causing the overall performance issue, you may use integration test to identify and isolate them. This should not be your focus. E - Instrument the production services to record every transaction for replay by the load-testing This would be way too much: not only the detailed instrumentation may impact the production performance, it's also possible the instrumentation itself distorts the test results - remember, Bigtable is for multiple terabyte or even petabyte NoSQL database for high throughput with low latency read and write. F (Correct answer) - Instrument the load-testing tool and the target services with detailed logging and metrics collection. This is normal requirement and practice for load testing to collect testing results with detailed measurable metric and historical logs otherwise load testing would be meaningless Understanding Cloud Bigtable Performance https://cloud.google.com/bigtable/docs/performance

No community discussion yet for this question.