Testing a scaled out app service

Question

Hi;

I want to test that my software works fine when scaling out. So I've set it to have 2 servers and now need to test. And I turned off session affinity to hopefully get requests bouncing between servers.

First, what/how should I test this?

Second, is there a way to hit a specific one of the servers, via IP address or name? Or does that not make sense with the session affinity turned off?

Third, for my logging, is putting the Environment.MachineName in the log message the best approach?

Fourth, is there a way to set up a naming nomenclature for the server machine names?

Anything else I should do?

thanks - dave

Answer 1

Hi @David Thielen turning off session affinity won't really be useful to you if I understand your scenario correctly because you're basically testing a stateless architecture and you don't have access to a specific server. Azure App Service is a PaaS offering which takes care of auto-scaling for you but if you need more control over the VMs, IP address on which your app runs, load balancing, scaling and all server management then consider using Azure Virtual Machines.

Here are my specific answers to your questions

1. What/how should I test this?: You can also test session persistence, load balancing, failure handling

• Session persistence: Make requests that modify session state (e.g., add items to a cart) and then make subsequent requests to see if the state is maintained. With session affinity off, you should see inconsistencies.
• Load balancing: Send a high volume of requests quickly (you can use tools like Apache JMeter or Azure Load Testing) and monitor your logs to see if requests are distributed across both servers.
• Failure handling: Simulate a server failure by manually scaling down to one instance mid-test to see if requests are handled correctly by the remaining server.

1. Hitting a specific server: the short answer is no. In Azure App Service, you don't have direct access to the underlying VMs or their IP addresses. The load balancer handles request distribution. With session affinity off, there's no way to target a specific server. That's the point—requests should be distributed randomly. Even with session affinity on, you can't choose which server handles a session; Azure manages this.
2. Using Environment.MachineName in logs: Yes, Environment.MachineName is a good approach. It provides a unique identifier for each server instance. In Azure App Service, this will typically be something like RD00155D3809A0 or similar. This helps you track which server handled each request, especially useful when session affinity is off.
3. Setting up server machine names: Like I mentioned above, with Azure App Service you don't have direct control over the machine names. They are automatically assigned by Azure.
4. Other considerations: you may want to monitor server resources (CPU, memory) in the Azure portal to ensure load is distributed, enable Application Insights to track request flows and server handling and test database connections to ensure they're being managed correctly across servers. You can also set up auto-scaling rules based on metrics like CPU or request count to test dynamic scale-out.

Hope that helps.

-Grace