add final pages

Author: JoeStech

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/5-containerization.md

@@ -0,0 +1,55 @@
+---
+title: Containerize the application
+weight: 5
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+# Containerize the application
+
+Containerization should preserve reproducibility across architectures. This page shows practical paths for Dockerfile-based builds and .NET SDK container publish, with guardrails for multi-architecture delivery.
+
+### 1. Dockerfile path
+
+Run a Dockerfile build with buildx:
+
+```bash
+# Create or reuse a buildx builder that supports multi-architecture builds.
+docker buildx create --use --name nopx
+
+# Build and publish a manifest list that includes multiple architectures.
+docker buildx build --platform linux/amd64,linux/arm64 -t [your repo:tag name] --push .
+```
+
+### 2. .NET SDK publish path (single architecture)
+
+Use SDK publish when you want tighter integration with .NET build settings and fewer custom Docker steps.
+
+```bash
+dotnet publish src/Presentation/Nop.Web/Nop.Web.csproj \
+  -c Release \
+  /t:PublishContainer \
+  -p:ContainerImageTag=publish-test
+```
+
+### 3. .NET SDK multi-arch path
+
+Define multi-arch runtime identifiers in the project file, then publish once.
+
+```xml
+<PropertyGroup>
+  <ContainerRuntimeIdentifiers>linux-x64;linux-arm64</ContainerRuntimeIdentifiers>
+</PropertyGroup>
+```
+
+```bash
+# Publish all configured runtime identifiers from one project definition.
+dotnet publish src/Presentation/Nop.Web/Nop.Web.csproj -c Release /t:PublishContainer
+```
+
+This is the scalable path for one image definition across both architectures.
+
+## Recommendation
+
+Use SDK publish as the default migration path. Use a Dockerfile workflow for advanced layer control or custom build logic.

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/6-deploy-verify-cobalt.md

@@ -0,0 +1,54 @@
+---
+title: Performance tuning on Cobalt
+weight: 6
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+# Performance tuning on Cobalt
+
+Treat tuning as an experiment pipeline, not a one-shot tweak. On Arm, apply changes in a controlled sequence, measure with fixed workloads, and keep only optimizations that repeatedly improve your target metrics.
+
+## Tuned run configuration
+
+Start with a conservative runtime profile that is commonly effective for server workloads.
+
+```bash
+export DOTNET_TieredPGO=1
+export DOTNET_ReadyToRun=1
+export DOTNET_gcServer=1
+export DOTNET_gcConcurrent=1
+export DOTNET_EnableDiagnostics=0
+export DOTNET_ThreadPool_ForceMinWorkerThreads=2
+```
+
+Run the same endpoint suite used in the baseline:
+
+```bash
+# Keep benchmark parameters identical to baseline for valid comparison.
+python3 test_nopcommerce_endpoints.py \
+  --base-url http://127.0.0.1:5000 \
+  --concurrency 8 \
+  --iterations 20 \
+  --json-out arm_after.json
+```
+
+## Validation rules for credible tuning gains
+
+Use these rules before adopting a tuning profile:
+
+- Run at least 5 baseline and 5 tuned trials.
+- Keep endpoint sequence fixed across all runs.
+- Reset warm-up policy consistently (always warm or always cold).
+- Require improvement in both throughput and p95 latency, not just one.
+- Set a minimum practical threshold (for example, >=5% median gain) before rollout.
+
+## Interpretation
+
+- If only one metric improves while p95 or error rate regresses, do not treat the change as a win.
+- If run-to-run variation is near the observed delta, treat it as noise.
+- Keep architecture-specific profiles separate; do not force one profile onto all architectures.
+
+
+Use this page as a tuning workflow template, then validate with your production-like traffic profile before rollout.

content/learning-paths/servers-and-cloud-computing/dotnet-migration-nopcommerce/7-arm-mcp-server.md

@@ -0,0 +1,78 @@
+---
+title: Optimizing with the Arm MCP Server
+weight: 7
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+# Optimizing with the Arm MCP Server
+
+Use the Arm MCP Server after the manual baseline is complete. The agent should accelerate analysis and execution, but your benchmark artifacts remain the source of truth for what actually improved.
+
+If you are new to this toolchain, start with the [Arm MCP Server learning path](https://learn.arm.com/learning-paths/servers-and-cloud-computing/arm-mcp-server/) for setup and core usage patterns.
+
+## 1. Identify endpoints likely to benefit most
+
+Ask the agent to analyze your application routes and classify optimization candidates by CPU intensity, serialization cost, synchronization, and cache behavior.
+
+Prompt template:
+
+```text
+Analyze this .NET application for Arm optimization opportunities.
+Identify endpoints most likely to benefit from Arm tuning.
+Rank them by expected impact and explain why.
+```
+
+Expected output:
+
+- Ranked endpoint list
+- Bottleneck hypotheses per endpoint
+- Instrumentation plan to validate hypotheses
+
+## 2. Generate and run a targeted endpoint test suite
+
+Ask the agent to build a repeatable suite that exercises the ranked endpoints and emits machine-readable output.
+
+Prompt template:
+
+```text
+Create a reproducible endpoint benchmark suite for these routes.
+Use concurrency, iterations, and JSON output.
+Include pass/fail checks for HTTP behavior and error rate.
+```
+
+The suite should produce:
+
+- Per-endpoint latency percentiles
+- Throughput summary
+- Error counts
+- Before/after comparison artifacts
+
+## 3. Plan and implement Arm optimizations on Azure Cobalt
+
+Ask the agent to create an execution plan, apply changes, run tests, and report deltas.
+
+Prompt template:
+
+```text
+On this Ubuntu Neoverse (Azure Cobalt) instance:
+1) establish baseline,
+2) apply Arm-focused .NET runtime and deployment optimizations,
+3) rerun tests,
+4) report statistically meaningful deltas and risks.
+```
+
+Typical optimization actions include:
+
+- Runtime settings (`DOTNET_TieredPGO`, `DOTNET_ReadyToRun`, thread pool tuning)
+- Container/runtime configuration cleanup
+- Architecture-conditional deployment settings
+- Repeated measurement loops with fixed workload parameters and fixed endpoint order
+
+## Practical guardrails
+
+- Keep manual baseline artifacts as source of truth.
+- Require raw output files for every claim.
+- Ask the agent to separate observed facts from inferred explanations.
+- Re-run on production-like traffic before release.