2
votes

Comment les ressources sont-elles réparties entre les applications dans un plan de service d'application

Comment les ressources telles que le processeur / la mémoire sont-elles réparties entre les applications dans le plan de service d'application. Est-ce un partage égal entre les applications? Une application peut-elle consommer 90% des ressources? Je demande cela parce que si les ressources allouées aux applications dans le plan de service d'application sont dynamiques, je créerai plusieurs emplacements (un pour le développement, la mise en scène, la production) De cette façon, je serai sûr que le développement, la mise en scène ne consommera pas plus de ressources et de production. l'application peut occuper, par exemple, 99% des ressources du service d'application si nécessaire


0 commentaires

3 Réponses :


1
votes

Ils ne sont pas séparés, ils sont partagés. Vous ne pouvez pas contrôler les quotas de ressources pour les applications sous App Service Plan, afaik. Il est donc possible que n'importe quelle application puisse utiliser toutes les ressources offertes par App Service Plan.


6 commentaires

Êtes-vous sûr que l'une des applications peut occuper, par exemple, 99% des ressources en cas de besoin?


Je n'ai jamais dit cela. Si ces ressources sont disponibles, il pourrait les réclamer. Vous ne pouvez pas faire en sorte qu'une application prenne des ressources de l'autre application si l'application les utilise.


Bien sûr, une application ne peut pas utiliser de ressource lorsqu'une autre application l'utilise. Mon doute est essentiellement que les ressources seront partagées dynamiquement entre les applications. Une application peut-elle libérer une ressource si elle n'utilise pas beaucoup et une application peut-elle consommer plus de ressources si nécessaire et si elle est disponible


non, sauf si vous codez votre application pour libérer des ressources. App Service Plan ne peut pas forcer votre application à libérer de la mémoire \ connexions TCP \ peu importe


Prenons un exemple. Envisagez un plan de service d'application avec 1 Go de RAM et 2 applications en cours d'exécution. Quelle peut être la mémoire maximale que chaque application peut obtenir? Est-il plafonné à 500 Mo pour les deux? Ou cette dynamique est-elle basée sur l'utilisation de l'application


dynamique en fonction de l'utilisation de l'application



0
votes

Si vous avez appliqué le plan de service au groupe de ressources, il est partagé entre toutes les ressources de ce groupe. Encore une fois, si nous configurons la ressource spécifique avec le cadre et le processeur / mémoire, en fonction de la configuration, le processeur / la mémoire est alloué.


0 commentaires

1
votes

Il n'est pas possible de restreindre l'utilisation des ressources par application dans un seul nœud dans un plan de service d'application.

Cependant, si vous avez plusieurs nœuds, vous pouvez restreindre le nombre de nœuds de l ' application em > évolue jusqu'à.

Les détails sont documentés ici: https://docs.microsoft.com/en-us/azure/app-service/manage-scale-per-app

Voici un exemple si vous utilisez des modèles ARM où le nombre de nœuds de calcul est limité à 5.

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters":{
        "appServicePlanName": { "type": "string" },
        "appName": { "type": "string" }
        },
    "resources": [
    {
        "comments": "App Service Plan with per site perSiteScaling = true",
        "type": "Microsoft.Web/serverFarms",
        "sku": {
            "name": "P1",
            "tier": "Premium",
            "size": "P1",
            "family": "P",
            "capacity": 10
            },
        "name": "[parameters('appServicePlanName')]",
        "apiVersion": "2015-08-01",
        "location": "West US",
        "properties": {
            "name": "[parameters('appServicePlanName')]",
            "perSiteScaling": true
        }
    },
    {
        "type": "Microsoft.Web/sites",
        "name": "[parameters('appName')]",
        "apiVersion": "2015-08-01-preview",
        "location": "West US",
        "dependsOn": [ "[resourceId('Microsoft.Web/serverFarms', parameters('appServicePlanName'))]" ],
        "properties": { "serverFarmId": "[resourceId('Microsoft.Web/serverFarms', parameters('appServicePlanName'))]" },
        "resources": [ {
                "comments": "",
                "type": "config",
                "name": "web",
                "apiVersion": "2015-08-01",
                "location": "West US",
                "dependsOn": [ "[resourceId('Microsoft.Web/Sites', parameters('appName'))]" ],
                "properties": { "numberOfWorkers": "5" }
            } ]
        }]
}

Je ne crois pas que vous puissiez définir la limite de nœuds de travail par emplacement, c'est un par- pour autant que je sache (mais je n'ai pas testé).

En fonction de vos objectifs de performances par rapport à le budget; Je suggérerais de ne pas partager un plan de service d'application entre le développement, la préparation et la production. Le simple fait de compiler le code ralentira l'application (en fonction de la mise à l'échelle de la machine).

Une suggestion est d'avoir des plans de service d'application séparés par environnement, puis d'utiliser des emplacements pour zéro temps d'arrêt déploiement lors du passage à la production, c'est-à-dire la fonctionnalité d'échange de slots.

Normalement, je suppose que sur le développement, vous voudrez exécuter du code expérimental et lors de la mise en scène, vous voudrez peut-être charger des tests (ou d'autres tests), donc vous ne Je ne veux pas que cela interfère avec le trafic de production.

Cependant, cela dit, vous devrez faire attention à ce que vos plans de service de développement et d'application de test ne s'exécutent pas inutilement. Vous devrez donc gérer leur suppression lorsqu'ils ne sont pas utilisés. Par conséquent, en fonction de vos performances / budget / effort de développement, il vous informera si vous souhaitez partager dev / stag / prod dans un plan de service d'application en premier lieu.


0 commentaires