Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
We are trying to create a solution for high frequency trading application on SOA. As resident of .NET, we are using WCF services. Searching Google, I found REST payload is less than the SOAP payload. REST is faster than the SOAP. At the same time, SOAP has some other advantages like Transaction support, more binding support, so on.
Which will be faster netTCPbinding with SOAP or REST with JSON?
Which one should has more advantages for high load and low latency system?
Any pointers?
Generally speaking REST has a better performance, you may check this entry Rest vs. Soap. Has REST a better performance?
Anyway for HFT this could be not enough, as Udi said, you may pay attention to your application architecture and your infrastructure, avoid closing connections, use TCP protocol directly instead HTTP, use non-blocking io technics to improve TPS, maybe using messaging systems (kind of JMS) ...
is a broad topic
For any type of low latency scenario, you should be avoiding network calls like the plague. If you really want to play in the HFT space, you'll need to handle much deeper architectural questions than the ones raised here.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I want to stress my .net web service, It feels like something is limiting the concurrent connections I can have.. even when trying from 2 different computers on them server the results were pretty the same. (All of this is done locally, server and clients are on local network so response time is very fast)
So is there a settings I need to change in my server machine to allow more incoming connections?
There are various things that can limit the amount of processing possible, each of which require research to see if they apply. So you might want to add more to your question about what has been verified today.
Regardless, based on your information I would assume that SessionState is enabled. This, with default behavior will limit processing to a single request at a time for each client due to synchronization locks for guaranteed read-write ability. I assume this is the root cause of what you are seeing today. This StackOverflow post talks about this specifically
Others have posted various details in the comments that can help also.
I have found though that load testing is best done from outside sources as well to ensure your entire production pipeline is involved. (Network components, etc)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I apologize if these are bad questions, however I stumbled upon .NET remoting not too long ago and it's confusing me a little. What I've come to understand is .NET remoting is a way to call an object that is completely separate from your current program, is this correct? (My research includes reading and maybe understanding the MSDN Technical Overview of .NET Remoting).
When I stumbled upon the .NET remoting feature (here), it was because I was looking up methods for multithreading. Is .NET remoting a form of multithreading? Is it related to multithreading at all?
Thank you in advance for your time.
First of all .NET Remoting isn't a good choice if you start a new development because it was discontinued a long time ago. It's still there to provide backwards compatibility.
Since .NET 3.0, the right choice to do what did .NET Remoting has been Windows Communication Foundation.
About your concerns, .NET Remoting was a way of simulating that objects from other AppDomains and even other processes from same or other machines could co-exist like regular, offline objects in a very transparent way.
In a short summary, I would say that .NET Remoting wasn't designed for multi-threading purposes but as an inter-process communication approach.
Now with either WCF or ASP.NET Web API you can consume and emit objects between processes in the same machine or between other machines in the same or other networks. See WCF and ASP.NET Web API self-host flavors to learn how you can host a network API in your process and let other processes consume them.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I want to create a distributed application and I want to be using Web services so that I could consent with the other systems because there will be a version running on mobile and other computer and other smart hours.
But what worries me is being able to protect the application because it would be a lot of data and there will be great to adopt it.
Is HTTPS protocol enough to protect data during transmission and enough inability to eavesdrop on?
my English is poor i use google translate and not very good in that but is the better>
thx
HTTPS should suffice if the whole question circles around the transmission of data between the server and the client. If the data is EXTREMELY sensitive, implement some kind of encryption for the data itself, but in most cases, yes SSL/TLS will do the trick. I would be more worried about getting a proper authentication solution in Place to protect access in the first place.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have an ASMX web service which is internally calling some Payment related APIs and is currently processing few thousand orders daily. We are planning to upgrade this wrapper service to Asp.Net Web APIs. How can I explain the business the benefits of this upgrade in a non technical way as they might not be able to understand the technical terms? Budget and resources is not an issue for this upgrade.
Web API is better because it is based on HTTP and not SOAP. HTTP contains headers that give information on the content. It is more easier to understand and develop for. Since Web API is in HTTP it means that you are able to reach many more clients. The body of a http message can contain any kind of content.
From a business perspective it is easier to maintain, easier to develop and you are able to reach more clients. It also means that you are able to always extend functionality. With those qualities such as the maintainability and the ease of development means that it is ultimately cheaper and more effective.
In software whatever is easy to maintain and understand is the ultimate king from all angles (financial and technological).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am looking for the best way to implement, let's say a middle tier.
In the company I working for, we have two systems written with different programming languages. Each one must communicate with a third system via xml (rest and soap).
The first thing that came in my mind was to create a web application which would accept the calls from our internal systems but I stopped this implementation as I faced some issues regards the soap serialization (How could I do this?).
Except this I thought of WCF but I don't know if it is an appropriate solution for my case.
So, I would like to know which is the best way to implement this.
I'll appreciate any comment
Thanks
You should use WCF for the middle-tier since it provides you with everything you need.
Serialization
Interoperability with Other Web Services Platforms
Interaction with Applications built on other technologies, such as J2EE application servers, that support standard Web services. These applications can be running on Windows machines or on machines running other operating systems.
Security
SOAP All Version and REST
Bindings
Protocols
Discovery