|
1 | 1 | ---
|
2 | 2 | title: Reinforcement Learning - Personalizer
|
3 | 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. |
| 4 | +description: "High-performance and high-traffic websites and applications have two main factors to consider with Personalizer for scalability and performance: latency and training throughput." |
5 | 5 | services: cognitive-services
|
6 | 6 | author: edjez
|
7 | 7 | manager: nitinme
|
8 | 8 | ms.service: cognitive-services
|
9 | 9 | ms.subservice: personalizer
|
10 | 10 | ms.topic: overview
|
11 |
| -ms.date: 05/07/2019 |
| 11 | +ms.date: 06/07/2019 |
12 | 12 | ms.author: edjez
|
13 | 13 | ---
|
14 | 14 | # Scalability and Performance
|
15 | 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: |
| 16 | +High-performance and high-traffic websites and applications have two main factors to consider with Personalizer for scalability and performance: |
18 | 17 |
|
19 | 18 | 1. Keeping low latency when making Rank API calls
|
20 | 19 | 1. Making sure training throughput keeps up with event input
|
21 | 20 |
|
22 |
| -## Performance & Latency |
| 21 | +Personalization can return a rank very rapidly, with most of the call duration dedicated to communication through the REST API. Azure will autoscale the ability to respond to requests rapidly. |
23 | 22 |
|
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. |
| 23 | +## Low-latency scenarios |
25 | 24 |
|
| 25 | +Some applications require low latencies when returning a rank. This is necessary: |
26 | 26 |
|
27 |
| -### Low-latency Scenarios |
| 27 | +* To keep the user from waiting a noticeable amount of time before displaying ranked content. |
| 28 | +* To keep a server from experiencing extreme traffic by _not_ tying up compute time and network connections. |
28 | 29 |
|
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 | +<!-- |
30 | 31 |
|
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 | +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 |
|
33 | 34 | 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 |
|
| 36 | +
|
| 37 | +
|
35 | 38 | ### Extreme Low Latency Scenarios
|
36 | 39 |
|
37 | 40 | 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 | 41 |
|
| 42 | +--> |
39 | 43 |
|
40 |
| -## Scalability and Training Throughput |
| 44 | +## Scalability and training throughput |
41 | 45 |
|
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. |
| 46 | +Personalizer works by updating a model that is retrained based on messages sent asynchronously by Personalizer after Rank and Reward APIs. These messages are sent using an Azure EventHub for the application. |
43 | 47 |
|
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. |
| 48 | + It is unlikely most applications will reach the maximum joining and training throughput of Personalizer. 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 | 49 |
|
47 |
| -How to estimate your throughput requirements |
| 50 | +## How to estimate your throughput requirements |
48 | 51 |
|
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. |
| 52 | +* Estimate the average number of bytes per ranking event adding the lengths of the context and action JSON documents. |
| 53 | +* Divide 20MB/sec by this estimated average bytes. |
51 | 54 |
|
52 | 55 | 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 | 56 |
|
54 |
| -If you are reaching these limits please contact our support team for architecture advice. |
| 57 | +If you are reaching these limits, please contact our support team for architecture advice. |
| 58 | + |
| 59 | +## Next steps |
55 | 60 |
|
56 |
| -# More Information |
| 61 | +[Create and configure Personalizer](how-to-settings.md). |
0 commit comments