I have created simple ASP.NET Web API(self-host OWIN) which has endpoint http://MyIp:80/process/file. It can accept only five simultaneous requests and takes about 30 seconds to proceed it, if requests number exceeded the Rest Api brings HTTP exception. To increase number of requests I am planning to host the ASP.NET Web API application on another server but in that case I will get different IP address for Rest Api. I know that there are load balancing solutions but can't find good source how to use it with ASP.NET Web API. Any advise would be appreciated!
The easiest way for you would be to use cloud. Especially for Microsoft technologies I would recommend Microsoft Azure. You will get scaling and load balancing out of the box as well as a lot of other benefits of using cloud.
This is a poor man's load balancing... bear with me.
You can declare one server as primary and the second one as secondary.
If a request hits the primary, but it is already with those 5 requests processing, it can issue a HTTP 307 Temporary Redirect to the secondary one. If the secondary is also overloaded, then throw an error.
Using a 307 temporary redirection, the caller knows that can retry the same HTTP verb to the new location. So if the caller was doing a POST call to the primary, and gets a HTTP 307 pointing to the secondary, will reissue the POST request to the secondary.
Related
I currently have my web application hosted on AWS, and I use two ELB instances, one to load balance the frontend requests to the app servers, and a second to load balance the backend requests FROM the app servers TO the API servers, like so (sorry for the crappy ascii diagram):
/-->APP1--\ /-->API1
User-->ELB1 ELB2
\-->APP2--/ \-->API2
In other words, the API requests that the APP servers make are load balanced evenly across the two backend API servers.
But, because I'm caching responses on the API servers, and use a cache invalidation mechanism which is NOT shared between the API servers, I'd like for a user's session to be stuck to one backend API server.
I already have the user's session stuck to one APP server, using the normal ELB load balancer-generated cookie stickiness, but is there any way to get the backend ELB stuck to a session? Of course, those requests are not coming from a browser, so there's nothing to manage cookies, and it seems that ELB's can only manage stickiness with cookies. Can I emulate the necessary cookies my backend requests?
To close off this question, yes, this is fairly easy to achieve by simply capturing the 'Set-Cookie' response header from the ELB, and then passing the cookie back in subsequent requests. But, see my caveat below.
I don't believe it would be possible to achieve stickiness between your App servers and API servers without doing a whole load of messy work. I could be wrong, and am very open to correction but I don't believe there is an easy solution, unless the language you're using for your App Server logic has something to offer.
Regardless, the best solution here would be to decouple your App Servers and your Cache. It would make more sense to have a single cache shared between the API servers that is served by separate servers. This will increase your infrastructure's fault tolerance and give you better quality data in your cache (especially as you scale up). You could use the ElastiCache service to do this for you and avoid any heavy lifting.
I just confused to distinguish between app server and web server.
as far as i know , web server handles user request , fetch from database and renders back to user and so on .
Now my question is what does a app server do in a web-application??
why it is useful to use app server along with web server ??
A Web server exclusively handles HTTP requests, whereas an application server serves business logic to application programs through any number of protocols.
An example
As an example, consider an online store that provides real-time pricing and availability information. Most likely, the site will provide a form with which you can choose a product. When you submit your query, the site performs a lookup and returns the results embedded within an HTML page. The site may implement this functionality in numerous ways. I'll show you one scenario that doesn't use an application server and another that does. Seeing how these scenarios differ will help you to see the application server's function.
Scenario 1: Web server without an application server
In the first scenario, a Web server alone provides the online store's functionality. The Web server takes your request, then passes it to a server-side program able to handle the request. The server-side program looks up the pricing information from a database or a flat file. Once retrieved, the server-side program uses the information to formulate the HTML response, then the Web server sends it back to your Web browser.
To summarize, a Web server simply processes HTTP requests by responding with HTML pages.
Scenario 2: Web server with an application server
Scenario 2 resembles Scenario 1 in that the Web server still delegates the response generation to a script. However, you can now put the business logic for the pricing lookup onto an application server. With that change, instead of the script knowing how to look up the data and formulate a response, the script can simply call the application server's lookup service. The script can then use the service's result when the script generates its HTML response.
In this scenario, the application server serves the business logic for looking up a product's pricing information. That functionality doesn't say anything about display or how the client must use the information. Instead, the client and application server send data back and forth. When a client calls the application server's lookup service, the service simply looks up the information and returns it to the client.
By separating the pricing logic from the HTML response-generating code, the pricing logic becomes far more reusable between applications. A second client, such as a cash register, could also call the same service as a clerk checks out a customer. In contrast, in Scenario 1 the pricing lookup service is not reusable because the information is embedded within the HTML page. To summarize, in Scenario 2's model, the Web server handles HTTP requests by replying with an HTML page while the application server serves application logic by processing pricing and availability requests.
Hope this is clear now!
My application consists of a 'gateway' DataSnap REST server that is the first point of access for all clients. Depending on the username the clients pass in their requests (basic authentication), the request needs to be redirected to another DataSnap server. My question - is there anyway of building the 'gateway' server so that it simply redirects whatever the request is to another server based on the username, or other values in the HTTP request headers? I'm trying to avoid having to repeat all the server methods in the 'gateway' service i.e. I'd rather not 'chain' 2 requests together but somehow just have 1 request redirected.
Not sure if this is possible, but thought somebody might prove me wrong? I'm using Delphi XE2 and the DataSnap servers are Windows services.
I can see two options here:
use the first server only to return the address of the real server after logging in
or
use a Apache or NGINX reverse proxy in front of the Datasnap servers and RewriteRules based on the authentication data (however my Google-Fu for today seems to be exhausted, maybe this can be placed as a HTTP / Apache specfifc question here on SO)
Short version: the solution will depend on which level (HTTP, DataSnap, in between) you know where to target the request to.
If you can make the decision on the DataSnap level, there are two kinds of solutions:
The purists way to do this is write a generic DataSnap gateway that can interrogate a datasnap target server, dynamically creates both a proxy server and client for it, then intercepts the traffic and decides which datasnap target server to hand over the request to.
A more pragmatic approach would be the one you are afraid of.
Another approach would be on the HTTP level. That will only work if you can determine at the HTTP level to which target server a request should be handed over to.
I have a ASP.NET MVC3 web application. To get data from third party, my application makes several HTTP requests from server. I want to see all the http requests made to the third party from server for each page loads. I have installed glimpse from nu-get package. but I could not see any remote HTTP calls made from server. I am debugging my application in my local machine. is it possible to get this information using glimpse? if not is there any other tool can help me out here?
Thanks!
Unfortunately, Glimpse does not currently show HTTP requests your application has made - but that sounds like a great feature!
You do have a few options:
Create a custom tab using Glimpse's extensibility model. You could tap into whatever HTTP client you are using and expose the data.
Additionally, you could leverage Glimpse's Trace Tab to trace out messages about your HTTP requests.
Finally, you could use ANTS Performance Profiler which recently added a feature to see all the HTTP requests an application makes, in addition to CPU level timing information and SQL queries. (And it has a free trial!)
I'm designing an API to enable remote clients to execute PowerShell scripts against a remote server.
To execute the commands effectively, the application needs to create a unique runspace for the remote client (so it can initialise the runspace with an appropriate host and command set for that client). Every time the client makes a request, the API will need to ensure the request is executed within the correct runspace.
An (over-simplified) view of the flow might look like this:
Client connects to Web API, POSTs credentials for the backend application
Web API passes these credentials through to the backend app, which uses them to create a RunSpace uniquely configured for that client
Web API and app "agree" on a linked session-runspace ID
Web API either informs client of session-runspace ID or holds it in memory
Client makes request: e.g. "GET http://myapiserver/api/backup-status/"
Web API passes request through to backend app function
Backend app returns results: e.g. "JSON {this is the current status of backup for user/client x}"
Web API passes these results through to remote client
Either timeout or logout request ends 'session' and RunSpace is disposed
(In reality, the PowerShell App might just be a custom controller/model within the Web API, or it could be an IIS snap-in or similar - I'm open to design suggestions here...).
My concern is, in order to create a unique RunSpace for each remote client, I need to give that client a unique "session" ID so the API can pass requests through to the app correctly. This feels like I'm breaking the stateless rule.
In truth, the API is still stateless, just the back-end app is not, but it does need to create a session (RunSpace) for each client and then dispose of the RunSpace after a timeout/end-session request.
QUESTIONS
Should I hack into the Authentication mechanism in ASP.NET MVC to spin-up the RunSpace?
Should I admit defeat and just hack up a session variable?
Is there a better SOA that I should consider? (Web API feels very neat and tidy for this though - particularly if I want to have web, mobile and what-have-you clients)
This feels like I'm breaking the stateless rule.
Your application is stateful - no way around it. You have to maintain a process for each client and the process has to run on one box and client always connecting to the same box. So if you have a single server, no problem. If you have multiple, you have to use sticky session so client always comes back to the same server (load balancers could do that for you).
Should I hack into the Authentication mechanism in ASP.NET MVC to
spin-up the RunSpace?
If you need authentication.
Should I admit defeat and just hack up a session variable?
No variable, just use plain in-memory session. In case more than 1 server, use sticky session as explained above.
Is there a better SOA that I should consider? (Web API feels very neat
and tidy for this though - particularly if I want to have web, mobile
and what-have-you clients)
SOA does not come into this. You have a single service.