The team I work with has recently migrated from a self hosted setup to IIS hosting of thier web services. The migration went 'smoothly' however we are now seeing some funny behaviour on our server.
If we make a simple request call from our client to our server to get some data from our DB everything works as expected. If we make a call from our client to our server and then the server makes a call to a 3rd party service (hosted off site) then we're seeing a massive increase in response time. A call like this used to take less than a few seconds, since migrating to IIS hosting the response time is over a few minutes.
Has anyone seen this behaviour before? Is it possible that we're having issues with credentials between the IIS hosted server and the 3rd party service?
As long as the bindings haven't changed and you are using the same service identity (i.e. Windows account) then you should get the same performance.
Have you checked whether the service is using static variables and/or multi-threading logic? You could be having resource contention problems with the proxy to the 3rd party service. You'll need to provide more detail about service to get a more specific recommendation.
Related
this is my first questions on SO. Normaly I just wander the internet reading stuff until I can make up a solution.
So up until now we use HTTP Request and Response Model to communicate with Clients.
Using C# ASP.Net .Net Framework 4.0 hosted in IIS.
This way we are not able to forward information in real time to them from the server.
We would need to wait till the clients contact the server.
To solve this issue I think OWIN with SignalR V2 Middleware hosted in IIS would give us the ability to use Remote Procedure Calls, so whenever something happens that needs to be forwarded immediately to the Client, we can do so by calling that specific clients function or all clients.
For this of course the target Framework of the application needs to be .Net Framework 4.5 at least.
Now the problem I have is that in the Microsoft Documentation it says to use the IIS Express version, in order to enable the server to have more than 10 connections.
On the client side it would be no problem as ideally there would only be one connection at any given time.
But the Server should be able to have a whole lot more than just 10. As the Websocketconnections would stay open.
I am not an IIS expert, but why are there these limitations in the non Express version?
I would expect that one should be able to set the number of maximum connections despite the IIS version?
What are the gains of using IIS instead of self-hosting OWIN?
I would guess that I would need to implement some security features myself?
On my development PC a client Windows Service with SignalR V2 is able to communicate with an OWIN SignalR V2 hosted in IIS application.
At the moment I need to evaluate what needs to be considered to set this up on a server to ensure functionality.
I hope this all makes sense.
I am implementing Remote Procedure Calls in our Webservice, for real time communication with clients.
I read documentations about RPC, SignalR V2, OWIN and Katana.
At the moment I need to evaluate what needs to be considered to set this up on a server to ensure functionality.
I have been reading about SignalR API and trying to implement the same. I have created a MVC web application which is a client to the SignalR Hub. The client is a JavaScript client. I have created the SignalR Hub as a part of the same application. What I have learnt is that SignalR could also be self hosted as an independent application. My confusion is that, does it make any difference if I separate it from my web application and host it separately? And are there any pros and cons to both the approaches.
It's up to you how you will organise your projects. I think there are some interesting points:
https://learn.microsoft.com/en-us/aspnet/signalr/overview/deployment/tutorial-signalr-self-host:
Reasons for not hosting in IIS include:
Environments where IIS is not available or desirable, such as an existing server farm without IIS.
The performance overhead of IIS needs to be avoided.
SignalR functionality is to be added to an exising application that runs in a Windows Service, Azure worker role, or other
process.
If a solution is being developed as self-host for performance
reasons, it's recommended to also test the application hosted in
IIS to determine the performance benefit.
I am trying to create a chat application in WCF.
I've created the client and the service on a localhost using httpBinding,
this is the service endpoint:
http://localhost:9999/ProductService
Now, I really don't know how to make the program run 'globaly' and not on a localhost.
Is there anyway to host the server on my pc? or run the application serverless using p2p communications?
Thanks anyway for your Time
You can set up at publicly accessible web server on your own computer, but it's definitely not recommended for any production purposes, unless you have a good understanding of this and have a internet-connection that allows for it, both technically and legally.
You should probably get external web hosting for this instead.
But if you really want to do this, you can install IIS to host the service.
As a side note, I don't think WCF is the optimal route to take for this anymore. Maybee you should check out SignalR and/or WebSockets instead. And ASP.NET Core WebAPI. It's not really anything wrong with WCF, but for new projects I wouldn't recommend it.
I need to write a client-server application. First of all, I'm going to write an application server. Also my app server should connect to database(MS Sql Server) and give data from it to client app. So, as I know, I should use WCF. Is it a good idea? Maybe I need to take a look for something else?
Lets start with client-server architecture.
Assuming you have finalized that you need client and server, but have you decided carefully the architecture? I mean what type of server and what type of client you are going to create?
Let's see the options here:
Server
1. What type of hosting you are going to use?
2. What type and how much load your server needs to handle?
Client
1. Type of consumer of your service
2. Do client need to be deployed on local machine or it should be web based?
There are obviously more concerns than above. Initial design should be as flexible as possible.
So, now lets look at some solutions regarding architecture.
Server:
1. Application Hosted WCF server: Each time you need to manage the server lifecycle. Also, this is not scalable. So if you are looking for scalable architecture, you need to look more.
2. IIS hosted WCF server: This might be a good idea along with some architecture concerns as per your need.
3. Web Method: Obviously this came after WCF, but WCF is still in its place. So the main difference is at What is the difference between an asp.net web method and a wcf service?
Now Client:
1. ASP.NET: This will enable to use a single client app for every platform obviously because of HTML
2. WPF/WinForms: This is going to bit tricky to use as client as you need to deploy the client app on user machine and here comes the data security problem. In former you can directly use SSL or some other way to send data to browser. While in this if you are not using WCF with HTTPS and there are some proprietary data going over wires, it may be concerns.
If you are looking for cross platform usage of your server you can use HTML.
Conclusion:
You can use Server as WCF hosted service (either in IIS or in self contained application) and client as ASP.NET.
-----------------------------If it is not big enough requirement then you can use ASP.NET as server and then browser as client (No need to create client).----------------------------
You can create server either as WCF as web methods and deploy the client on user machine.
----------------------------
WCF is nice enough and it can handle your proprietary data types as well.
WCF is a nice thing, but i would use ASP.Net Self-Hosted Web-API. It's more modern. And you have a full rest interface, which is much more popular.
Here is a comparison: WCF and ASP.NET Web API
Here is a good starting point: Self-Host ASP.NET Web API 1 (C#)
We have a 2.0 Web Service proxy generated for a WCF Service. This service required Basic authentication, but periodically we experience problems that the proxy cannot connect to the Server.
The application is installed on a cluster and referencing a cluster that holds the WCF Service.
Anyone experience this problem already?
Could be that the service is only installed / working on one server in the cluster. Therefore, sometimes it works and sometimes it does not, depending on which machine you hit.
Apparantly it has to do with the setup of the environment. All the machines are virtual and the errors occurs depending on the host they are running on. I also was able to reproduce it with the WCF Proxy as well by switching on/off VM's.
thanks for the answers
You may want to consider deploying an ASMX service backed by the WCF service class. This gives you a classic XML webservices facade to work with.