Merge branch 'main' into release-pp-nsp

Author: v-alje

articles/application-gateway/media/application-gateway-create-probe-portal/figure6.png

@@ -76,7 +76,7 @@ Vector similarity search can be used in multiple applications. Some common use-c
 - **Document Retrieval**. Use the deeper semantic understanding of text provided by LLMs to provide a richer document search experience where traditional keyword-based search falls short. [Document Retrieval Example](https://github.com/RedisVentures/redis-arXiv-search)
 - **Product Recommendation**. Find similar products or services to recommend based on past user activities, like search history or previous purchases. [Product Recommendation Example](https://github.com/RedisVentures/LLM-Recommender)
 - **Visual Search**. Search for products that look similar to a picture taken by a user or a picture of another product. [Visual Search Example](https://github.com/RedisVentures/redis-product-search)
-- **Semantic Caching**. Reduce the cost and latency of LLMs by caching LLM completions. LLM queries are compared using vector similarity. If a new query is similar enough to a previously cached query, the cached query is returned. [Semantic Caching example using LangChain](https://python.langchain.com/docs/integrations/llms/llm_caching#redis-cache)
+- **Semantic Caching**. Reduce the cost and latency of LLMs by caching LLM completions. LLM queries are compared using vector similarity. If a new query is similar enough to a previously cached query, the cached query is returned. [Semantic Caching example using LangChain](https://python.langchain.com/docs/integrations/llm_caching/#redis-cache)
 - **LLM Conversation Memory**. Persist conversation history with an LLM as embeddings in a vector database. Your application can use vector search to pull relevant history or "memories" into the response from the LLM. [LLM Conversation Memory example](https://github.com/continuum-llms/chatgpt-memory)
 
 ## Why choose Azure Cache for Redis for storing and searching vectors?

articles/azure-cache-for-redis/cache-overview-vector-similarity.md

@@ -5,7 +5,7 @@ services: azure-netapp-files
 author: b-ahibbard
 ms.service: azure-netapp-files
 ms.topic: conceptual
-ms.date: 09/05/2024
+ms.date: 10/24/2024
 ms.author: anfdocs
 ---
 # Performance considerations for Azure NetApp Files storage with cool access
@@ -20,6 +20,9 @@ When the default cool access retrieval policy is selected, sequential I/O reads
 
 In a recent test performed using Standard storage with cool access for Azure NetApp Files, the following results were obtained.
 
+>[!NOTE]
+>All results published are for reference purposes only. Results are not guaranteed as performance in production workloads can vary due to numerous factors.
+
 ## 100% sequential reads on hot/cool tier (single job)
 
 In the following scenario, a single job on one D32_V5 virtual machine (VM) was used on a 50-TiB Azure NetApp Files volume using the Ultra performance tier. Different block sizes were used to test performance on hot and cool tiers.
@@ -39,65 +42,27 @@ This graph shows a side-by-side comparison of cool and hot tier performance with
 
 :::image type="content" source="./media/performance-considerations-cool-access/throughput-graph.png" alt-text="Chart of throughput at varying `iodepths` with one job." lightbox="./media/performance-considerations-cool-access/throughput-graph.png":::
 
-## 100% sequential reads on hot/cool tier (multiple jobs)
-
-For this scenario, the test was conducted with 16 job using a 256=KB block size on a single D32_V5 VM on a 50-TiB Azure NetApp Files volume using the Ultra performance tier. 
-
->[!NOTE]
->The maximum for the Ultra service level is 128 MiB/s per tebibyte of allocated capacity. An Azure NetApp Files regular volume can manage a throughput of up to approximately 5,000 MiB/s.
-
-It's possible to push for more throughput for the hot and cool tiers using a single VM when running multiple jobs. The performance difference between hot and cool tiers is less drastic when running multiple jobs. The following graph displays results for hot and cool tiers when running 16 jobs with 16 threads at a 256-KB block size. 
-
-:::image type="content" source="./media/performance-considerations-cool-access/throughput-sixteen-jobs.png" alt-text="Chart of throughput at varying `iodepths` with 16 jobs." lightbox="./media/performance-considerations-cool-access/throughput-sixteen-jobs.png":::
-
-- Throughput improved by nearly three times for the hot tier.
-- Throughput improved by 6.5 times for the cool tier.
-- The performance difference for the hot and cool tier decreased from 2.9x to just 1.3x.
-
-## Maximum viable job scale for cool tier – 100% sequential reads
-
-The cool tier has a limit of how many jobs can be pushed to a single Azure NetApp Files volume before latency starts to spike to levels that are generally unusable for most workloads.
-
-In the case of cool tiering, that limit is around 16 jobs with a queue depth of no more than 15. The following graph shows that latency spikes from approximately 23 milliseconds (ms) with 16 jobs/15 queue depth with slightly less throughput than with a queue depth of 14. Latency spikes as high as about 63 ms when pushing 32 jobs and throughput drops by roughly 14%.
-
-:::image type="content" source="./media/performance-considerations-cool-access/sixteen-jobs-line-graph.png" alt-text="Chart of throughput and latency for tests with 16 jobs." lightbox="./media/performance-considerations-cool-access/sixteen-jobs-line-graph.png":::
-
 ## What causes latency in hot and cool tiers?
 
 Latency in the hot tier is a factor of the storage system itself, where system resources are exhausted when more I/O is sent to the service than can be handled at any given time. As a result, operations need to queue until previously sent operations can be complete.
 
 Latency in the cool tier is generally seen with the cloud retrieval operations: either requests over the network for I/O to the object store (sequential workloads) or cool block rehydration into the hot tier (random workloads).
 
-## Mixed workload:  sequential and random
-
-A mixed workload contains both random and sequential I/O patterns. In mixed workloads, performance profiles for hot and cool tiers can have drastically different results compared to a purely sequential I/O workload but are very similar to a workload that's 100% random.
-
-The following graph shows the results using 16 jobs on a single VM with a queue depth of one and varying random/sequential ratios. 
-
-:::image type="content" source="./media/performance-considerations-cool-access/mixed-workload-throughput.png" alt-text="Chart showing throughput for mixed workloads." lightbox="./media/performance-considerations-cool-access/mixed-workload-throughput.png":::
-
-The impact on performance when mixing workloads can also be observed when looking at the latency as the workload mix changes. The graphs show how latency impact for cool and hot tiers as the workload mix goes from 100% sequential to 100% random. Latency starts to spike for the cool tier at around a 60/40 sequential/random mix (greater than 12 ms), while latency remains the same (under 2 ms) for the hot tier.
-
-:::image type="content" source="./media/performance-considerations-cool-access/mixed-workload-throughput-latency.png" alt-text="Chart showing throughput and latency for mixed workloads." lightbox="./media/performance-considerations-cool-access/mixed-workload-throughput-latency.png":::
-
-
 ## Results summary
 
 - When a workload is 100% sequential, the cool tier's throughput decreases by roughly 47% versus the hot tier (3330 MiB/s compared to 1742 MiB/s).
 - When a workload is 100% random, the cool tier’s throughput decreases by roughly 88% versus the hot tier (2,479 MiB/s compared to 280 MiB/s).
 - The performance drop for hot tier when doing 100% sequential (3,330 MiB/s) and 100% random (2,479 MiB/s) workloads was roughly 25%. The performance drop for the cool tier when doing 100% sequential (1,742 MiB/s) and 100% random (280 MiB/s) workloads was roughly 88%.
-- Hot tier throughput maintains about 2,300 MiB/s regardless of the workload mix.
 - When a workload contains any percentage of random I/O, overall throughput for the cool tier is closer to 100% random than 100% sequential.
 - Reads from cool tier dropped by about 50% when moving from 100% sequential to an 80/20 sequential/random mix.
 - Sequential I/O can take advantage of a `readahead` cache in Azure NetApp Files that random I/O doesn't. This benefit to sequential I/O helps reduce the overall performance differences between the hot and cool tiers.
 
-## General recommendations
-
-To avoid worst-case scenario performance with cool access in Azure NetApp Files, follow these recommendations:
+## Considerations and recommendations
 
 - If your workload frequently changes access patterns in an unpredictable manner, cool access may not be ideal due to the performance differences between hot and cool tiers.
 - If your workload contains any percentage of random I/O, performance expectations when accessing data on the cool tier should be adjusted accordingly.
 - Configure the coolness window and cool access retrieval settings to match your workload patterns and to minimize the amount of cool tier retrieval. 
+- Performance from cool access can vary depending on the dataset and system load where the application is running. It's recommended to conduct relevant tests with your dataset to understand and account for performance variability from cool access.
 
 ## Next steps
 * [Azure NetApp Files storage with cool access](cool-access-introduction.md)

articles/azure-netapp-files/media/performance-considerations-cool-access/mixed-workload-throughput-latency.png

@@ -13,7 +13,7 @@ ms.workload: storage
 ms.tgt_pltfrm: na
 ms.custom: linux-related-content
 ms.topic: conceptual
-ms.date: 10/16/2024
+ms.date: 10/24/2024
 ms.author: anfdocs
 ---
 # Azure NetApp Files large volume performance benchmarks for Linux
@@ -30,8 +30,8 @@ This article describes the tested performance capabilities of a single [Azure Ne
 
     The Ultra service level was used in these tests. 
 
-* Sequential writes: 100% sequential writes maxed out at 8,500 MiB/second in these benchmarks. (A single large volume’s maximum throughput is capped at 12,800 MiB/second by the service.)
-* Sequential reads: 100% sequential reads maxed out at 10,000 MiB/second in these benchmarks. (At the time of these benchmarks, this limit was the maximum allowed throughput. The limit has increased to 12,800 MiB/second.)
+* Sequential writes: 100% sequential writes maxed out at ~8,500 MiB/second in these benchmarks. (A single large volume’s maximum throughput is capped at 12,800 MiB/second by the service, so more potential throughput is possible.)
+* Sequential reads: 100% sequential reads maxed out at ~12,761 MiB/second in these benchmarks. (A single large volume's throughput is capped at 12,800 MiB/second. This result is near the maximum achievable throughput at this time.)
 
 * Random I/O: The same single large volume delivers over 700,000 operations per second. 
 
@@ -56,7 +56,7 @@ Tests observed performance thresholds of a single large volume on scale-out and
 
 ### 256-KiB sequential workloads (MiB/s) 
 
-The graph represents a 256 KiB sequential workload and a 1 TiB working set. It shows that a single Azure NetApp Files large volume can handle between approximately 8,518 MiB/s pure sequential writes and 9,970 MiB/s pure sequential reads. 
+The graph represents a 256-KiB sequential workload using 12 virtual machines reading and writing to a single large volume using a 1-TiB working set. The graph shows that a single Azure NetApp Files large volume can handle between approximately 8,518 MiB/s pure sequential writes and 12,761 MiB/s pure sequential reads.
 
 :::image type="content" source="./media/performance-large-volumes-linux/256-kib-sequential-reads.png" alt-text="Bar chart of a 256-KiB sequential workload on a large volume." lightbox="./media/performance-large-volumes-linux/256-kib-sequential-reads.png":::
 

articles/azure-netapp-files/media/performance-considerations-cool-access/mixed-workload-throughput.png

@@ -10,61 +10,6 @@ ms.date: 03/20/2024
 
 This article describes how to resolve potential errors in your Bicep installation.
 
-## .NET runtime error
-
-When installing the Bicep extension for Visual Studio Code, you may run into the following error messages:
-
-```error
-Failed to install .NET runtime v5.0
-```
-
-```error
-Failed to download .NET 5.0.x ....... Error!
-```
-
-> [!WARNING]
-> This is a last resort solution that may cause problems when updating versions.
-
-To solve the problem, you can manually install .NET from the [.NET website](https://aka.ms/dotnet-core-download), and then configure Visual Studio Code to reuse an existing installation of .NET with the following settings:
-
-**Windows**
-
-```json
-"dotnetAcquisitionExtension.existingDotnetPath": [
-  {
-    "extensionId": "ms-azuretools.vscode-bicep",
-    "path": "C:\\Program Files\\dotnet\\dotnet.exe"
-  }
-]
-
-```
-
-**macOS**
-
-If you need an **x64** installation, use:
-
-```json
-"dotnetAcquisitionExtension.existingDotnetPath": [
-  {
-    "extensionId": "ms-azuretools.vscode-bicep",
-    "path": "/usr/local/share/dotnet/x64/dotnet"
-  }
-]
-```
-
-For other **macOS** installations, use:
-
-```json
-"dotnetAcquisitionExtension.existingDotnetPath": [
-  {
-    "extensionId": "ms-azuretools.vscode-bicep",
-    "path": "/usr/local/share/dotnet/dotnet"
-  }
-]
-```
-
-See [User and Workspace Settings](https://code.visualstudio.com/docs/getstarted/settings) for configuring Visual Studio Code settings.
-
 ## Visual Studio Code error
 
 If you see the following error message popup in Visual Studio Code:
@@ -77,7 +22,7 @@ From VS Code, open the **Output** view in the pane at the bottom of the screen,
 
   :::image type="content" source="./media/installation-troubleshoot/visual-studio-code-output-pane-bicep.png" alt-text="Visual Studio Code output pane":::
 
-If you see the following output in the pane, and you're using Bicep CLI **version 0.4.1124** or later, check whether you have added the `dotnetAcquisitionExtension.existingDotnetPath` configuration option to VS Code. See [.NET runtime error](#net-runtime-error). If this configuration option is present, remove it and restart VS Code.
+If you see the following output in the pane, check whether you have added the `dotnetAcquisitionExtension.existingDotnetPath` setting to VS Code. If this setting is present, remove it and restart VS Code. See [User and Workspace Settings](https://code.visualstudio.com/docs/getstarted/settings) for configuring Visual Studio Code settings.
 
   ```error
   It was not possible to find any compatible framework version.