Merge branch 'MicrosoftDocs:main' into docs-editor/container-insights-log-query-1694530119

Author: bwren

articles/cosmos-db/nosql/TOC.yml

@@ -658,7 +658,11 @@
             - name: Async Java SDK v2
               href: performance-tips-async-java.md
             - name: Sync Java SDK v2
-              href: performance-tips-java.md
+              href: performance-tips-java.md        
+        - name: JavaScript
+          items:
+            - name: Best practices for JavaScript SDK
+              href: best-practices-javascript.md
         - name: Configure the integrated cache
           href: ../how-to-configure-integrated-cache.md
         - name: Benchmarking framework

articles/cosmos-db/nosql/best-practices-javascript.md

@@ -0,0 +1,48 @@
+---
+title: Best practices for JavaScript SDK
+titleSuffix: Azure Cosmos DB
+description: Review a list of best practices for using the Azure Cosmos DB JavaScript SDK in a performant manner.
+author: sajeetharan
+ms.author: sasinnat
+ms.reviewer: sidandrews
+ms.service: cosmos-db
+ms.subservice: nosql
+ms.topic: best-practice
+ms.date: 09/11/2023
+---
+
+# Best practices for JavaScript SDK in Azure Cosmos DB for NoSQL
+
+[!INCLUDE[NoSQL](../includes/appliesto-nosql.md)]
+
+This guide includes best practices for solutions built using the latest version of the JavaScript SDK for Azure Cosmos DB for NoSQL. The best practices included here helps improve latency, improve availability, and boost overall performance for your solutions.
+
+## Account configuration
+
+- Make sure to run your application in the same [Azure region](../distribute-data-globally.md) as your Azure Cosmos DB account, whenever possible to reduce latency. Enable 2-4 regions and replicate your accounts in multiple regions for [best availability](../distribute-data-globally.md). For production workloads, enable [service-managed failover](../how-to-manage-database-account.md#configure-multiple-write-regions). In the absence of this configuration, the account experiences loss of write availability for all the duration of the write region outage, as manual failover can't succeed due to lack of region connectivity. For more information on how to add multiple regions using the JavaScript SDK, see the [global distribution tutorial](tutorial-global-distribution.md).
+
+## SDK usage
+
+- Always using the [latest version](sdk-nodejs.md) of the Azure Cosmos DB SDK available for optimal performance.
+- Use a [single instance](/javascript/api/@azure/cosmos/cosmosclient?view=azure-node-latest&preserve-view=true) of `CosmosClient` for the lifetime of your application for better performance.
+- Set the [preferredRegions](/javascript/api/@azure/cosmos/connectionpolicy?view=azure-node-latest#@azure-cosmos-connectionpolicy-preferredlocations&preserve-view=true) in the SDK using [ConnectionPolicy](./tutorial-global-distribution.md). During failovers, write operations are sent to the current write region and all reads are sent to the first region within your preferred regions list. For more information about regional failover mechanics, see [availability troubleshooting](troubleshoot-sdk-availability.md).
+- A transient error is an error that has an underlying cause that soon resolves itself. Applications that connect to your database should be built to expect these transient errors. To handle them, implement retry logic in your code instead of surfacing them to users as application errors. The SDK has built-in logic to handle these transient failures on retryable requests like read or query operations. The SDK can't retry on writes for transient failures as writes aren't idempotent. The SDK does allow users to configure retry logic for throttles. For details on which errors to retry on [visit here](conceptual-resilient-sdk-applications.md#should-my-application-retry-on-errors).
+- Use SDK logging to capture extra diagnostic information and troubleshoot latency issues.
+
+## Data design
+
+- The request charge of a specified operation correlates directly to the size of the document. We recommend reducing the size of your documents as operations on large documents cost more than operations on smaller documents.
+- Some characters are restricted and can't be used in some identifiers: '/', '\\', '?', '#'. The general recommendation is to not use any special characters in identifiers like database name, collection name, item ID, or partition key to avoid any unexpected behavior.
+- The Azure Cosmos DB indexing policy also allows you to specify which document paths to include or exclude from indexing by using indexing paths `IndexingPolicy#getIncludedPaths()` and `IndexingPolicy#getExcludedPaths()`.  Ensure that you exclude unused paths from indexing for faster writes.  For more information, see [creating indexes using the SDK sample](performance-tips-java-sdk-v4.md#indexing-policy).
+
+## Host characteristics
+
+- You may run into connectivity/availability issues due to lack of resources on your client machine. Monitor your CPU utilization on nodes running the Azure Cosmos DB client, and scale up/out if usage is high. Also, consider running your workload using the [cluster](https://nodejs.org/api/cluster.html) module.
+- For most common cases of production workloads, we highly recommend using at least 4-cores and 8-GB memory VMs whenever possible.
+- If using a virtual machine to run your application, enable [Accelerated Networking](../../virtual-network/create-vm-accelerated-networking-powershell.md) on your VM to help with bottlenecks due to high traffic and reduce latency or CPU jitter. You might also want to consider using a higher end Virtual Machine where the max CPU usage is under 70%.
+- By default, query results are returned in chunks of 100 items or 4 MB, whichever limit is hit first. If a query returns more than 100 items, increase the page size to reduce the number of round trips required. Memory consumption increases as page size increases.
+
+## Next steps
+
+> [!div class="nextstepaction"]
+> [Partitioning and scaling in Azure Cosmos DB](../partitioning-overview.md).

articles/firewall/premium-features.md

@@ -111,7 +111,7 @@ IDPS signature rules have the following properties:
 |Signature ID     |Internal ID for each signature. This ID is also presented in Azure Firewall Network Rules logs.|
 |Mode      |Indicates if the signature is active or not, and whether firewall drops or alerts upon matched traffic. The below signature mode can override IDPS mode<br>- **Disabled**: The signature isn't enabled on your firewall.<br>- **Alert**: You receive alerts when suspicious traffic is detected.<br>- **Alert and Deny**: You receive alerts and suspicious traffic is blocked. Few signature categories are defined as “Alert Only”, therefore by default, traffic matching their signatures isn't blocked even though IDPS mode is set to “Alert and Deny”. Customers may override this by customizing these specific signatures to “Alert and Deny” mode. <br><br>IDPS Signature mode is determined by one of the following reasons:<br><br> 1. Defined by Policy Mode – Signature mode is derived from IDPS mode of the existing policy.<br>2. Defined by Parent Policy – Signature mode is derived from IDPS mode of the parent policy.<br>3. Overridden – You can override and customize the Signature mode.<br>4. Defined by System - Signature mode is set to *Alert Only* by the system due to its [category](idps-signature-categories.md). You may override this signature mode.<br><br>Note: IDPS alerts are available in the portal via network rule log query.|
 |Severity      |Each signature has an associated severity level and assigned priority that indicates the probability that the signature is an actual attack.<br>- **Low (priority 3)**: An abnormal event is one that doesn't normally occur on a network or Informational events are logged. Probability of attack is low.<br>- **Medium (priority 2)**: The signature indicates an attack of a suspicious nature. The administrator should investigate further.<br>- **High (priority 1)**: The attack signatures indicate that an attack of a severe nature is being launched. There's little probability that the packets have a legitimate purpose.|
-|Direction      |The traffic direction for which the signature is applied.<br>- **Inbound**: Signature is applied only on traffic arriving from the Internet and destined to your [configured private IP address range](#idps-private-ip-ranges).<br>- **Outbound**: Signature is applied only on traffic sent from your [configured private IP address range](#idps-private-ip-ranges) to the Internet.<br>- **Bidirectional**: Signature is always applied on any traffic direction.|
+|Direction      |The traffic direction for which the signature is applied.<br><br>- **Inbound**: Signature is applied only on traffic arriving from the Internet and destined to your [configured private IP address range](#idps-private-ip-ranges).<br>- **Outbound**: Signature is applied only on traffic sent from your [configured private IP address range](#idps-private-ip-ranges) to the Internet.<br>- **Internal**: Signature is applied only on traffic sent from and destined to your [configured private IP address range](#idps-private-ip-ranges).<br>- **Any**: Signature is always applied on any traffic direction.|
 |Group      |The group name that the signature belongs to.|
 |Description      |Structured from the following three parts:<br>- **Category name**: The category name that the signature belongs to as described in [Azure Firewall IDPS signature rule categories](idps-signature-categories.md).<br>- High level description of the signature<br>- **CVE-ID** (optional) in the case where the signature is associated with a specific CVE.|
 |Protocol     |The protocol associated with this signature.|