forked from MicrosoftDocs/azure-docs
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request MicrosoftDocs#404 from wesmc7777/wesmc-functions-c…
…onnect New best practices content draft for functions
- Loading branch information
Showing
2 changed files
with
159 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,82 @@ | ||
--- | ||
title: Best Practices for Azure Functions | Microsoft Docs | ||
description: Learn best practices and patterns for Azure Functions. | ||
services: functions | ||
documentationcenter: na | ||
author: wesmc7777 | ||
manager: erikre | ||
editor: '' | ||
tags: '' | ||
keywords: azure functions, patterns, best practice, functions, event processing, webhooks, dynamic compute, serverless architecture | ||
|
||
ms.service: functions | ||
ms.devlang: multiple | ||
ms.topic: article | ||
ms.tgt_pltfrm: multiple | ||
ms.workload: na | ||
ms.date: 11/09/2016 | ||
ms.author: wesmc | ||
--- | ||
|
||
# Best Practices for Azure Functions | ||
|
||
##Overview | ||
|
||
This article provides a collection of best practices for you to consider when implementing function apps. | ||
|
||
|
||
## Avoid long running functions | ||
|
||
Large long running functions can cause unexpected timeout issues. A function can be large because of many Node.js dependencies. Importing these dependencies can cause increased load times resulting in unexpected timeouts. Node.js dependencies could be explicitly loaded by multiple `require()` statements in your code. They could also be implicit based on a single module loaded by your code that has it's own internal dependencies. | ||
|
||
Whenever possible refactor large functions into small function sets that work together. For example a webhook or HTTP trigger function might receive a large payload and pass that payload to a queue trigger function. | ||
|
||
|
||
## Cross function communication. | ||
|
||
When integrating multiple functions, it is generally a best practice to use storage queues for cross function communication. The main reason is storage queues are cheaper and much easier to provision. | ||
|
||
Individual messages in a storage queue are limited in size to 64 KB. If you need to pass larger messages between functions, an Azure Service Bus queue could be used to support message sizes up to 256 KB. | ||
|
||
Service Bus topics are useful if you require message filtering before processing. | ||
|
||
Event hubs are useful to support high volume communications. | ||
|
||
|
||
|
||
## Write functions to be stateless | ||
|
||
Functions should be stateless and idempotent if possible. Associate any required state information with your data. For example, an order being processed would likely have an associated `state` member. A function could process an order based on that state while the function itself remains stateless. | ||
|
||
Idempotent functions are especially recommended with timer triggers. For example, if you have something that absolutely must run once a day, write it so it can run any time during the day with the same results. The function can exit when there is no work for a particular day. Also if a previous run failed to complete, the next run should pick up where it left off. | ||
|
||
Assume your function could encounter an exception at any time. You should design your functions with the ability to continue from a previous fail point during the next execution. | ||
|
||
|
||
## Don't mix test and production code in the same function app. | ||
|
||
Functions within a function app share resources. If you're using a function app in production, don't add test related functions and resources to it. It can cause unexpected overhead during production code execution. | ||
|
||
If you have a shared assembly referenced in multiple .Net functions, put it in a common shared folder. Reference the assembly with a statement similar to the following example: | ||
|
||
#r "..\Shared\MyAssembly.dll". | ||
|
||
Otherwise, it is easy to accidentally deploy multiple test versions of the same binary that behave differently between functions. | ||
|
||
Don't use verbose logging in production code. It has a negative performance impact. | ||
|
||
|
||
|
||
## Avoid references to the Task.Result property | ||
|
||
If you are using asynchronous C# code, avoid referencing the `Task.Result` property. This approach essentially does a busy-wait on a lock of another thread. Holding a lock creates the potential for deadlocks. | ||
|
||
|
||
|
||
|
||
## Next steps | ||
For more information, see the following resources: | ||
|
||
* [Testing a function](functions-test-a-function.md) | ||
* [Scale a function](functions-scale.md) | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,77 @@ | ||
--- | ||
title: Monitoring Azure Functions | Microsoft Docs | ||
description: Learn how to monitor your Azure Functions. | ||
services: functions | ||
documentationcenter: na | ||
author: wesmc7777 | ||
manager: erikre | ||
editor: '' | ||
tags: '' | ||
keywords: azure functions, functions, event processing, webhooks, dynamic compute, serverless architecture | ||
|
||
ms.service: functions | ||
ms.devlang: multiple | ||
ms.topic: article | ||
ms.tgt_pltfrm: multiple | ||
ms.workload: na | ||
ms.date: 11/03/2016 | ||
ms.author: wesmc | ||
--- | ||
|
||
# Monitoring Azure Functions | ||
|
||
## Overview | ||
|
||
> [!IMPORTANT] | ||
> The monitoring tile in the main resource blade will not contain monitoring information for functions on the [Dynamic Hosting plan](functions-overview.md#pricing). | ||
|
||
|
||
Content in progress... | ||
|
||
|
||
## Monitoring log files from a command line | ||
|
||
|
||
You can stream log files to a command line session on a local workstation using the Azure Command Line Interface (CLI) or PowerShell. | ||
|
||
### Streaming function app log file with the Azure CLI | ||
|
||
To get started, [install the Azure CLI](../xplat-cli-install.md) and [connect to your Azure subscription](../xplat-cli-connect.md). | ||
|
||
Use the following command to enable Azure CLI Service Management (ASM) mode:. | ||
|
||
azure config mode asm | ||
|
||
The following command will stream the log files of your function app to the command line: | ||
|
||
azure site log tail -v <function app name> | ||
|
||
### Streaming function app log file with PowerShell | ||
|
||
To get started, [install and configure Azure PowerShell](../powershell-install-configure.md). | ||
|
||
Add your Azure account by running the following command: | ||
|
||
PS C:\> Add-AzureAccount | ||
|
||
If you have multiple subscriptions, you can list them by name with the following command to see if the correct subscription is the currently selected based on `IsCurrent` property: | ||
|
||
PS C:\> Get-AzureSubscription | ||
|
||
If you need to set the active subscription to the one containing your function app, use the following command: | ||
|
||
PS C:\> Get-AzureSubscription -SubscriptionName "MyFunctionAppSubscription" | Select-AzureSubscription | ||
|
||
Stream the logs to your PowerShell session with the following command: | ||
|
||
PS C:\> Get-AzureWebSiteLog -Name MyFunctionApp -Tail | ||
|
||
For more information refer to [How to: Stream logs for web apps](../app-service-web/web-sites-enable-diagnostic-log.md#streamlogs). | ||
|
||
## Next steps | ||
For more information, see the following resources: | ||
|
||
* [Testing a function](functions-test-a-function.md) | ||
* [Scale a function](functions-scale.md) | ||
|