Originally my code created a new HttpClient in a using statement on every request. Then I read several articles about reusing HttpClient to increase performance.
Here is an excerpt from one such article:
I do not recommend creating a HttpClient inside a Using block to make a
single request. When HttpClient is disposed it causes the underlying
connection to be closed also. This means the next request has to
re-open that connection. You should try and re-use your HttpClient
instances.
http://www.bizcoder.com/httpclient-it-lives-and-it-is-glorious
It seems to me that leaving a connection open is only going to be useful if multiple requests in a row go to the same places - such as www.api1.com.
My question is, how may HttpClients should I create?
My website talks to about ten different services on the back end.
Should I create a single HttpClient for all of them to consume, or should I create a separate HttpClient per domain that I use on the back end?
Example:
If I talk to www.api1.com and www.api2.com, should I create 2 distinct HttpClients, or only a single HttpClient?
Indeed, Disposing of HttpClient will not forcibly close the underlying TCP/IP connection from the connection pool. Your best performance scenario is what you have suggested:
Keep an instance of HttpClient alive for each back-end service you need to connect to or the lifetime of your application.
Depending on the details you have about the back-end service, you may also want to have a client for each distinct API on that back-end service as well. (API's in the same domain could be routing all over the place.)
Related
I've read that the general rule of thumb is to create a single HTTP Client instance to be used by an application for it's life cycle vs. creating an instance and disposing it between requests.
HttpClient is intended to be instantiated once and reused throughout the life of an application.
The above is per Microsoft's documentation for the HTTP Client. This makes sense to me in the context of something such as a console app that fires up, executes some code, and then quits.
Is the same principal still the best practice when making HTTP Requests in a Web App/API? Not sure if this would fit the same scenario since the 'life cycle' of the app would be indefinite as long as it is up and online.
If so, are there specific best practices for use in a Web App? Thinking of things such as making it a static instance (if so where should it live), putting it in a service class, etc.
I am using SignalR to setup a connection between my client and my server. I would like to store some user data on init. When the user calls a method I want access to these variables to do some calculations and send a response back to the client.
I can not use static variables because I want these variables to be individual for each client. Saving these variables in one global dictionary seems not performant for a lot of users. Saving the data in a database is not an option because the client will call a method approximately every 15-30 seconds and this for a few minutes and then the hub can be disposed.
What I am trying to archieve is one hub instance per client. One open connection with the server, 1-on-1. Is this possible with SignalR and how or do I have to look for another library?
Thanks a lot,
Have a great day!
by trying to get a hub instance per client connection is pretty hard since hubs are designed to be just the opposite (a way to talk to some or all clients connected)
you are probably looking for the Persistent Connection API
PS: I don't really see why you rule out a db so quickly since you could always use an in memory cache like redis.
I have a data server pushing data through my .NET server to clients using ?SignalR. Because a SignalR Hub instance is created per request, but I want only one connection / subscription to the data server, I'm using a singleton controller to manage and map incoming data to the corresponding client.
My problem now is: when and how can I dispose this one connection on application termination (even forced termination)?
I'm quite new to handling connections in .NET so this might be really easy. Maybe there's a better application design as using the singleton controller.
I have a WCF webservice that acts as a data provider for my ASP.NET web page.
Throughout the web page a number of calls are made to the web service via the auto-generated ServiceClient.
Currently I create a new ServiceClient and open it for each request i.e. Get Users, Get Roles, Get Customer list etc.... Each one of these would create a new ServiceClient and open a new connection.
Can I make my ServiceClient class a global or statically available class so that all functions within my ASP.NET web page can use the same client. This would seem to be far more efficient. Are there any issues with doing it this way? Any advice I should take into account when doing this?
What happens if I make multiple requests to a client? Presumably it is all synchronous so it shouldn't matter if I make 1 or 50 calls to it?
Thanks
When session (wsHttp with security context or reliable session) or connection (net.tcp, net.pipe) oriented binding is used you have to handle your proxy in the way you want to handle the session. So if you share the proxy, all calls will be handled in single WCF session (by default handled by single service instance). But you have to deal with additional complexity like: Unhandled service exception will terminate your channel and following call from client will result in exception.
When session-less HTTP binding (basicHttp, webHttp) is used you can share your proxy or even make it static. Each call is handled separately, exception on a service will not fault the channel and it transparently reuses opened HTTP persistent connections. But because of this, there should be no big overhead to creating new proxy / channel.
So my suggestion is: When you need several calls to your service in single request processing in your ASP.NET application, use the same proxy / channel. But don't share proxy / channel among different requests.
I think using a ChannelFactory could take of your problem. If I'm right the ChannelFactory has a pool of your connection and re-uses the channels. The advantage of this is that the channels don't get instatiated each time, only the first.
Read more here: ChannelFactory
To handle the disposing of the channels you need some special handling since the channel can throw exception in dispose. I wrote a mapper to handle this, you can read about it here: http://blog.tomasjansson.com/2010/12/disposible-wcf-client-wrapper/
Can you please answer to the following questions to enlighten me about web services.
What is the lifecycle of web service ? When the class which represents my web service gets instanced and when it's start running (executing) ?
Is it there new instance created for every webMethod call ? And what happens if there are multiple simultaneous requests for same or different web method ?
When to open connection to remote resource, that the onnection is ready before any requests. And this connection must persist through whole lifetime of web service.
Thank you in advace for all answers.
Webservices are nothing more than ASP.NET pages communicating on the SOAP protocol (XML over HTTP). Each method have its own round-trip (like a page, so new instances are created by default). ASP.NET thread pool is used for running a webservice. As web programmer you don't have lot of control over how thread pool is used since it depends on many external factors (system resources, concurrent page requests...).
If you mean database connections by 'Opening connection to remote resources' these connections also are pooled by Connection Pool of ADO.NET and it will be managed automatically. If you external resources are heavy use Singleton webservice model and load external resources in constructor. Don't use singleton patteron on a database connection (It has its own pooling mechanism). You should take care of concurrency issues for your static variables if you are choosing Singleton pattern.
At the end I should say living in managed-world of programming is easier than ever. Most of the time somebody is caring about our doubts.
That depends; You have two instancation models.
"Single Call" (an instance is created for each call made to the service)
"Singleton" (an instance is created on the first call and reused as long as the process remains alive).
See answer 1; Eleboration; Yes, each call get's its own instance
I would seperate that away from the actual Web Service class. You can use another singleton approach to achieve this functionality.
Hope this helps,