Examkin

Question

Difficulty: HardMessage-Based Integration using Amazon SQS and SNS

A developer is building a high-throughput backend microservice that processes sensor telemetry events from an Amazon SQS queue. The microservice is written in Java and runs on Amazon ECS. During performance testing under high load, the developer notices high network latency, CPU spikes on the ECS container, and elevated AWS billing charges due to a large number of empty SQS `ReceiveMessage` API calls. Additionally, the application's polling loop exhausts local ephemeral port resources.

Which two actions should the developer take to optimize the SDK client and reduce cost and resource utilization? (Choose two.)

  1. Configure the SQS client as a static or singleton instance within the application to enable HTTP connection pooling and reuse TCP connections.Answer
  2. Set the `WaitTimeSeconds` parameter to 2020 seconds during the `ReceiveMessage` API call to enable long polling.Answer
  3. C
    Hardcode the AWS IAM access keys in the SQS client builder configuration to bypass the default credential provider chain lookup latency.
  4. D
    Set the SQS queue's visibility timeout to 00 seconds to ensure that messages are immediately available for other ECS tasks to process if a task fails.
  5. E
    Enable AWS X-Ray active tracing on the ECS task definition, but do not instrument the SQS client within the Java application code.

Answer

The developer should configure the SQS client as a static or singleton instance to enable connection pooling and reuse TCP connections, and set the WaitTimeSeconds parameter to 2020 seconds during ReceiveMessage calls to enable long polling.
Configuring the SQS client as a static or singleton instance ensures that the underlying HTTP client reuses TCP connections via keep-alive, resolving ephemeral port exhaustion. Setting the WaitTimeSeconds parameter to 2020 seconds enables SQS Long Polling, which instructs Amazon SQS to wait until messages are available in the queue before responding, thereby eliminating empty responses, lowering API costs, and reducing container CPU usage.

Step-by-Step Solution

1
Analyze the SDK client initialization lifecycle in the message polling loop.
Reusing a single static/singleton client instance allows the HTTP client to maintain a connection pool, saving TCP/TLS handshake overhead and preventing local ephemeral port exhaustion.
Creating a new client instance per loop iteration spawns new HTTP connection pools, leading to a high rate of socket creation and port exhaustion.
2
Analyze the polling frequency and API call pattern.
Configuring SQS Long Polling by setting WaitTimeSeconds to a value up to 2020 seconds allows the SQS service to wait until a message becomes available before returning a response.
Long polling significantly reduces the number of empty ReceiveMessage responses, reducing API call count, CPU overhead, and SQS processing costs.

Key Concept

Optimizing SQS polling and AWS SDK client lifecycles for high-throughput and cost efficiency.
Rate this question

Topics

Message-Based Integration using Amazon SQS and SNS

More questions from this topic