|
| 1 | +--- |
| 2 | +title: Reinforcement Learning - Personalizer |
| 3 | +titleSuffix: Azure Cognitive Services |
| 4 | +description: Personalizer uses information about actions and current context to make better ranking suggestions. The information about these actions and context are attributes or properties that are referred to as features. |
| 5 | +services: cognitive-services |
| 6 | +author: edjez |
| 7 | +manager: nitinme |
| 8 | +ms.service: cognitive-services |
| 9 | +ms.subservice: personalizer |
| 10 | +ms.topic: overview |
| 11 | +ms.date: 05/07/2019 |
| 12 | +ms.author: edjez |
| 13 | +--- |
| 14 | +# Scalability and Performance |
| 15 | + |
| 16 | +Personalizer is used in many high-performance and high-traffic websites and applications. |
| 17 | +When evaluating Personalizer for use in these situations, there are two main factors to consider: |
| 18 | + |
| 19 | +1. Keeping low latency when making Rank API calls |
| 20 | +1. Making sure training throughput keeps up with event input |
| 21 | + |
| 22 | +## Performance & Latency |
| 23 | + |
| 24 | +Personalization can return a rank very rapidly, with most of the call duration dedicated to communication through the REST API. Azure will auto-scale the ability to respond to requests rapidly. |
| 25 | + |
| 26 | + |
| 27 | +### Low-latency Scenarios |
| 28 | + |
| 29 | +Some applications require low latencies when returning a rank. This is necessary to keep the user from 'waiting' a noticeable amount of time; or keep a server experiencing extreme traffic from tying up compute time and network connections. |
| 30 | + |
| 31 | +If your web site is scaled on your infrastructure, you can avoid making http calls by hosting the Personalizer API in your own servers running a Docker container. |
| 32 | + |
| 33 | +This change would be transparent to your application, other than using an endpoint URL referring to the running docker instances as opposed to an online service in the cloud. |
| 34 | + |
| 35 | +### Extreme Low Latency Scenarios |
| 36 | + |
| 37 | +If you require latencies under a millisecond, and have already tested using Personalizer via containers, please contact our support team so we can assess your scenario and provide guidance suited to your needs. |
| 38 | + |
| 39 | + |
| 40 | +## Scalability and Training Throughput |
| 41 | + |
| 42 | +Personalizer works by updating a model that is re-trained based on messages sent asynchronously by Personalizer after Rank and Reward APIs. These messages are sent using an Azure EventHub for the application. |
| 43 | + |
| 44 | + It is unlikely most applications will reach the maximum joining and training throughput of Personalizer. |
| 45 | + While reaching this maximum will not slow down the application, it would imply Event Hub queues are getting filled internally faster than they can be cleaned up. |
| 46 | + |
| 47 | +How to estimate your throughput requirements |
| 48 | + |
| 49 | +* Estimate what is the average number of bytes per ranking events (adding the lengths of the context and action JSON documents) |
| 50 | +* Divide 20MB/sec by this number. |
| 51 | + |
| 52 | +For example, if your average payload has 500 features and each is an estimated 20 characters, then each event is approximately 10kb. With these estimates, 20,000,000 / 10,000 = 2,000 events/sec, which is about 173 million events/day. |
| 53 | + |
| 54 | +If you are reaching these limits please contact our support team for architecture advice. |
| 55 | + |
| 56 | +# More Information |
0 commit comments