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?
Related
I currently have a WCF service that the website uses to display data. I also use the same service to run a computation that takes about 8-9 hours and it saves the data it computed into the database during the time (the process/server stays alive). The WCF is only used by the website.
Should I switch to ASP.NET Web API? Can Web API run computation for like 8-9 hours and stay alive like the WCF? Basically I can call the web address and it initiates the computation and I also use different web address to get the data for the clients.
Should I even consider Web API?
I've implemented an OData service using ASP.NET WebAPI. I also have some existing web methods in a seperate WCF project which is hosted in an ASP.NET Web Application.
By copying some bits of web config around and copying a couple of code files I've managed to get the WCF methods hosted in the WebAPI project.
Everything seems to be working but I've got a nagging doubt I'm doing something horribly wrong that's going to break when I least expect it.
Is this a good idea?
Depends on your anticipated call volume. The only problem I can think of with this is that incoming WCF requests will be serviced from the same dispatcher thread pool as the OData service. This makes it more likely that you will suffer availability based issues on either endpoint.
I have a WCF service that offers a standard SOAP interface over TCP/IP, HTTP or Named Pipes. This service computes and caches a large, complex, relational data set and offers views on it to clients, via high-level service operations. It's working perfectly.
I also have a separate custom OData service that offers the underlying data in a more "raw" form. This service shares some of the plumbing of the first, with respect to loading and caching the large, complex, relational data set, but is otherwise a standalone service that can be hosted apart from the first.
I'm currently hosting the standard SOAP service in IIS with Windows Process Activation Services, and I'm sure I can do the same thing with the OData service, as a separate endpoint.
If I wanted to host them together in the same IIS host process, what are my options for allowing the two services to share the underlying cached data set, to save on load time and memory consumption?
Assuming you can deal with the limitations of the Reflection Provider or are willing to deal with the complexity of a Custom Provider, you should be able to construct a caching layer that makes the same data available to both your WCF service and your WCF Data Service.
(This would also technically work with the Entity Framework provider, but it sounds like that might not be a good fit for your other needs.)
I can post a sample if you run into trouble getting it up and running.
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
Folks,
I'm building a pretty standard workflow that I want exposed via a WCF endpoint - I'm using the "WCF Service Application" project template and I've got a .xamlx service. This is a very simple document interchange workflow service - I want consumers to POST me a blob of XML as the body of an HTTP post (with HTTP headers containing authentication tokens). In response, these consumers will get a blob of XML containing the reply. 2 goals for me using REST/POX here are the document/message-based nature of the interaction AND I want to make client development easy for non-.NET environments (especially limited environments like Silverlight and iPhone).
I don't really see how to make this possible using out of the box features (unless I'm missing something). Does anybody know how to create a RESTful (or even REST-ish, I'm not picky) endpoint for a WF4 service-hosted workflow? Any info leading in the right direction here would be great.
There is an unreleased item on CodePlex to cover this, which includes source code. Also see this SO answer which contains another idea for achieving this.
If you'd like to see the CodePlex activity released, please up-vote the UserVoice request.
Using a REST Pass-Through Service
As #Maurice mentions, you can also treat the WF service as a back-end service and expose a REST service that simply calls through to the WF service.
This method is a bit clumsy, but has the advantage that it doesn't use anything unreleased or really complicated.
If the back-end service runs on the same machine as the REST service (which is probably what you'd do), you should expose the WF service using the named pipes binding. This binding is fast, but only works when the caller and callee are on the same box.
A further thought: your REST pass-through service is blocked while the back-end service is being called. If your WF service is not very fast, you'd benefit from making your REST service asynchronous so it doesn't block a thread pool thread while the WF service is being called.
There are no out of the box activities that will allow you to use REST with WF, the Receice is pure SOAP.
You can either build a custom REST Receive activity and use that with your workflow. Depending on your needs this is going to be quite a handful to a lot of work. The easy option is use use a standard REST WCF endpoint and convert the REST data to SOAP, pass rhe request on to the workflow, and do the reverse on the result message.