


Application Spring Boot sur AWS Lambda - Partie Mesure des démarrages à froid et à chaud avec l'image native GraalVM et les paramètres de mémoire
Jan 07, 2025 am 07:17 AMIntroduction
Dans l'article 12 de notre série, nous avons exploré comment développer et déployer la fonction Lambda avec un runtime personnalisé contenant une image native GraalVM avec le runtime GraalVM 22 créé à partir de l'application Spring Cloud Function AWS. Dans la partie 13 nous avons mesuré les performances (démarrages à froid et à chaud) d'une telle fonction Lambda avec 1024 Mo de mémoire.
Dans cet article, nous mesurerons les performances (démarrages à froid et à chaud) de la fonction Lambda en utilisant cette approche avec différents paramètres de mémoire entre 256 et 1?536 Mo pour explorer le compromis entre co?t et performances.
Mesure des démarrages à froid et à chaud de la fonction Lambda avec un runtime personnalisé contenant une image native GraalVM avec différents paramètres de mémoire
Nous réutiliserons exactement la même expérience décrite dans la partie 13 de cette série d'articles mais avec des paramètres de mémoire différents entre 256 et 1536 Mo.
Voici les résultats de l'expérience?:
Heure de démarrage à froid (c) et à chaud (m) en ms?:
Memory setting | c p50 | c p75 | c p90 | c p99 | c p99.9 | c max | w p50 | w p75 | w p90 | w p99 | w p99.9 | w max |
---|---|---|---|---|---|---|---|---|---|---|---|---|
256 MB | 1634.84 | 1659.54 | 1691.35 | 1778.03 | 1785.15 | 1785.7 | 6.56 | 6.99 | 7.63 | 18.33 | 372.54 | 857.7 |
512 MB | 1244.44 | 1278.48 | 1313.45 | 1414.28 | 1421.36 | 1421.94 | 6.66 | 7.10 | 7.94 | 25.41 | 181.86 | 414.99 |
768 MB | 1111.53 | 1126.07 | 1139.66 | 1192.08 | 1202.86 | 1203.07 | 6.58 | 6.93 | 7.48 | 12.46 | 115.18 | 278.91 |
1024 MB | 1051.03 | 1061.58 | 1080.86 | 1119.34 | 1149.45 | 1230.28 | 6.45 | 6.77 | 7.33 | 12.50 | 90.92 | 218.17 |
1280 MB | 1022.02 | 1035.39 | 1058.41 | 1065.76 | 1104.64 | 1174.79 | 6.58 | 6.96 | 7.54 | 12.37 | 70.77 | 271.13 |
1536 MB | 1009.83 | 1029.20 | 1048.41 | 1161.32 | 1116.24 | 1148.24 | 6.66 | 7.04 | 7.75 | 12.08 | 63.03 | 215.62 |
Conclusion
Dans cet article, les démarrages à froid et à chaud mesurés de la fonction Lambda à l'aide d'un runtime personnalisé contenant l'image native GraalVM avec le runtime GraalVM 21 créé à partir de l'application Spring Cloud Function AWS introduite dans la partie 12 ayant différents paramètres de mémoire entre 256 et 1 536 Mo.
Nous observons des choses similaires à celles décrites dans l'article Fonction Pure Lambda avec GraalVM Native Image - Mesure des démarrages à froid et à chaud en utilisant différents paramètres de mémoire Lambda. Les temps de démarrage à chaud sont également très proches les uns des autres avec le paramètre de mémoire de fonction Lambda inférieur, comme 256 ou 512 Mo, où la différence est principalement visible pour les percentiles élevés (>= p90). Les temps de démarrage à froid sont assez élevés pour 256 et 512 Mo et à partir de 768 Mo de mémoire ils ne diminuent qu'un peu en donnant plus de mémoire à Lambda, mais sans différence notable pour une mémoire supérieure à 1024 Mo. En fonction de vos exigences de performances, vous pouvez donner à Lambda moins de mémoire que 1 024 Mo comme nous l'avons initialement indiqué dans l'exemple d'application et avoir un très bon compromis prix-performances avec 768 Mo ou même un peu moins de mémoire.
Nous avons également partagé les mêmes observations que celles décrites dans la conclusion de la partie 13. Lorsque nous comparons les temps de démarrage à froid à ceux mesurés dans l'article Fonction Pure Lambda avec GraalVM Native Image - Mesure des démarrages à froid et à chaud à l'aide de différents paramètres de mémoire Lambda ( où la fonction Lambda n'utilise aucun framework comme Spring Boot), nous voyons des valeurs inférieures d'environ 0,5 à 0,6 secondes pour chaque centile lors de l'utilisation de la fonction Lambda pure. Personnellement, je pense que mon exemple d'application Spring Boot 3 a un certain potentiel d'optimisation car je ne peux pas expliquer une si grande différence dans les temps de démarrage à froid entre ceux-ci. Mon attente (peut-être na?ve) est que l'utilisation du framework Spring Boot 3 avec AWS Lambda et l'image native GraalVM ne puisse conduire qu'à des temps de démarrage à froid 0,2 à 0,3 plus élevés par rapport à l'utilisation de la fonction Lambda pure.
Au moment de la publication de cet article, de nouvelles versions des frameworks et des outils utilisés sont devenues disponibles (runtime GraalVM 23, Spring Boot 3.4 et mise à jour de la bibliothèque Spring Cloud Function), vous devez donc apporter les modifications de version et recompiler GraalVM Native. image en suivant les instructions de la partie 2 de la série et mesurez à nouveau les performances. Je publierai également bient?t les nouvelles mesures avec ces versions et mettrai à jour l'exemple d'application.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Outils d'IA chauds

Undress AI Tool
Images de déshabillage gratuites

Undresser.AI Undress
Application basée sur l'IA pour créer des photos de nu réalistes

AI Clothes Remover
Outil d'IA en ligne pour supprimer les vêtements des photos.

Clothoff.io
Dissolvant de vêtements AI

Video Face Swap
échangez les visages dans n'importe quelle vidéo sans effort grace à notre outil d'échange de visage AI entièrement gratuit?!

Article chaud

Outils chauds

Bloc-notes++7.3.1
éditeur de code facile à utiliser et gratuit

SublimeText3 version chinoise
Version chinoise, très simple à utiliser

Envoyer Studio 13.0.1
Puissant environnement de développement intégré PHP

Dreamweaver CS6
Outils de développement Web visuel

SublimeText3 version Mac
Logiciel d'édition de code au niveau de Dieu (SublimeText3)

Sujets chauds

La différence entre le hashmap et le hashtable se reflète principalement dans la sécurité des threads, la prise en charge de la valeur nul et les performances. 1. En termes de sécurité des threads, le hashtable est en filetage et ses méthodes sont principalement des méthodes synchrones, tandis que HashMAP n'effectue pas de traitement de synchronisation, qui n'est pas un filetage; 2. En termes de support de valeur nulle, HashMap permet une clé nul et plusieurs valeurs nulles, tandis que le hashtable ne permet pas les clés ou les valeurs nulles, sinon une nulpointerexception sera lancée; 3. En termes de performances, le hashmap est plus efficace car il n'y a pas de mécanisme de synchronisation et le hashtable a une faible performance de verrouillage pour chaque opération. Il est recommandé d'utiliser à la place ConcurrentHashMap.

Java utilise des classes de wrapper car les types de données de base ne peuvent pas participer directement aux opérations orientées objet, et les formulaires d'objets sont souvent nécessaires dans les besoins réels; 1. Les classes de collecte ne peuvent stocker que des objets, tels que les listes, l'utilisation de la boxe automatique pour stocker des valeurs numériques; 2. Les génériques ne prennent pas en charge les types de base et les classes d'emballage doivent être utilisées comme paramètres de type; 3. Les classes d'emballage peuvent représenter les valeurs nulles pour distinguer les données non définies ou manquantes; 4. Les cours d'emballage fournissent des méthodes pratiques telles que la conversion de cha?nes pour faciliter l'analyse et le traitement des données, donc dans les scénarios où ces caractéristiques sont nécessaires, les classes de packaging sont indispensables.

StaticMethodsinInterfaceswereintrocedInjava8TollowutilityfonctionwithIntheInterface self.beforejava8, telfunctionsrequuresepatehelperclasses, leadstodisorganizedCode.now, staticmethodsprovidethrekeyefits: 1) ils sont en train

Le compilateur JIT optimise le code à travers quatre méthodes: méthode en ligne, détection et compilation de points chauds, spéculation et dévigtualisation de type et élimination redondante. 1. La méthode en ligne réduit les frais généraux d'appel et inserte fréquemment appelées petites méthodes directement dans l'appel; 2. Détection de points chauds et exécution de code haute fréquence et optimiser de manière centralisée pour économiser des ressources; 3. Type Speculations collecte les informations de type d'exécution pour réaliser des appels de déviptualisation, améliorant l'efficacité; 4. Les opérations redondantes éliminent les calculs et les inspections inutiles en fonction de la suppression des données opérationnelles, améliorant les performances.

Les blocs d'initialisation d'instance sont utilisés dans Java pour exécuter la logique d'initialisation lors de la création d'objets, qui sont exécutés avant le constructeur. Il convient aux scénarios où plusieurs constructeurs partagent le code d'initialisation, l'initialisation du champ complexe ou les scénarios d'initialisation de classe anonyme. Contrairement aux blocs d'initialisation statiques, il est exécuté à chaque fois qu'il est instancié, tandis que les blocs d'initialisation statiques ne s'exécutent qu'une seule fois lorsque la classe est chargée.

Injava, thefinalkeywordpreventsavariable'svaluefrombeingchangedafterAsssignment, mais cetsbehaviDiffersFortimitives et objectreferences.forprimitivevariables, finalMakeShevalueConstant, AsinfininTMax_peed = 100; whitereSsignmentCausAnesanerror.ForobjectRe

Le mode d'usine est utilisé pour encapsuler la logique de création d'objets, ce qui rend le code plus flexible, facile à entretenir et à couplé de manière lache. La réponse principale est: en gérant de manière centralisée la logique de création d'objets, en cachant les détails de l'implémentation et en soutenant la création de plusieurs objets liés. La description spécifique est la suivante: Le mode d'usine remet la création d'objets à une classe ou une méthode d'usine spéciale pour le traitement, en évitant directement l'utilisation de newClass (); Il convient aux scénarios où plusieurs types d'objets connexes sont créés, la logique de création peut changer et les détails d'implémentation doivent être cachés; Par exemple, dans le processeur de paiement, Stripe, PayPal et d'autres instances sont créés par le biais d'usines; Son implémentation comprend l'objet renvoyé par la classe d'usine en fonction des paramètres d'entrée, et tous les objets réalisent une interface commune; Les variantes communes incluent des usines simples, des méthodes d'usine et des usines abstraites, qui conviennent à différentes complexités.

Il existe deux types de conversion: implicite et explicite. 1. La conversion implicite se produit automatiquement, comme la conversion INT en double; 2. La conversion explicite nécessite un fonctionnement manuel, comme l'utilisation de (int) MyDouble. Un cas où la conversion de type est requise comprend le traitement de l'entrée des utilisateurs, les opérations mathématiques ou le passage de différents types de valeurs entre les fonctions. Les problèmes qui doivent être notés sont les suivants: transformer les nombres à virgule flottante en entiers tronqueront la partie fractionnaire, transformer les grands types en petits types peut entra?ner une perte de données, et certaines langues ne permettent pas la conversion directe de types spécifiques. Une bonne compréhension des règles de conversion du langage permet d'éviter les erreurs.
