Freshness pass

Author: HeidiSteen

articles/search/search-howto-complex-data-types.md

@@ -10,7 +10,7 @@ tags: complex data types; compound data types; aggregate data types
 ms.custom: ignite-2022
 ms.service: cognitive-search
 ms.topic: how-to
-ms.date: 11/17/2021
+ms.date: 01/30/2023
 ---
 
 # Model complex data types in Azure Cognitive Search
@@ -23,7 +23,7 @@ Azure Cognitive Search natively supports complex types and collections. These ty
 
 To get started, we recommend the [Hotels data set](https://github.com/Azure-Samples/azure-search-sample-data/tree/master/hotels), which you can load in the **Import data** wizard in the Azure portal. The wizard detects complex types in the source and suggests an index schema based on the detected structures.
 
-> [!Note]
+> [!NOTE]
 > Support for complex types became generally available starting in `api-version=2019-05-06`. 
 >
 > If your search solution is built on earlier workarounds of flattened datasets in a collection, you should change your index to include complex types as supported in the newest API version. For more information about upgrading API versions, see [Upgrade to the newest REST API version](search-api-migration.md) or [Upgrade to the newest .NET SDK version](/previous-versions/azure/search/search-dotnet-sdk-migration-version-9).

articles/search/search-howto-move-across-regions.md

@@ -9,7 +9,7 @@ ms.author: heidist
 ms.service: cognitive-search
 ms.topic: how-to
 ms.custom: subject-moving-resources
-ms.date: 10/06/2021
+ms.date: 01/30/2023
 ---
 
 # Move your Azure Cognitive Search service to another Azure region

articles/search/search-performance-analysis.md

@@ -7,7 +7,7 @@ author: LiamCavanagh
 ms.author: liamca
 ms.service: cognitive-search
 ms.topic: conceptual
-ms.date: 04/06/2021
+ms.date: 01/30/2023
 ---
 
 # Analyze performance in Azure Cognitive Search
@@ -16,7 +16,7 @@ This article describes the tools, behaviors, and approaches for analyzing query
 
 ## Develop baseline numbers
 
-In any large implementation, it is critical to do a performance benchmarking test of your Cognitive Search service before you roll it into production. You should test both the search query load that you expect, but also the expected data ingestion workloads (if possible, run these simultaneously). Having benchmark numbers helps to validate the proper [search tier](search-sku-tier.md), [service configuration](search-capacity-planning.md), and expected [query latency](search-performance-analysis.md#average-query-latency).
+In any large implementation, it's critical to do a performance benchmarking test of your Cognitive Search service before you roll it into production. You should test both the search query load that you expect, but also the expected data ingestion workloads (if possible, run both workloads simultaneously). Having benchmark numbers helps to validate the proper [search tier](search-sku-tier.md), [service configuration](search-capacity-planning.md), and expected [query latency](search-performance-analysis.md#average-query-latency).
 
 To develop benchmarks, we recommend the [azure-search-performance-testing (GitHub)](https://github.com/Azure-Samples/azure-search-performance-testing) tool.
 
@@ -28,27 +28,27 @@ To isolate the effects of a distributed service architecture, try testing on ser
 
 ## Use resource logging
 
-The most important tool that an administrator has in diagnosing potential performance issues is [diagnostics logging](monitor-azure-cognitive-search.md) that collects operational data and metrics about your search service. Resource logging is enabled through [Azure Monitor](../azure-monitor/overview.md). There are costs associated with using Azure Monitor and storing data, but if you enable it for your service, it can be instrumental in investigating performance issues.
+The most important diagnostic tool at an administrator's disposal is [resource logging](monitor-azure-cognitive-search.md). Resource logging is the collection of operational data and metrics about your search service. Resource logging is enabled through [Azure Monitor](../azure-monitor/overview.md). There are costs associated with using Azure Monitor and storing data, but if you enable it for your service, it can be instrumental in investigating performance issues.
 
-There are multiple opportunities for latency to occur, whether during a network transfer, or during processing of content in the app services layer, or on a search service. A key benefit of resource logging is that activities are logged from the search service perspective, which means that the log can help you determine whether performance issues are due to problems with the query or indexing, or some other point of failure.
+The following image shows the chain of events in a query request and response. Latency can occur at any one of them, whether during a network transfer, processing of content in the app services layer, or on a search service. A key benefit of resource logging is that activities are logged from the search service perspective, which means that the log can help you determine if the performance issue is due to problems with the query or indexing, or some other point of failure.
 
 :::image type="content" source="media/search-performance/perf-log-event-chain.png" alt-text="Chain of logged events" border="true":::
 
-Diagnostics logging gives you options for storing logged information. We recommend using [Log Analytics](../azure-monitor/logs/log-analytics-overview.md) so that you can execute advanced Kusto queries against the data to answer many questions about usage and performance. 
+Resource logging gives you options for storing logged information. We recommend using [Log Analytics](../azure-monitor/logs/log-analytics-overview.md) so that you can execute advanced Kusto queries against the data to answer many questions about usage and performance. 
 
 On your search service portal pages, you can enable logging through **Diagnostic settings**, and then issue Kusto queries against Log Analytics by choosing **Logs**. For more information about setting up, see [Collect and analyze log data](monitor-azure-cognitive-search.md).
 
 :::image type="content" source="media/search-performance/perf-log-menu-options.png" alt-text="Logging menu options" border="true":::
 
 ## Throttling behaviors
 
-Throttling occurs when the search service has reached the limit of what it can handle from a resource perspective. Throttling can occur during queries or indexing. From the client side, an API call results in a 503 HTTP response when it has been throttled. During indexing, there is also the possibility of receiving a 207 HTTP response, which indicates that one or more items failed to index. This error is an indicator that the search service is getting close to capacity. 
+Throttling occurs when the search service is at capacity. Throttling can occur during queries or indexing. From the client side, an API call results in a 503 HTTP response when it has been throttled. During indexing, there's also the possibility of receiving a 207 HTTP response, which indicates that one or more items failed to index. This error is an indicator that the search service is getting close to capacity. 
 
-As a rule of thumb, it is best to quantify the amount of throttling that you see. For example, if one search query out of 500,000 is throttled, it might not be that large of an issue. However, if a large percentage of queries is throttled over a period, this would be a greater concern. By looking at throttling over a period, it also helps to identify time frames where throttling might more likely occur and help you decide how to best accommodate that.
+As a rule of thumb, try to quantify the amount of throttling and any patterns. For example, if one search query out of 500,000 is throttled, it might not be worth investigating. However, if a large percentage of queries is throttled over a period, this would be a greater concern. By looking at throttling over a period, it also helps to identify time frames where throttling might more likely occur and help you decide how to best accommodate that.
 
-A simple fix to most throttling issues is to throw more resources at the search service (typically replicas for query-based throttling, or partitions for indexing-based throttling). However, increasing replicas or partitions adds cost, which is why it is important to know the reason why throttling is occurring at all. Investigating the conditions that cause throttling will be explained in the next several sections. 
+A simple fix to most throttling issues is to throw more resources at the search service (typically replicas for query-based throttling, or partitions for indexing-based throttling). However, increasing replicas or partitions adds cost, which is why it's important to know the reason why throttling is occurring at all. Investigating the conditions that cause throttling will be explained in the next several sections. 
 
-Below is an example of a Kusto query that can identify the breakdown of HTTP responses from the search service that has been under load. By querying over a 7-day period, the rendered bar chart shows that a relatively large percentage of the search queries were throttled, in comparison to the number of successful (200) responses.
+Below is an example of a Kusto query that can identify the breakdown of HTTP responses from the search service that has been under load. Over a 7-day period, the rendered bar chart shows that a relatively large percentage of the search queries were throttled, in comparison to the number of successful (200) responses.
 
 ```kusto
 AzureDiagnostics
@@ -78,9 +78,9 @@ AzureDiagnostics
 
 ## Measure individual queries
 
-In some cases, it can be useful to test individual queries to see how they are performing. To do this, it is important to be able to see how long the search service takes to complete the work, as well as how long it takes to make the round-trip request from the client and back to the client. The diagnostics logs could be used to look up individual operations, but it might be easier to do this all from a client tool, such as Postman.
+In some cases, it can be useful to test individual queries to see how they're performing. To do this, it's important to be able to see how long the search service takes to complete the work, as well as how long it takes to make the round-trip request from the client and back to the client. The diagnostics logs could be used to look up individual operations, but it might be easier to do this all from a client tool, such as Postman.
 
-In the example below, a REST-based search query was executed. Cognitive Search includes in every response the number of milliseconds it takes to complete the query, visible in the Headers tab, in "elapsed-time". Next to Status at the top of the response, you'll find the round-trip duration. in this case, 418 milliseconds. In the results section, the “Headers” tab was chosen. Using these two values highlighted with a Red box in the image below, we see the search service took 21 ms to complete the search query and the entire client round-trip request took 125 ms. By subtracting these two numbers we can determine that it took 104 ms additional time to transmit the search query to the search service and to transfer the search results back to the client.
+In the example below, a REST-based search query was executed. Cognitive Search includes in every response the number of milliseconds it takes to complete the query, visible in the Headers tab, in "elapsed-time". Next to Status at the top of the response, you'll find the round-trip duration. in this case, 418 milliseconds. In the results section, the “Headers” tab was chosen. Using these two values highlighted with a Red box in the image below, we see the search service took 21 ms to complete the search query and the entire client round-trip request took 125 ms. By subtracting these two numbers we can determine that it took 104-ms additional time to transmit the search query to the search service and to transfer the search results back to the client.
 
 This can be extremely helpful to determine if there might be network latencies or other factors impacting query performance.
 
@@ -109,7 +109,7 @@ AzureDiagnostics
 
 ## Impact of indexing on queries
 
-An important factor to consider when looking at performance is that indexing uses the same resources as search queries. If you are indexing a large amount of content, you can expect to see latency grow as the service tries to accommodate both workloads.
+An important factor to consider when looking at performance is that indexing uses the same resources as search queries. If you're indexing a large amount of content, you can expect to see latency grow as the service tries to accommodate both workloads.
 
 If queries are slowing down, look at the timing of indexing activity to see if it coincides with query degradation. For example, perhaps an indexer is running a daily or hourly job that correlates with the decreased performance of the search queries. 
 
@@ -121,7 +121,7 @@ This section provides a set of queries that can help you visualize the search an
 
 ### Average Query Latency
 
-In the below query, an interval size of 1 minute is used to show the average latency of the search queries. From the chart we can see that the average latency was low until 5:45pm and lasted until 5:53pm.
+In the below query, an interval size of 1 minute is used to show the average latency of the search queries. From the chart, we can see that the average latency was low until 5:45pm and lasted until 5:53pm.
 
 ```kusto
 let intervalsize = 1m; 
@@ -138,7 +138,7 @@ AzureDiagnostics
 
 ### Average Queries Per Minute (QPM)
 
-The following query allows us to look at the average number of queries per minute to ensure that there was not some sort of spike in search requests that might have impacted the latency. From the chart we can see there is some variance, but nothing to indicate a spike in request count.
+The following query looks at the average number of queries per minute to ensure that there wasn't a spike in search requests that might have affected the latency. From the chart, we can see there's some variance, but nothing to indicate a spike in request count.
 
 ```kusto
 let intervalsize = 1m; 
@@ -155,9 +155,9 @@ AzureDiagnostics
 
 ### Indexing Operations Per Minute (OPM)
 
-Here we will look at the number of Indexing operations per minute. From the chart we can see that a large amount of data was indexed started at 5:42 pm and ended at 5:50pm. This indexing began 3 minutes before the search queries started becoming latent and ended 3 minutes before the search queries were no longer latent.
+Here we'll look at the number of Indexing operations per minute. From the chart, we can see that a large amount of data was indexed started at 5:42 pm and ended at 5:50pm. This indexing began 3 minutes before the search queries started becoming latent and ended 3 minutes before the search queries were no longer latent.
 
-From this we can see that it took about 3 minutes for the search service to be busy enough from the indexing to start impact the search query latency. We can also see that after the indexing completed it took another 3 minutes for the search service to complete all the work from the newly indexed content, until the search queries starting to no longer be latent.
+From this insight, we can see that it took about 3 minutes for the search service to become busy enough for indexing to affect query latency. We can also see that after indexing completed, it took another 3 minutes for the search service to complete all the work from the newly indexed content, and for query latency to resolve.
 
 ```kusto
 let intervalsize = 1m; 
@@ -174,13 +174,13 @@ AzureDiagnostics
 
 ## Background service processing
 
-It is not unusual to see periodic spikes in query or indexing latency. Spikes might occur in response to indexing or high query rates, but could also occur during merge operations. Search indexes are stored in chunks - or shards. Periodically, the system merges smaller shards into large shards, which can help optimize service performance. This merge process also cleans up documents that have previously been marked for deletion from the index, resulting in the recovery of storage space. 
+It isn't unusual to see periodic spikes in query or indexing latency. Spikes might occur in response to indexing or high query rates, but could also occur during merge operations. Search indexes are stored in chunks - or shards. Periodically, the system merges smaller shards into large shards, which can help optimize service performance. This merge process also cleans up documents that have previously been marked for deletion from the index, resulting in the recovery of storage space. 
 
-Merging shards is fast, but also resource intensive and thus has the potential to degrade service performance. For this reason, if you see short bursts of query latency, and those bursts coincide with recent changes to indexed content, it's likely that you attribute that latency to shard merge operations. 
+Merging shards is fast, but also resource intensive and thus has the potential to degrade service performance. If you notice short bursts of query latency, and those bursts coincide with recent changes to indexed content, you can assume the latency is due to shard merge operations. 
 
 ## Next steps
 
-Review these additional articles related to analyzing service performance.
+Review these articles related to analyzing service performance.
 
 + [Performance tips](search-performance-tips.md)
 + [Choose a service tier](search-sku-tier.md)