Fix blocking issues

cdpark · cdpark · commit 90c80f372664 · 2024-07-25T14:14:40.000-07:00
diff --git a/articles/cosmos-db/cassandra/monitor-insights.md b/articles/cosmos-db/cassandra/monitor-insights.md
@@ -49,26 +49,26 @@ Exceeding provisioned throughput could be one of the reasons. Enable [Server Sid
 
 
 ## System and management operations
-The system view helps show metadata requests count by primary partition. It also helps identify throttled requests. The management operation shows the account activities such as creation, deletion, key, network and replication settings. Request volume per status code over a time period.
+The system view helps show metadata requests count by primary partition. It also helps identify throttled requests. The management operation shows the account activities such as creation, deletion, key, network, and replication settings. Request volume per status code over a time period.
 
 :::image type="content" source="./media/monitor-insights/metadata-requests-status-code.png" alt-text="Screenshot showing request status code based on metadata.":::
 
 - Metric chart for account diagnostic, network and replication settings over a specified period and filtered based on a Keyspace.
 
-:::image type="content" source="./media/monitor-insights/diagnostic-network-replication.png" alt-text="Screenshot of diagnostic network replication for a API for Cassandra account.":::
+:::image type="content" source="./media/monitor-insights/diagnostic-network-replication.png" alt-text="Screenshot of diagnostic network replication for a Cassandra account API.":::
 
 
 - Metric chart to view account key rotation.
 
 You can view changes to primary or secondary password for your API for Cassandra account.
 
-:::image type="content" source="./media/monitor-insights/cosmos-db-account-key.png" alt-text="Screenshot showing Azure Cosmos DB rotation key for a API for Cassandra account.":::
+:::image type="content" source="./media/monitor-insights/cosmos-db-account-key.png" alt-text="Screenshot showing Azure Cosmos DB rotation key for a Cassandra account API.":::
 
 
 ## Storage
 Storage distribution for raw and index storage. Also a count of documents in the API for Cassandra account.
 
-:::image type="content" source="./media/monitor-insights/data-index-usage.png" alt-text="Diagram showing the document count within a API for Cassandra account.":::
+:::image type="content" source="./media/monitor-insights/data-index-usage.png" alt-text="Diagram showing the document count within an API for Cassandra account.":::
 
 Maximum request units consumption for an account over a defined time period.
 
@@ -91,7 +91,7 @@ The chart below shows if your application’s high RU consumption is because of
 
 The chart below shows a breakdown of requests by different status code. Understand the meaning of the different codes for your  [API for Cassandra codes](../monitor-reference.md#error-codes-for-cassandra).
 
-:::image type="content" source="./media/monitor-insights/total-request-by-status-code.png" alt-text="Screenshot image of a graph showing the total request by status code for a cassandra api account.":::
+:::image type="content" source="./media/monitor-insights/total-request-by-status-code.png" alt-text="Screenshot image of a graph showing the total request by status code for a Cassandra API account.":::
 
 
 ## Next steps
diff --git a/articles/cosmos-db/concepts-limits.md b/articles/cosmos-db/concepts-limits.md
@@ -290,9 +290,9 @@ The following table lists the limits specific to MongoDB feature support. Other
 | Maximum execution time for MongoDB operations (for 3.6 and 4.0 server version)| 60 seconds|
 | Maximum level of nesting for embedded objects / arrays on index definitions | 6 |
 | Idle connection timeout for server side connection closure ² | 30 minutes |
-| Time limit for MongoDB shell in the Azure Portal | 120 minutes in a 24hr period |
+| Time limit for MongoDB shell in the Azure portal | 120 minutes in a 24hr period |
 
-¹ Large document sizes up to 16 MB require feature enablement in Azure portal. Read the [feature documentation](../cosmos-db/mongodb/feature-support-42.md#data-types) to learn more.
+¹ Large document sizes up to 16 MB require feature enablement in the Azure portal. Read the [feature documentation](../cosmos-db/mongodb/feature-support-42.md#data-types) to learn more.
 
 ² We recommend that client applications set the idle connection timeout in the driver settings to 2-3 minutes because the [default timeout for Azure LoadBalancer is 4 minutes](../load-balancer/load-balancer-tcp-idle-timeout.md).  This timeout ensures that an intermediate load balancer idle doesn't close connections between the client machine and Azure Cosmos DB.
 
diff --git a/articles/cosmos-db/how-to-choose-offer.md b/articles/cosmos-db/how-to-choose-offer.md
@@ -128,7 +128,7 @@ When using autoscale, use Azure Monitor to see the provisioned autoscale max RU/
 
 The following example shows a variable or unpredictable workload using autoscale. Note when there isn't any traffic, the system scales the RU/s to the minimum of 10% of the max RU/s, which in this case is 5,000 RU/s and 50,000 RU/s, respectively.
 
-:::image type="content" source="media/how-to-choose-offer/autoscale-metrics-azure-monitor.png" alt-text="Example of workload using autoscale, with autoscale max RU/s of 50,000 RU/s and throughput ranging from 5000 - 50,000 RU/s":::
+:::image type="content" source="media/how-to-choose-offer/autoscale-metrics-azure-monitor.png" alt-text="Screenshot of example workload using autoscale, with autoscale max RU/s of 50,000 RU/s and throughput ranging from 5000 - 50,000 RU/s.":::
 
 ## Next steps
 * Use [RU calculator](https://cosmos.azure.com/capacitycalculator/) to estimate throughput for new workloads.
diff --git a/articles/cosmos-db/optimize-cost-throughput.md b/articles/cosmos-db/optimize-cost-throughput.md
@@ -16,7 +16,7 @@ ms.custom: devx-track-csharp
 
 By offering provisioned throughput model, Azure Cosmos DB offers predictable performance at any scale. Reserving or provisioning throughput ahead of time eliminates the “noisy neighbor effect” on your performance. You specify the exact amount of throughput you need and Azure Cosmos DB guarantees the configured throughput, backed by SLA.
 
-You can start with a minimum throughput of 400 RU/sec and scale up to tens of millions of requests per second or even more. Each request you issue against your Azure Cosmos DB container  or database, such as a read request, write request, query request, stored procedures have a corresponding cost that is deducted from your provisioned throughput. If you provision 400 RU/s and issue a query that costs 40 RUs, you can issue 10 such queries per second. Any request beyond that gets rate-limited and you should retry the request. If you're using client drivers, they support the automatic retry logic.
+You can start with a minimum throughput of 400 RU/sec and scale up to tens of millions of requests per second or even more. Each request you issue against your Azure Cosmos DB container  or database, such as a read request, write request, query request, stored procedures have a corresponding cost that is deducted from your provisioned throughput. If you provision 400 RU/s and issue a query that costs 40 RUs, you'll be able to issue 10 such queries per second. Any request beyond that get rate-limited and you should retry the request. If you're using client drivers, they support the automatic retry logic.
 
 You can provision throughput on databases or containers and each strategy can help you save on costs depending on the scenario.
 
@@ -32,7 +32,7 @@ The following are some guidelines to decide on a provisioned throughput strategy
 
 1. You have a few dozen Azure Cosmos DB containers and want to share throughput across some or all of them. 
 
-2. You're migrating from a single-tenant database designed to run on IaaS-hosted VMs or on-premises, for example, NoSQL or relational databases to Azure Cosmos DB. And if you have many collections/tables/graphs and you don't want to make any changes to your data model. Note, you might have to compromise some of the benefits offered by Azure Cosmos DB if you're not updating your data model when migrating from an on-premises database. It's recommended that you always reassess your data model to get the most in terms of performance and also to optimize for costs. 
+2. You're migrating from a single-tenant database designed to run on IaaS-hosted VMs or on-premises, for example, NoSQL or relational databases to Azure Cosmos DB. And if you have many collections/tables/graphs and you don't want to make any changes to your data model. Note, you might have to compromise some of the benefits offered by Azure Cosmos DB if you aren't updating your data model when migrating from an on-premises database. It's recommended that you always reassess your data model to get the most in terms of performance and also to optimize for costs. 
 
 3. You want to absorb unplanned spikes in workloads by virtue of pooled throughput at the database level subjected to unexpected spike in workload. 
 
@@ -88,15 +88,15 @@ connectionPolicy.RetryOptions.MaxRetryWaitTimeInSeconds = 60;
 
 ## Partitioning strategy and provisioned throughput costs
 
-Good partitioning strategy is important to optimize costs in Azure Cosmos DB. Ensure that there's no skew of partitions, which are exposed through storage metrics. Ensure that there's no skew of throughput for a partition, which is exposed with throughput metrics. Ensure that there's no skew towards particular partition keys. Dominant keys in storage are exposed through metrics but the key is dependent on your application access pattern. It's best to think about the right logical partition key. A good partition key is expected to have the following characteristics:
+Good partitioning strategy is important to optimize costs in Azure Cosmos DB. Ensure that there is no skew of partitions, which are exposed through storage metrics. Ensure that there is no skew of throughput for a partition, which is exposed with throughput metrics. Ensure that there's no skew towards particular partition keys. Dominant keys in storage are exposed through metrics but the key is dependent on your application access pattern. It's best to think about the right logical partition key. A good partition key is expected to have the following characteristics:
 
 * Choose a partition key that spreads workload evenly across all partitions and evenly over time. In other words, you shouldn't have some keys to with majority of the data and some keys with less or no data. 
 
 * Choose a partition key that enables access patterns to be evenly spread across logical partitions. The workload is reasonably even across all the keys. In other words, the majority of the workload shouldn't be focused on a few specific keys. 
 
 * Choose a partition key that has a wide range of values. 
 
-The basic idea is to spread the data and the activity in your container across the set of logical partitions, so that resources for data storage and throughput can be distributed across the logical partitions. Candidates for partition keys may include the properties that appear frequently as a filter in your queries. Queries can be efficiently routed by including the partition key in the filter predicate. With such a partitioning strategy, optimizing provisioned throughput is a lot easier. 
+The basic idea is to spread the data and the activity in your container across the set of logical partitions, so that resources for data storage and throughput can be distributed across the logical partitions. Candidates for partition keys might include the properties that appear frequently as a filter in your queries. Queries can be efficiently routed by including the partition key in the filter predicate. With such a partitioning strategy, optimizing provisioned throughput is a lot easier. 
 
 ### Design smaller items for higher throughput 
 
@@ -124,11 +124,11 @@ You can also set alerts to check if the number of rate-limited requests exceeds
 
 Since you're billed for the throughput provisioned, matching the provisioned throughput to your needs can help you avoid the charges for the unused throughput. You can scale your provisioned throughput up or down any time, as needed. If your throughput needs are very predictable you can use Azure Functions and use a Timer Trigger to [increase or decrease throughput on a schedule](scale-on-schedule.md). 
 
-* Monitoring the consumption of your RUs and the ratio of rate-limited requests might reveal that you don't need to keep provisioned throughout constant throughout the day or the week. You may receive less traffic at night or during the weekend. By using either Azure portal or Azure Cosmos DB native SDKs or REST API, you can scale your provisioned throughput at any time. Azure Cosmos DB’s REST API provides endpoints to programmatically update the performance level of your containers making it straightforward to adjust the throughput from your code depending on the time of the day or the day of the week. The operation is performed without any downtime, and typically takes effect in less than a minute. 
+* Monitoring the consumption of your RUs and the ratio of rate-limited requests might reveal that you don't need to keep provisioned throughout constant throughout the day or the week. You might receive less traffic at night or during the weekend. By using either Azure portal or Azure Cosmos DB native SDKs or REST API, you can scale your provisioned throughput at any time. Azure Cosmos DB’s REST API provides endpoints to programmatically update the performance level of your containers making it straightforward to adjust the throughput from your code depending on the time of the day or the day of the week. The operation is performed without any downtime, and typically takes effect in less than a minute. 
 
 * One of the areas you should scale throughput is when you ingest data into Azure Cosmos DB, for example, during data migration. Once you have completed the migration, you can scale provisioned throughput down to handle the solution’s steady state.  
 
-* Remember, the billing is at the granularity of one hour, so you will not save any money if you change your provisioned throughput more often than one hour at a time.
+* Remember, the billing is at the granularity of one hour, so you don't save any money if you change your provisioned throughput more often than one hour at a time.
 
 ## Determine the throughput needed for a new workload 
 
@@ -156,15 +156,15 @@ The following steps help you to make your solutions highly scalable and cost-eff
 
 2. One method for estimating the amount of reserved throughput required by your application is to record the request unit RU charge associated with running typical operations against a representative Azure Cosmos DB container or database used by your application and then estimate the number of operations you anticipate performing each second. Be sure to measure and include typical queries and their usage as well. To learn how to estimate RU costs of queries programmatically or using portal see [Optimizing the cost of queries](./optimize-cost-reads-writes.md). 
 
-3. Another way to get operations and their costs in RUs is by enabling Azure Monitor logs, which gives you the breakdown of operation/duration and the request charge. Azure Cosmos DB provides request charge for every operation, so every operation charge can be stored back from the response and then used for analysis. 
+3. Another way to get operations and their costs in RUs is by enabling Azure Monitor logs, which will give you the breakdown of operation/duration and the request charge. Azure Cosmos DB provides request charge for every operation, so every operation charge can be stored back from the response and then used for analysis. 
 
 4. You can elastically scale up and down provisioned throughput as you need to accommodate your workload needs. 
 
 5. You can add and remove regions associated with your Azure Cosmos DB account as you need and control costs. 
 
-6. Make sure you have even distribution of data and workloads across logical partitions of your containers. If you have uneven partition distribution, this could cause to provision higher amount of throughput than the value that is needed. If you identify that you have a skewed distribution, we recommend redistributing the workload evenly across the partitions or repartition the data. 
+6. Make sure you have even distribution of data and workloads across logical partitions of your containers. If you have uneven partition distribution, this might cause to provision higher amount of throughput than the value that is needed. If you identify that you have a skewed distribution, we recommend redistributing the workload evenly across the partitions or repartition the data. 
 
-7. If you have many containers and these containers don't require SLAs, you can use the database-based offer for the cases where the per container throughput SLAs don't apply. You should identify which of the Azure Cosmos DB containers you want to migrate to the database level throughput offer and then migrate them by using a change feed-based solution. 
+7. If you have many containers and these containers do not require SLAs, you can use the database-based offer for the cases where the per container throughput SLAs don't apply. You should identify which of the Azure Cosmos DB containers you want to migrate to the database level throughput offer and then migrate them by using a change feed-based solution. 
 
 8. Consider using the “Azure Cosmos DB Free Tier” (free for one year), Try Azure Cosmos DB (up to three regions) or downloadable Azure Cosmos DB emulator for dev/test scenarios. By using these options for test-dev, you can substantially lower your costs.  
 
