How many web services

Question

I have a web service that looks like this:

public class TheService : System.Web.Services.WebService { [WebMethod(EnableSession = true)] public string GetData(string Param1, string Param2) { ... } } 

In other words, it is contained in one class and there, I have one public method, and there is another private method that reads in the database.

The problem I'm facing is scalability. I am creating a web application that should work for 1000 daily users, and each user will make about 300-500 calls per day to the web service and, therefore, from 300,000 to 500,000 requests per day. I need to add 9 more calls to the web service. Some of these calls will be associated with a database record.

My question is this: I better create 9 separate web services or continue working with one service that I have and add other methods. Or maybe something else and better. I plan to deploy the application to Azure, so I'm not really worried about the hardware, but just part of the application.

Answer 1

I would not base my decision on a volume or for performance / scalability reasons. You will not get much if any performance advantage comes from concentrating or separating them. Any grouping or filtering that can be performed when services are grouped in one direction can also be performed using services grouped in a different way. The ability to split between servers will be the same.

Design

Instead, I will focus on making the code understandable and maintainable. Group your services as they matter most to your program architecture. Keep them logically grouped, as they make the most sense for grouping, in terms of the problem domain (as opposed to the solution domain perspective).

Since you can group them the way you want, I recommend that you read SOLID , which is a set of guiding principles for creating software architecture.

One of these principles is the particularly important principle >, which can be defined by the notion that "many client specific interfaces are better than one general purpose interface."

Performance and scalability

Since you mentioned performance and scalability that are a concern, I recommend you follow this plan:

• Determine how long you can wait until you can complete the patch / software support.
• Determine the expected load, including both the average and maximum load, depending on the time (you determined the average value), and how much you expect this traffic to grow over time (especially during the period that you can go without fixing / maintenance software)
• Create a model that describes what calls will be made and in what proportions (over time and to the server)
• Create automation that accurately reflects these models. Try to simulate both medium and peak traffic and outperforming your traffic with the highest scale.
• Profile your code, DB, network traffic and disk traffic when starting this automation.
• Identify bottlenecks, and if they are within tolerance
• Optimize your bottlenecks (as needed) and repeat from the profiling step
• In the next version of your software, repeat from above to add scripts / downloads / automation
• Perform regression testing using existing tests, modified according to the new scale

Answer 2

Dividing web methods into several web services will not help you; load balancing will be.

Answer 3

The number of web services will not affect the scalability of the application.

Finding your bottlenecks will help scalability. If you are a bottleneck in the database, you may need to find ways to customize your queries, split your data into other stores, etc. If you are a bottleneck, this is the central processor on web services (web roles in blue), then adding a few clusters to the cluster will help. Azure supports this.

But just don't start adding roles. Understand where your bottlenecks are. Measurement, profile and tuning.

Azure has local and local area networks that can also help you in your profile.

Answer 4

Dividing web services into multiple web roles due to physical limitations and optionally due to logical layout may be worth considering because:

Using Azure, you can scale your roles independently. This means that if different web methods have to scale according to different patterns (i.e., your first web method has the largest volume in the morning and afternoon, and the other two web methods have the largest volume in the evening and night) and the last The 2 web methods are usually flat throughout the day, which is very good, it may be worthwhile to separate your methods by role according to scalability restrictions, and not according to logical restrictions.

By increasing / decreasing the servers allocated for each method, you may be able to fine-tune the optimal power compared to demand with much greater accuracy.

NTN

Answer 5

In fact, the creation of separate web services, as Igorek suggested, will provide a much larger scale. In this case, you can deploy different web services for different roles, each of which gets its own set of instances (along with the ability to create different sizes of instances for each role). Windows Azure will balance the load across all role instances.

So, in terms of detail:

• Least granular. Combine all methods in one web service hosted on the same role. When you scale to multiple instances, all service method requests are load balanced in all instances. Since you combine everything into one role, you will find that it is optimized for cost: you can run all the web services code in one instance (actually 2 instances to provide SLA).
• More detailed: create separate web services, each with its own methods, and a host on the same role (allows you to implement SOLID principles, as Merlin described). The same basic performance characteristics as the first option, since all requests are still load balanced in one set of instances.
• Most granular: create separate web services, each with its own methods, and place each web service endpoint in a separate role, allowing independent calibration of virtual machines and scaling of each web service endpoint. This option has a higher execution cost, since now you have at least one instance for the web service endpoint (again, 2 instances in the real world, direct application).

Answer 6

I'm not sure about your specific case, but to solve Azure tasks it is preferable to move expensive (from the point of view of CPU / DB) tasks to separate the role of the worker. In this case, you will have one WebRole with services that will receive requests (this will be light weight, so you will not have many instances for it) and create tasks for the worker roles and one or more work roles that will handle these tasks - 1 Worker roles can be created for each type of task (to group similar actions, such as reading / writing data to the database) or No. 2, one work role can handle any tasks. I do not see any advantages in # 2, because to get the same behavior you can just create one WebRole with many instances and handle everything there. Thus, you will have the opportunity to control the processing time by adding / removing worker roles.

Other people believe that using the Azure platform alone will not make the application scalable, especially if you use Azure SQL, you will need to implement the outline or add a lot of DB to avoid one large database for all queries.

I don’t know if this is related to this task, but just to inform you - Azure refuses connections that are inactive for 60 seconds (I did not find a way to increase this timeout, you can Google this problem). Perhaps the problem is with porting web services to Azure, and your answers can reach 60 seconds. One way to avoid this is to keep the connection active, which is pretty simple if clients know about this “feature”.