Performance optimization

Overview

This article describes performance optimisation techniques for a Turbo360 private hosting instance. It covers App Service Plan sizing, SQL database tier selection, autoscale configuration, Application Insights performance monitoring, and common patterns that degrade performance over time. Apply these recommendations to maintain consistent response times as your user count, monitored subscription count, or data volumes grow.

Business value

Right-sizing and tuning your Turbo360 infrastructure prevents the two most common performance failure modes — under-provisioned compute causing slow response times and query timeouts, and over-provisioned infrastructure driving unnecessary Azure spend. Proactive performance management also reduces the likelihood of performance degradation surfacing as false-positive monitoring alerts.

Prerequisites

• Contributor access to the Turbo360 resource group in the Azure portal
• Access to Application Insights for the Turbo360 instance
• Familiarity with Azure App Service and Azure SQL scaling options

Required permissions

How it works

Turbo360 performance is primarily determined by three resource tiers:

• App Service Plan — controls CPU and memory available to the Web App and Function Apps
• SQL Database — controls query throughput (DTUs) and storage I/O
• Storage Account — generally not a bottleneck; performance depends on the redundancy tier and blob operation frequency

Under normal load, the Web App serves user interface requests and the processor Function App handles background monitoring cycles, cost import jobs, and alert evaluations. SQL is the primary performance bottleneck for large deployments with many monitored subscriptions or high monitoring frequency.

Configuration

App Service Plan sizing

Scale up the App Service Plan when you observe:

• Web App response times consistently above 5 seconds
• Function App processing falling behind schedule (monitoring cycles not completing within the cycle interval)
• Application Insights showing CPU or memory pressure on Function App instances

SQL database tier sizing

Scale up the SQL tier when you observe:

• SQL DTU consumption consistently above 80% (visible in Azure portal SQL metrics)
• Query timeouts in Application Insights exceptions
• Slow load times on Cost Analyzer analysis views or BAM transaction history

Autoscale configuration

Configure autoscale on the App Service Plan to handle variable load without manual intervention.

1. In the Azure portal, navigate to the App Service Plan.
2. Select Scale out (App Service plan) under Settings.
3. Switch from Manual scale to Custom autoscale.
4. Add a scale-out rule: trigger on CPU Percentage > 70% for 5 minutes; increase instance count by 1.
5. Add a scale-in rule: trigger on CPU Percentage < 30% for 10 minutes; decrease instance count by 1.
6. Set minimum instances to 2 (or 3 if zone redundancy is enabled) and maximum instances based on your budget.
7. Click Save.

Application Insights performance monitoring

Use Application Insights to identify slow requests and bottlenecks before they affect users.

Key metrics to monitor:

To create a performance alert:

1. In the Azure portal, navigate to Application Insights.
2. Select Alerts > + New alert rule.
3. Add a condition (for example, Server response time > 5 seconds).
4. Configure an action group to notify via email or Teams.
5. Save the alert rule.

SQL index maintenance

Over time, SQL index fragmentation can degrade query performance. Azure SQL performs automatic index maintenance by default, but fragmentation may still accumulate for high-write workloads such as BAM push model deployments.

Run the following query in the Azure portal Query Editor or SQL Server Management Studio (SSMS) to check index fragmentation:

SELECT 
    OBJECT_NAME(ips.object_id) AS TableName,
    i.name AS IndexName,
    ips.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') ips
JOIN sys.indexes i ON ips.object_id = i.object_id AND ips.index_id = i.index_id
WHERE ips.avg_fragmentation_in_percent > 30
ORDER BY ips.avg_fragmentation_in_percent DESC;

If fragmentation exceeds 30% on tables with high query frequency, rebuild or reorganise the affected indexes. Contact Turbo360 support before running index maintenance on Turbo360 tables.

Example scenario

A platform engineer notices that Cost Analyzer analysis views are taking 8–10 seconds to load for a deployment with 30 monitored subscriptions and 60 active users. Application Insights shows SQL query duration averaging 4 seconds and DTU consumption at 85%. They scale the SQL database from Standard S2 to Standard S4, reducing query duration to under 1 second. They also configure autoscale on the App Service Plan (minimum 2, maximum 4 instances, trigger at 70% CPU) to handle load spikes during morning peak usage. Response times drop to under 2 seconds.

Limitations

• Scaling up the SQL database causes a brief connection interruption (typically under 30 seconds) while the tier change is applied.
• Autoscale adds new App Service instances within 2–5 minutes. Sudden load spikes may cause degraded performance during scale-out.
• Standard tier SQL does not support zone redundancy. Scaling to Premium for performance may also be required to enable zone redundancy.
• Index maintenance on Turbo360 SQL tables should only be performed under guidance from Turbo360 support to avoid disrupting table schemas or application behaviour.
• Application Insights sampling may suppress high-frequency telemetry. Adjust the sampling rate if you need full request telemetry for performance diagnosis.

Troubleshooting

1. Web App response times are slow despite a recent scale-up
   Cause: The scale-up change has not yet taken effect, or the bottleneck is in SQL rather than App Service compute.
   Fix: Confirm the App Service Plan tier change is applied in the Azure portal. Check SQL DTU metrics — if DTU consumption is high, scale up the SQL tier rather than the App Service Plan.

2. Function App monitoring cycles are not completing on schedule
   Cause: The processor Function App is resource-constrained or encountering repeated exceptions.
   Fix: Review Application Insights for Function App failures and duration metrics. Scale up the App Service Plan and check for exception patterns in the Failures blade.

3. Autoscale is not triggering despite high CPU
   Cause: The autoscale rule cooldown period is preventing rapid scale-out, or the CPU threshold is set too high.
   Fix: Review the autoscale settings and reduce the CPU threshold or cooldown period. Verify the autoscale rule is saved and active.

4. SQL query times are high even after scaling up the tier
   Cause: Index fragmentation or table statistics are stale on high-write Turbo360 tables.
   Fix: Contact Turbo360 support to evaluate whether index maintenance or statistics updates are appropriate for the affected tables.

5. Application Insights shows no data
   Cause: Application Insights connection string is missing or invalid in the App Service configuration.
   Fix: In the Azure portal, navigate to App Service > Configuration and verify that APPLICATIONINSIGHTS_CONNECTION_STRING is set to the correct Application Insights connection string. Restart the App Service after updating the setting.

FAQs

1. How do I know if Turbo360 performance issues are caused by my Azure resources or the application layer?
   Use Application Insights to distinguish between server-side (SQL, compute) and client-side (browser, network) latency. High SQL query duration in the Performance blade points to a SQL tier or index issue. High server response time with low SQL duration points to App Service compute constraints.

2. Can I reduce costs by scaling down the App Service Plan during off-hours?
   Yes. Autoscale can be configured with scheduled profiles to scale down to fewer instances during off-peak hours (for example, nights and weekends) and scale back up before business hours. This reduces costs without manual intervention.

Related articles

• Environment health
• High availability
• Maintenance
• Infrastructure requirements
• Private hosting architecture