i am working in a web application project which has .NET based Web 2.0-based features in GUI(means lot of AJAX calls) and axis1 based web services at business layer to serve data...
i see a performance issue in webservice protocol: SOAP/HTTP...since there is going to be lot of AJAX calls i.e. HTTP requests to web server..we may see frequent socket/connection time out issues in production...I want to know does any one have any prior experience in this kind of issue? Any idea how to rectify this?
I googled and found persistent HTTP Connections would improve it...but would like to know your views.
Here is my enviroment details:-
front end: .NET
backend:
tomcat 6.0
axis1
oracle10g
windows XP
Yes, persistent HTTP connections help to avoid creating new connections, and this is the first thing that comes to mind. Another way is to set socket timeout values on client/server sockets, increase backlog value on the server socket(s) (I'm not sure how to do it in Axis*).
Related
does somebody have any information how a HTTP OPTION is handled in ASP.NET.
We use the OPTION to healthcheck our system which is fast (around 1ms) but there are times where the response is too slow (2s) which triggers our healthcheck system. Any idea where to look for the reason? (IIS logs, ASP.NET Events etc.)
Thanks
Depends on which version of ASP.NET. But I would assume it is handled pretty similarly to all other HTTP requests. I think you may be experiencing some issues with a slow first start request on IIS.
First of all thanks for taking the time to read my question. Here is what I am trying to accomplish followed by what I have so far on this.
What I want to do is create a Windows application (or server of sorts) that would listen for requests from an ASP.NET application. The windows application would be installed and would listen for messages from ASP.NET application and then do some processing. The flow is like this:
A user downloads the desktop application and registers their IP address on my web site. After downloading the desktop app, the ASP.NET application can then send requests to that particular desktop client for further processing. I think further processing is independent of the resolution in this case that's why i have skipped over details on what processing would be done. But if you think it is important, please let me know and I will add those details as well.
I have looked into creating a TCP server that would listen for requests. Because the user has already registered their IP address on my web site, my web site assigns them a unique identifier and stores the ID alongwith IP address in database. Now, the ASP.NET site can send requests to that desktop application.
I have looked into creating a TCP server for this purpose. While researching I also came across PNRP and it seems something like what I am trying to do.
Can you guys recommend some solutions or where I should be looking at for this scenario? Should I create a simple TCPLISTENER or may be go with PNRP approach? Or something else?
The basic requirement is for a web application to be able to communicate with a desktop application. The web application would be servicing numerous users and each user would have a desktop application installed. Which user for which desktop client question would be addressed by the web application that would maintain a database of unique user id's and their corresponding IP Address.
Thanks in advance for your help.
You could use .NET remoting or a web-service in the desktop app. Use WCF or WSE for the latter. You can use COM to add windows firwall rules.
Whatever you do, take firewalling/NAT into account. It might be easier for the client application to poll the server (initiate the connection) otherwise you open a can of worms by trying to have a remotely-accessible server in your user's computer without having to do some very manual configurations on the user's networking equipment.
Once you have that part sorted out, what I used in your situation was .NET Remoting. At the time WCF had not come out and when it did it was to crippled for my needs. TCP IP sockets were too raw (I had to write too much code) and so Remoting solved my problem ideally (a hand full lines of code to set up the connection, and everything was automatic from there on).
EDIT: I use an excellent third party library that makes Remoting even more flexible (flexible enough that I am still waiting for WCF to catch up with the featureset so that I stop using Remoting, and no luck yet!). Check out http://www.genuinechannels.com/ to see all the features they have. It includes making calls from server to client, and that sounds exactly like what you need to do. Check it out.
Earlier on I've implemented a custom C++ server from scratch, something which is nice and fun to do but is very time-consuming.
So I've heard about "servlet" of Java which sounds like something I'm looking for for my next project.
I'm looking at ASP.NET to be used as a servlet because it's pretty much mature in terms of networking capabilities and programming features and I can write code for it in C# which is a language I already know and feels good with.
Anyway before getting into it I'd like to get concise answers regarding some of the capabilities that ASP.NET may provide me with.
My client application is Flash-based and has nothing to do with XML or HTTP protocols (raw sockets).
1) Can I accept raw (in terms of protocol) socket connections and keep them alive as long as needed?
2) How hard/complicated is it to apply AES encryption over a connected socket?
3) Can I have a "shared", in-memory, objects, like lists, over the application's instance?
4) Can I get one message from client X and send a copy/reply/report (on the fly) to client Y, without using a database or anything like that? This question suggests question #5.
5) Can I identify a connection by its memory address or object address, so I can refer to it directly?
6) Can my application be distributed over several servers?
7) How hard/complicated is it to scale such an application? For 10 concurrent connections there's no problem but for 50,000 I can surely expect load issues.
8) Finally, the most important question which probably has the most complex answer: How flexible is the environment from a programmer perspective? I mean, can I control events such as "on_connect", "on_disconnect" and stuff like that? How hard would it be to access connection Y from connection X's event (such as "on_data_received")?
ASP.Net is more like JSP than Java Servlets as it requires a web server to run. Typically IIS is used since Microsoft has built in ASP.Net support there, but it's possible to run ASP.Net on other web servers. As a web server product it's all HTTP and therefor connectionless. Based on your questions 1, 2, 4, 5 and 8 this may be a deal-killer for you.
If you can code your Flash application to manage itself with HTTP/HTTPS connections then using ASP.Net to build out web services that your app can use is a decent option. IIS is mature and can scale out nicely (q's 6 & 7). It also has an application-level store that you can use (q3). Of course each server in a farm would have its own copy.
It's possible to implement your own server in C# with a lot less effort than in C++, but it's still a time consuming endeavor. The TcpListener class in System.Net.Sockets would be the starting point if you chose to go that route.
I would go with Client/Server .NET application, not ASP.NET as it's out of its "scope".
Unless one of the demands is to have public website?
I've got an asp.net web page that is making 7 async requests to a WCF service on another server. Both boxes are clean without anything else installed.
I've also increased maxconnections in web.config to 20.
I run a single call through the system and the page returns in 800ms. The long and short of it is I think that the threadpool is being being overwhelmed as, once placed underload I cannot get more that 8 requests per second, even though both quad core boxes are running at 20% CPU load and the sql server it's connected to is returning the querys in under 10ms per call.
I've changed the service behaviour to concurrency.multiple but that's not seeming to help.
Any ideas anyone.
There are many different factors that could be in play here. Taking a stab at the remark that changing your instancing model on the service had zero effect (big IF here) then its possible the 'bottleneck' is upstream from the service. Either at the web server, or the client load generator.
You've got several areas to review for tuning: client, web server, wcf service server - that's assuming there are no network devices in the middle. Pick an end and work towards the other end. Since I'm already making an assumption that its not the service, then I'd start at the client and work my way towards the wcf service.
Client
What machine is driving the load against the web server? A laptop? A desktop? A dedicated test agent, or a shared one? The client acting as the load generator for purposes of this test is also susceptible to maxConnections limitation as this is a client setting.
What is the CPU utilization of the client generating load? Could it be that the test driver is just unable to generate enough load to push these boxes? Can you add additional test clients to your test?
Web Server
What does the system.net/processModel element look like in machine.config on the ASP.NET web server? Try setting autoConfig = true. This will allow the configuration to auto size based on the 'size' of the machine its running on.
WCF Service
Review WCF service for any throttling defaults that might be in play and tweak appropriately. See ServiceThrottlingBehavior on MSDN.
Let us know any changes in behavior you might observe (if any) if you make any changes!
The real answer here that everyone missed is that you're using an ASP.NET web page. That means your client is some form of web browser. Modern web browsers have a limit of 2 concurrent async requests at any time. This means that 5 of your requests were queued up and waiting for the first two to finish. Once those first two, it served the next two, then the next two, then the last one.
All of these round-trips and handshakes simply take time. I'm guessing that your roundtrip time is around 200ms, unfortunately you have to do it 4 times.
I also really dislike the "max 2" browser limitation on making webservice calls.
Is this service hosted in IIS, WAS or a Windows Service?
You should try to set Windows to run services on a higher priority. Your WCF Service is probably creating the threads it needs but they should be running at a low priority.
Hope that helps.
I am building an ASP.NET website which will collect data from a user and submit it to a 3rd party webservice. The webservice is somewhat unreliable and for this reason there is a backup service.
If a call to the primary service fails (timeout or some other error) then I need to flip a bit in a static class which will trip the system to use the secondary service.
At this point, I need to start polling the primary service (with dummy data) to see if it is back up (at which point I will receive an OK code in return). At this point I need to flip the bit back so that the website starts using the primary service again.
I've had a read of this Should I use a Windows Service or an ASP.NET Background Thread? and I think that separating out the code into a Windows Service would be the cleanest method of performing the polling, but then how would I communicate with the web appication.
One thought I've had is to expose a webservice that the Windows Service could use to communicate into the webapp but this seems both messy and over-kill.
I'd appreciate your thoughts and experiences performing similar tasks.
Thanks
I think the Windows service is the way to go, definitely.
As for the communication between the service and your web site, the best answer depends on the size and scale of your solution. If you are building something that needs to be reliable, I'd suggest you implement some sort of queue between your ASP.NET site and your Windows service. You have a lot of options here too, depending on budget and ability: BizTalk, MSMQ, and SQL Server queues (SSIS). Alternatively if you are looking for something smaller scale, I'd recommend you just stick it into a database table somewhere.
I would avoid using files on the file system because you will encounter issues with file locks and multithreading. I would also avoid directly communicating with the service because you risk losing the in-memory queue if the service fails for any reason.
Edited to add:
If reliability isn't a concern here, you could use a WPF named-pipes hosted service for communication between your website and your Windows service. This avoids much of the overheads normally involved in classic Web Services and is surprisingly quick. The only down-side is that self-hosting a WPF service is tricky and can be difficult to keep the service up.