All Collections
Best Practices
How RTT affects your Usage charges
How RTT affects your Usage charges

Tips to get the most out of your Plus Plan

John Harley avatar
Written by John Harley
Updated over a week ago

RTT Refresher

RTT is brainCloud's Real-Time Tech sub-system, and it enables features like real-time events, chat, messaging, online matchmaking, lobbies, and more.

RTT expands upon the brainCloud request+response architecture by adding a live bi-directional communications channel between the client and server portions of your app. This means that your service can push events to your client apps in real-time, without polling, enabling more exciting experiences.

As you would expect, supporting these capabilities in your app incurs some infrastructure costs - but as always, we have worked very hard to keep the costs to you very low and elastic.

  1. RTT is completely optional. Apps that don't use it can avoid costs by subscribing to any of the Basic plans.

  2. Pricing for apps using RTT is proportional to # of concurrent RTT connections (they use server resources) and the amount of traffic sent over those connections. Makes sense, right?

Enabling RTT

You gain access to RTT features for your app by subscribing to any Plus plan and enabling RTT on the Design | Core App Info | Advanced Settings page. 

Usage rates will be based on peak concurrent RTT connections per hour, Event Delivery and Hosting Relay Servers and Room Servers. Details below.

Concurrent RTT connections and Usage Rates

brainCloud RTT features require a nailed-up TCP or WebSocket connection for each client device. The costs to brainCloud are in maintaining connections (CCx) from our servers, and delivering the millions of real-time events to your users as they participate in chat, messaging, lobbies, etc. To account for this utilization, we convert these resources to API counts.

Each of the RTT plans come with a number of complimentary Concurrent Connections (CCx) that are free per hour

As an example, the Standard Plus plan includes 100 CCx. That means that a peak of 100 Users can be concurrently online without reaching your complimentary CCx usage limit. If RTT is enabled for the full time that users are in your app and your average play session is 12 minutes, that equates to about ~500 users per hour (12K users per day). 

Protip: If you optimize your app to initialize RTT when you need it and disconnect when you don't, 100 CCx could equate to thousands of users per hour. 

For example, RTT might not be needed while your user is: 

  • Browsing in-app-purchase offers

  • Managing his town in a single player context

  • Playing single player challenge missions

  • Upgrading units or cards

  • Reconfiguring his deck or army

  • etc...

How Usage Works Past Your Complimentary Cap

Once your app exceeds your plan's CCx cap, the app is charged at a rate of 10 API calls per CCx per hour.

Example Usage:
Lets say your app on the Standard Plus plan was averaging double the CCx cap: 200 CCx. The additional costs would be:
100 x 10 API/CCx x 24 hours x 30 days = 720,000 API counts.
At ~ $10 / M API, that’s about $7.20 in usage.

One-to-many Event Delivery

The other component of RTT Usage is event delivery. RTT is great for chat and lobby operations – where one operation may fan out to dozens (or thousands) of recipients. That’s great functionality wise – but those deliveries can really add up!

The good news is that RTT is very efficient at delivering events – so we are charging at a bulk ratio of 100:1 – that is, your app is charged just 1 API count for each 100 events delivered!

Example: Clan Chat Usage Costs

We will use as our example an RTT-enabled app that recently launched on brainCloud. It is averaging about 35K daily active users, and 1.75M API calls per day (~50 API/DAU).

The devs have integrated in group-based Chat and Messaging. Our stats are showing that the app is averaging about 500 concurrent RTT connections (CCx's), and that users are sending about 10,000 messages (chat + messaging) a day. This equates to about 1 message per 75 minutes that a user spends in the game. This seems like it's very little, but chat isn't the primary function of the app, and people spend much more time reading chat than posting to it.

Groups in the app can have up to 50 users - but far less than 10% of users would be online at any time. For discussion purposes, we'll assume that each message sent gets received by 5 users. [That's probably way high, especially considering that this app's traffic is split between chat and messaging - which is point-to-point.]

Anyway, let's do the basic calculations: 

  • RTT Deliveries = 10,000 x 5 recipients x 30 days = 1,500,000

  • RTT CCx = (500 - 100 free sessions) x 24 hours x 30 days = 288,000

So how many API counts does this add to the app?  As you will recall, each additional CCx is 10 API calls, but deliveries are very inexpensive at 100 delivers per 1 API count:

  • RTT Deliveries API Counts = 1,500,000 / 100 = 15,000 API

  • RTT CCx API Counts = 288,000 x 10 = 2,880,000 API

Which totals out at of 2,895,000 API calls - which at ~$10 / M = $29.00 of RTT Usage.

Key Takeaways

As you can see, RTT costs are greatly affected by how you implement your app. Be smart about when and how you use RTT to lower system impact and reduce your costs!

Tips for keeping RTT costs low:

  • Enable / disable RTT as appropriate in your app to keep the concurrent connection charges low. To minimize costs, don't have it enabled in parts of your app where real-time events can't be viewed, acted upon, etc.

  • Bulk delivery charges are a bit of a wild card -- their cost is directly related to the # of recipients of each event. Chat, and especially global chat channels, are the most expensive features for bulk charges. 

Tips for reducing Chat traffic:

  • Segment your traffic across multiple channels if you can - by topic, region, language, etc. Traffic in smaller, focused channels costs less - and is more engaging for the users to boot!

  • Connect / disconnect from channels dynamically. The brainCloud API is fast - use it! Avoid connecting simultaneously to a bunch of channels when only one can be viewed at a time!

Did this answer your question?