I'm working on a MVC .Net project that uses SignalR as a bi-directional communication between he client and server side.
Lately I've noticed that my CPU is getting overloaded quite quickly when I start the server (from visual studio). I looked around in task manager and seen that iisexpress.exe is consuming almost 90% of my CPU, and if I pause the project it shows that the server is idle and yet it's consuming all of my CPU.
I also tried to run the project on a much stronger PC, but the results were the same.
I read about this issue and saw this is a known issue which can be solved by turning off the browser link option, so I tried that, but not only that it didn't drop my CPU usage back to normal, but it also killed my connection between the server and the client side. Apparently this option is based on the SignalR technology, so by turning that option off I basically kill the communication between them.
I have three questions about it:
How can I solve this issue? turning off browser link doesn't work.
Will this problem persist even after I'll publish the project to the server? meaning it will run directly on the IIS server without VS in the background?
Is it not recommended to use SignalR on large HTML pages?
I would really appreciate your help!
Related
In the domain we have two types of networks. One type is allowed to connect to the internet and the other does not allow connections to the internet. The internal network is available to both.
We have a webserver in the network that hosts a Blazor Server application (using iis). The server is in the network that can use the internet. Now when i use my laptop that is also in the network that can connect to the internet, the website on the server is fast and gives me a snappy response. When i open the same site on a computer that is in the network that is not allowed to connect to the internet, the loading speeds are dramatically decreased. We see a slight increase when we set the protocol to http instead of https, but it is not a game changer.
We see that the data is loaded realy fast but the network request takes up to 6.5 seconds and the loading of data 29 miliseconds.
Anyone have any ideas?
We switched the application from https to http. This was a slight increase.
We used wireshark to check the networktraffic but we see the delays in there as well. The connection itself is good not red flags.
We changed the underlying platform of the application from .net 6 to .net 7. This did not make any difference.
We changed the deployment mode from framework-dependend to self-contained. Still no difference.
As soon as we enable the internet for the network, the site is fast again.
UPDATE 26-01-2023
After some more research we figured out that there are two ip addresses that need to be let through to make it fast again. The IP's are 142.250.179.131 and 23.2.226.23. The first IP is an IP owned by Google and has something to do with gstatic, and the second is from a company named Akamai Technologies.
None of the nuget packages or references in the application code reference any of the packages created by Akamai Technologies or Google. Or is there something else i am missing?
Well, if this is the case. I think this also needs to narrow down the scope of this issue. Have you tried to access the site directly using the domain name and port? For this result, you may need to take different actions:
Issue still occurs. Then this problem may be related to the application code development, you need to review the code and troubleshoot.
Issue resolved. Then you may need to check the performance of IIS server. Try to use the Debug Diagnostic Tool and check its performance. Something like this:
Our team has an application in Android, with a .NET c# backend, hosted in IIS.
Recently, we have observed sudden and unexplainable latencies in our customers with the following scenario:
Without any warning, users are enable to change the channel (Zapping) , since the product has to do with Live Media Streaming, and they can not even log out of the application
The mobile application connected to another backend (still a c# backend) , is working properly, without any problem
After some time (which varies from 6 hours of the first incident, to 5 minutes of the last one), it all turns back to normal.
I have enabled Failed Request Tracing logs, to see if I can get anything from there, and I have results as follows:
<failedRequest url="https://ourDNS.com:443/servertime.aspx"
siteId="1"
appPoolId="DefaultAppPool"
processId="22232"
verb="POST"
remoteUserName=""
userName=""
tokenUserName="NT AUTHORITY\IUSR"
authenticationType="anonymous"
activityId="{80013C53-0802-B500-B63F-84710C7967BB}"
failureReason="TIME_TAKEN"
statusCode="200"
triggerStatusCode="0"
timeTaken="45141"
xmlns:freb="http://schemas.microsoft.com/win/2006/06/iis/freb"
>
The page described above is a simple page, that first gets the server's timezone, and then after getting the customer's timezone (that can be set manually from the client), returns the exact date and time of the device where the application is hosted, for further calculations of stream program, what is playing now etc. However, for this page, that returns a simple JSON with a string in it, it requires some times more than 45 seconds (to me this is insane).
Another log from Client side in the moment is one Exception as above:
java.net.SocketTimeoutException
at java.net.PlainSocketImpl.read(PlainSocketImpl.java:491)
at java.net.PlainSocketImpl.access$000(PlainSocketImpl.java:46)
at java.net.PlainSocketImpl$PlainSocketInputStream.read(PlainSocketImpl.java:240)
at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:103)
at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:191)
at org.apache.http.impl.conn.DefaultResponseParser.parseHead(DefaultResponseParser.java:82)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:174)
at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:180)
at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:235)
at org.apache.http.impl.conn.AbstractClientConnAdapter.receiveResponseHeader(AbstractClientConnAdapter.java:259)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:279)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:121)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:428)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:555)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:487)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:465)
at com.framework.utilityframe.webhelper.HttpRequest.getHttpResponse(HttpRequest.java:316)
at com.framework.utilityframe.webhelper.HttpRequest.httpRequest(HttpRequest.java:393)
at com.tibo.webtv.web.TiboLog.logBufferingError(TiboLog.java:319)
at com.tibo.webtv.CustomVideoView$Buffering_Problem.doInBackground(CustomVideoView.java:324)
at com.tibo.webtv.CustomVideoView$Buffering_Problem.doInBackground(CustomVideoView.java:307)
at android.os.AsyncTask$2.call(AsyncTask.java:287)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305)
at java.util.concurrent.FutureTask.run(FutureTask.java:137)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
at java.lang.Thread.run(Thread.java:856)
Reading through different forums, I have seen different causes of performance leaks, starting from database to IIS and even a misconfiguration of the application. I have discarded database as a cause because:
At the moment of the problem, database parameters were absolutely fine, no changes in queries time execution, no waiting tasks, no locking
Secondly, the mobile and Decoder application connect to the same database, and the mobile application is running just fine with the same queries
Now, if I think of IIS, every Application hosted at that AppPool, was running fine and without delays, but still there may be something I am missing over there
And at least, something that makes me suspicious is the fact that the mobile application differs in two ways with the Decoder application:
First, the mobile application takes the responses from the Backend in XML format, the Decoder uses JSON.
Second,the mobile application uses http requests, and the Decoder uses https (SSL)
If anyone has experienced similar issues, their help would be greatly appreciated. And for any other detail you need, just ask and I will provide.
So,
Today, our team made another test, which included :
Application hosted in one server and database in another
Application and database hosted in a completely different server (Azure environment)
In both cases, the result was the same: Latencies and problem at the service.
The problem was neither at the backend nor the server. First, the Java application by mistake executed Sync Tasks when saving the logs to another server(dedicated, with full potential to keep as much data as you can give). Second, the log server had a full HDD, with more than 1 TB of only DB Logs, so when the application executed those Sync Tasks (which came as the first call, before any interaction with the channels), they received the Socket exceptions. So, maybe for someone else who may see this post: PLEASE,ALWAYS CHECK YOUR TASKS IN YOUR APPLICATION,AND ALWAYS CHECK ANY SERVER RELATED TO YOUR APPLICATION!!! Thank you very much :D
I want to develop a game in real time.
updated for all users on a picture every second. But I have no idea how to do, Is there something similar, i can use the sample code?
I'll use C# and Asp.NET
Note: Sorry for my bad english.
Try using SignalR, from what I can tell from your question, this would work well for doing game updates.
https://github.com/SignalR/SignalR
https://github.com/SignalR/SignalR/wiki/Getting-Started
If latency really matters then you should be looking at a WebSocket solution and not one introduces the overhead of requiring HTTP Requests. WebSockets support bi-directional communication between a client and server over a single connection which keeps latency to an absolute minimum. Other HTTP-based solutions, including EventSource, mean that data coming from the server to the client can be sent with low latency but messages from the server to the client have to be made by establishing a new HTTP request which introduces latency.
So, this means that ASP.NET is not a good choice for a truly realtime game at the moment.
What are the alternatives?
If you want to stay in the .NET world then I'd consider looking at XSockets or SuperWebSocket.
If you would consider other technology solutions then I've compiled a list of realtime web technology solutions. Again, when making a choice I'd favour solutions that have WebSocket support.
If you want to keep close to the Microsoft stack you could look at socket.io on Windows Azure. See Running Socket.io on Windows Azure Web and Worker Roles
If you would consider Node and a hosted service then the Pusher Pipe might be of interest for you.
From version 1.0 beta, the version just recently published on Nuget there is some changes regarding the XSockets Server (named XSocketsMaxiServr in prior version) , now its called XSockets.DevelopmentServer.Console.exe , and can be found in the XSockets\DevelopmentServer folder or the project where you install.
By just opening it from the "command prompt" the server starts, registers the WebSocketHandlers of yours. The examples that will be added during install, is located under XSockets\Examples.
We will update the documentation in just a few days, and i also know that Ulf , a team-member of XSockets just recently publised a new guide/video that can be found here:
http://xsockets.net/videos
The movie is called "XSockets.NET 1.0 RC1 - getting started" and im sure that i will be helpfull for you.
If you need any assistance don't hesitate to contact us, we will assist you as much as possible! You will find the correct contact information at the XSockets WebSite.
Kind regards, Magnus Thor, Team XSockets.NET
We have a very old windows forms application that communicates with the server using .net remoting.
Can anyone recommend a method or a tool to performance test this.
Last time I looked there were no good tools for performance testing a windows application with many users.
You can use a profiler to see what is going on if the single user case is too slow.
If you only are about a hand full of users, most UI test tools could be used to record a script that you played back on a few machines.
Otherwise you need to write a command line application that talks to the server in the same way as the windows forms app, and then run many copies of that command line app.
Or get the server to log all calls in such a way as the calls can be played back.
In the past I have thought about getting each client to log the calls to the sever in the form of C# statements that could then be compiled to create a performance test program.
There are some systems that claims to record the communication between the client and the sever at the network level, and then play it back many times. This may work if it is sensible for lot of clients to send the some requests with the same params to the server, otherwise there will be lots of scripting within the tool to create custom requests for each client.
To do performance testing on the application, you can use a profiler, such as the ANTS Performance Profiler. I'm not sure if that's going to profile the network communication as well or not.
Alternatively, you can set up performance counters and record information that way when you run your app.
I am making a medium sized standard LOB application. Currently its a web application but I am formulating a proposal to revamp it into a Desktop remote application. By this I mean that the database and the application server will be hosted in a remote location. The client application will communicate with the server via the internet through (either WCF / Webservices / Remoting).
My question is this: The only reason I am shifting this from a web platform is due to the constraints of the web (I dont want to do AJAX or Java scripting to minimize those constraints, so please no JS/AJAX recommendations). I have made traditional desktop applications and they are considerably fast but i have never made a remote or a distributed application. I am not sure weather the speed of the application will be faster then the web or not.
As I understand it, the remote desktop application would be much faster. For one, there wont be any post backs involved, (I hate them so much). The data will obviously come via internet, so in that respect, is it better to shift to the remote desktop just for sheer speed and power?
Any help in the right direction would be greatfull. Many thanks.
Zeeshan
I think biggest advantage of desktop clients over web applications is freedom in UI design, and you don't have to worry about any inconsistencies in the client environment, although those are not an issue if you are using a client that runs on silverlight.
Personally I don't like web applications that requires a lot of user interaction, there are some of them that is a pleasure to use but I think it is very easy to do it the wrong way and end up having a buggy or not so responsive application (probably because of the incompatibilities in browsers, I have IE, Firefox and Chrome installed on my computer and I use one for some websites because they run faster on it, and others for other sites because web pages show up correctly only on them). Though this might not be an issue for a silverlight client.
In case of network speed, depending on the things that goes on the wire even with binary serialization remoting might have quite a bit of overhead. For example along with the data it writes full class names, library names and their versions so it can get pretty big and slow even for small amounts of data (although it should still be smaller then HTTP). It also has the same problems that HTTP has over unreliable connections because it uses a similar protocol. For one project we had to write a custom serializer for some objects because binary serialization alone was generating 200K, but our custom serializer for those objects were generating 50K. Then we ended up writing our own network protocol because the one that comes with the runtime was frequently stalling over unreliable wireless networks, and remoting doesn't give any control on the socket created by it (which makes sense in terms of encapsulation but you can't close it and force it to open a new one).
(I am assuming that you are asking about remoting vs web app. not remote desktop vs. web apps, because of your note about post back, you can't avoid it with a remote desktop session)
Rewriting an application just for sheer speed? No, because probably user won't see much difference in response time.
You are somewhat ambiguous with your terminology - do you want a client app that runs on the user's machine, or do you want an app that runs on the server and the user connects via remote desktop (RDP)?
If you are talking about a client app that communicates to the server via WCF etc., then yes it will be faster than a standard web app, although it will still be slower than a native desktop app. It will be faster than the web app not just because of the lack of postbacks, but also because you will be sending pure data through the wire, not a massive amount of HTML/Javascript combined with your data. With a client app, you have several options so consider them carefully - do you want Silverlight, WPF, or a native WinForms app? Each have their positives and negatives.
If you were talking about having a client app running on the server which the user then access via RDP, then you have other considerations to think of. For any more than two concurrent users you will need to consider buying CALs so the users can connect to the server. At this point you should also be considering whether you should be running a terminal server or Citrix type setup instead of using remote desktop.
Edit
When using WCF over a WAN (internet) you will certainly have to consider how you will secure it. WCF makes it trivial to secure the channel, but you need to consider how you will do authentication - there are a couple of different ways, but you can easily google that stuff yourself. The method you choose will be important due to the limited resources or skill-sets of the users.
As for what you write it in, you can't argue with Winforms if that is where your experience is. Personally, i would never again use ASP.NET/Ajax/etc for a web type application, it would be WPF or Silverlight all the way (i would only use ASP.NET for simple web sites). You can use the express (free) versions of Visual Studio to write it in, you don't need Expression (it's just a nice to have, and is more aimed at the design side than the actual coding side). Deploying the app need not be difficult - Silverlight or WPF xbap are delivered via the web, the user has to do nothing (except for the simple install of the Silverlight plugin or installing the right .Net framework for WPF - check this link). Winforms or stand-alone WPF require slightly more work, but you can avoid most issues by writing a good installer.
Whichever you choose, make sure you don't under estimate the time for development (because you will have a bit of a learning curve), and also make sure you budget enough time for testing it - especially the security side of it :)
I have been in a similar situation, although started with a Winforms LOB application.
Heres what we found with WinForms...
It's going to be harder to deploy in your release cycle, to all client machines.
WinForms can't be run on other operating systems easily. (with the exception on mono)
WCF endpoints can get complicated, and you need to manage an endpoint for release/version of your application.
Authentication, Authorization and Security can be tricky to get right!
Heres why you should stick to a html web application.
it's going to be easier to deploy, as you just need to copy one set of DLL's into the bin folder. Can be scripted from a continuous integration or staging server.
Security is going to be easy, by using a SSL certificate.
Silverlight/Flash should fill in the gaps that HTML leaves out.
Microsoft has also combined the connected systems in .net 3.5, they now call it WCF (ASMX/Remoting/etc...). It's got quite a learning curve 4-5 weeks.