When to Increase Message Packs

You might need to increase message packs in the following situations:

Situation Reason to increase Example

Situation	Reason to increase	Example
You're consuming more messages than you subscribe to.	Your message packs should equate to the number of messages your Oracle Integration instance consumes per hour. Therefore, it's essential that you know your instance's hourly throughput, and increase your message packs as necessary to match the throughput.	You have 2 message packs, giving you 10,000 messages per hour, which covers your average throughput. Your requests usually take about 5 seconds to complete, so you process 12 requests per minute: `60 seconds per minute / 5 seconds per request = 12 requests per minute` You average 10 concurrent synchronous requests, so now you're up to 120 concurrent requests per minute: `12 requests per minute x concurrency of 10 = 120 concurrent requests per minute` That means you generally process 7,200 requests per hour: `120 concurrent requests per minute x 60 minutes = 7,200 requests per hour` We'll say that each request consumes one message, so you normally consume 7,200 messages per hour, which falls under your message pack subscription. But sometimes you get a 10-minute burst of 100 concurrent synchronous requests. You're suddenly processing 10 times as many requests—1,200 requests per minute, for a total of 12,000 requests during the burst. When you add that to your average messages for the rest of the hour, you've consumed 18,000 messages: `50 average minutes x 120 requests per minute = 6,000 requests` `6,000 requests + 12,000 request burst = 18,000 requests` That puts you 8,000 messages over your message pack subscription: `10,000 subscribed messages - 18,000 consumed messages = 8,000 message overage` You would need to subscribe to 2 more message packs to handle your request bursts.
You need to handle bursts of high concurrency.	The number of message packs directly affects the concurrent synchronous (and asynchronous) request limit.	You have 2 message packs, allowing you up to 200 concurrent synchronous requests. You average a concurrency of 25, so you're usually well within that limit. But sometimes you get a burst of 250 concurrent synchronous requests. Since that exceeds your limit, the extra requests get errors. You would need to subscribe to 1 more message pack to handle your request bursts.

You're consuming more messages than you subscribe to.

Your message packs should equate to the number of messages your Oracle Integration instance consumes per hour. Therefore, it's essential that you know your instance's hourly throughput, and increase your message packs as necessary to match the throughput.

You have 2 message packs, giving you 10,000 messages per hour, which covers your average throughput.

Your requests usually take about 5 seconds to complete, so you process 12 requests per minute:

60 seconds per minute / 5 seconds per request = 12 requests per minute

You average 10 concurrent synchronous requests, so now you're up to 120 concurrent requests per minute:

12 requests per minute x concurrency of 10 = 120 concurrent requests per minute

That means you generally process 7,200 requests per hour:

120 concurrent requests per minute x 60 minutes = 7,200 requests per hour

We'll say that each request consumes one message, so you normally consume 7,200 messages per hour, which falls under your message pack subscription.

But sometimes you get a 10-minute burst of 100 concurrent synchronous requests. You're suddenly processing 10 times as many requests—1,200 requests per minute, for a total of 12,000 requests during the burst.

When you add that to your average messages for the rest of the hour, you've consumed 18,000 messages:

50 average minutes x 120 requests per minute = 6,000 requests
6,000 requests + 12,000 request burst = 18,000 requests

That puts you 8,000 messages over your message pack subscription:

10,000 subscribed messages - 18,000 consumed messages = 8,000 message overage

You would need to subscribe to 2 more message packs to handle your request bursts.

You need to handle bursts of high concurrency.

The number of message packs directly affects the concurrent synchronous (and asynchronous) request limit.

You have 2 message packs, allowing you up to 200 concurrent synchronous requests. You average a concurrency of 25, so you're usually well within that limit.

But sometimes you get a burst of 250 concurrent synchronous requests. Since that exceeds your limit, the extra requests get errors.

You would need to subscribe to 1 more message pack to handle your request bursts.