We are building a mobile app where we need to support user concurrency of maybe 10000 initially. The server is completely WCF based and we need to do performance and load testing against these services.
VS2012 has web and performance tests but this is not sufficient for our scenario. VS2012 can only send the exact same request concurrently. We need to send different concurrent requests, maybe change the username, or preferences, etc in each request.
You can try WCF Load Test - http://wcfloadtest.codeplex.com/ You can also consider WCFStorm - http://www.wcfstorm.com/wcf/home.aspx
Related
Sitting in front of the task to create a new small service, I am wondering if there is some best practice guidelines to ensure a fast response time (including the first 1-3 requests) for that service.
First of all I love to create services with .NET Core and the webapi template (.NET Core 6). But having created some of them I notices the delay for the initial request for the service is very slow and all subsequent request on other endpoints are slow as well.
I was wondering if there is something I can do to prevent this, is there some advice to achieve this without sending requests to all endpoints on service start?
The service is not running on AWS or another lambda service like host. The .NET Core services "feel" slow if you compare to fast starting other services written in e.g. Node. I know the real performance(latency, throughput, ...) is another beast and I am very satisfied with that.
I found the following articles but was not satisfied with the result and/or conclusion.
https://andrewlock.net/reducing-latency-by-pre-building-singletons-in-asp-net-core/
https://blog.markvincze.com/running-asp-net-core-in-auto-scaling-containers-warm-up/
Is there a better way to "warm" the service or reduce the impact of the initial request?
I am building a micro-service-oriented .NET Core web application and now I want to add real-time communication. It is possible to create a SignalR server and publish it on Azure? I want to use it in my microservices to send messages to users when a certain even occurs.
Yes, you can deploy your app to Azure and point your users to your hub endpoint with no problems. You have two options here:
Use SignalR and manually manage the connections and other signalR stuff if you will scale your application. For example, when you have 2 web apps and the client connects to one of them, you need to "tell" to other app that you have a new client connected using for example Redis Blackplane.
Use Azure SignalR and this kind of management is not needed, what you need to provide is only 1 app with the hub logic. So when a client connects to your hub it is automaticaly redirected to the Azure SignalR.
You can read more about this two options here:
https://learn.microsoft.com/pt-pt/azure/azure-signalr/signalr-concept-scale-aspnet-core
Why not deploy SignalR myself?ยด
It is still a valid approach to deploy your own Azure web app supporting ASP.NET Core SignalR as a backend component to your overall web application.
One of the key reasons to use the Azure SignalR Service is simplicity. With Azure SignalR Service, you don't need to handle problems like performance, scalability, availability. These issues are handled for you with a 99.9% service-level agreement.
Also, WebSockets are typically the preferred technique to support real-time content updates. However, load balancing a large number of persistent WebSocket connections becomes a complicated problem to solve as you scale. Common solutions leverage: DNS load balancing, hardware load balancers, and software load balancing. Azure SignalR Service handles this problem for you.
Another reason may be you have no requirements to actually host a web application at all. The logic of your web application may leverage Serverless computing. For example, maybe your code is only hosted and executed on demand with Azure Functions triggers. This scenario can be tricky because your code only runs on-demand and doesn't maintain long connections with clients. Azure SignalR Service can handle this situation since the service already manages connections for you. See the overview on how to use SignalR Service with Azure Functions for more details.
Yes you can, this is the official quick start sample.
https://learn.microsoft.com/en-us/azure/azure-signalr/signalr-quickstart-dotnet-core
Please advise me on this.
I have both Wcf service (which will be responsible for highly secured data manipulations) and Web App in same Server and i will access this Web application (Which will consume this Wcf service for data manipulation) over internet.
1) Is this a good practice to have both in same server.
2) What WCF Security i have to choose either Transport or Message security.
3) What type of architecture i have to use (Eg: 3 tier or N- Tier)
I use VS2010 and .Net framework 4.0 and Sql Server 2008 for development.
Thanks in advance.
It is not a simple question to answer if it is a good practice to have the WCF service on the same server as the app. If you want ot shield the service as much as possible you could of course put it on a separate server behind the firewall only allowing the web app to access it. But then it does sound somewhat superfluous to create a service at all. Does it provide methods that should be accessible to a client? -- When determining the deployment scenario you also have to measure cost to security and scalability. More servers means higher costs both for buying the servers and for maintaining them.
I think you can use both transport and message security, but using message security you could transfer the messages on http, which means less traffic than https.
About the number of levels in your application, this also depends on the nature of the application. You might even consider CQRS or similar architectures. But if you have proper segregation of the layers and they only depend on the next layer you can always insert new layers if needed. Speaking of which: If you plan to use the WCF service as an internal DAL, you could also prioritize to just create a simple DAL with a proper interface, which could later be changed to a WCF service.
There are many good reasons for creating a web service and it gives you the opportunity of scaling on more servers later on, so I am definately not recommending against a web service, just saying that it might be overkill or introduce a larger attack surface in your application.
Performance wise you might get a boost by using tcp bindings rather than http, but connecting external applications is easier on http if some non wcf client is involved.
Perhaps this post contains more questions than answers, but you are the only one who can decide given the brevity of your description :)
We have a multi-system solution: several web sites and a separate App-Tier implemented / exposed as WCF services. The web sites all use EntLibs to log stuff - but they need to log to a central DB which is only accessible by the App-Tier.
To get around this we're looking at implementing a WCF service that can have LogEntires sent to it (via a Custom Trace Listener that sends the Log Entries to it).
The decision to use a WCF service is that it's in keeping with the rest of the architecture - and we don't have a lot of time to go doing much else.
I also looked at this and started wondering if we're on the wrong track altogether (from a performance perspective).
So, my question is:
Is this such a bad idea that I should just stop?
If it's viable, what are the traps I need to look out for?
The answer in the question you linked to covers it quite well, if you read between the lines:
Call the WCF logging service with "Is One way" = true, so that your client program does not wait for the logging to complete.
Set the WCF settings such that the client does not throttle the number of requests
A service I have in WCF occasionally goes down due a problem with a COM component. While I am troubleshooting I would like to setup another host to make regular calls to this service to monitor availability.
It is slightly more complicated that a simple HTTP call though as the service is secured by SSL and WCF authentication (username / password). I'd also like to be able to parse successful calls to see if they return warning / fail states from my code.
Would you recommend any monitoring providers for this or is it beyond the simple monitoring they normally provide?
Regards
Ryan
You could enable WCF logging and auditing facilities either on the server or the client to produce a log of all traffic. Then you can analyze the results using the WCF Service Trace Viewer Tool provided in .NET Framework 3.0 and 3.5 SDK.
In your situation I would probably enable logging only at the message level. This will reduce the amount of information that ends up in the log file and will help you focus on analyzing the data that's actually being sent back and forth from the services.