I'm fairly new to C# but have experience with C++.
I'm looking to write a web service, that I can call from a website to pull hotel rates similar to rate comparison websites. My question is; what is the best method to be able to deal with the concurrent loads and allow the data requests to run in the background whilst updating the user interface.
Basically I've all the code ready and to pull the XML data from the likes of Booking.com, on a single per user basis.
But want to change this way of working, to allow me to send off requests to say 10 suppliers at once, and then in the background the web service works to get the rates.
The front end, will then refresh to get the latest data.
Any help or advice would be appreciated.
Related
I need a function on my website so that it can update the sports data, for example, the result of a sports game in real time. I have seen some websites do that, but I don't know how to monitoring those data. Any suggestions or help?
There are 4 possible approaches for displaying real-time data on website:
Refresh page at periodic intervals
Obsolete method. Not recommended for modern apps.
AJAX calls from browser to pull data at periodic intervals
This is the most popular method used currently by many websites
Can be done with least development effort.
3. Websocket
Modern method. Used extensively in financial services domain.
Good for bi-directional communication between client and server.
Adds an unnecessary overhead for simple updates by server (Example: match score)
4. SSE (Server-Sent-Events)
Most modern of all methods. Quickly gaining adoption.
Least overhead.
Most preferred for near real-time update from server to client.
More information on SSE:
https://developers.facebook.com/docs/graph-api/server-sent-events/
Say I have a scatter gather setup like this:
1) Web app
2) RabbitMQ
3) Scatter gather API 1
4) Scatter gather API 2
5) Scatter gather API x
Say each scatter gather (and any new ones added in future) need to supply an image/update an image to the web app, so that when the web app displays the results on screen it also displays the image. What is the best way to do this?
1) RESTFUL call from each API to web app adding/updating an image where necessary
2) Use message queue to send the image
I believe option two is best because I am using a microservices architecture. However, this would mean that the image could be processed by the web app after requests are made (if competiting consumers are used). Therefore the image could be missing from the webpage?
The problem with option 1 is the scatter gatherer apis are tightly coupled with the web app.
What is the appropriate way to approach this?
The short answer: There is no right way to do this.
The long answer: Because there's no right way to do this, there a danger that any answer I give you will be an opinion. Rather than do that, I'm going to help clarify the ramifications of each option you've proposed.
First thing to note: Unless there is already an image available at the time of the HTTP request, then your HTTP response will not be able to include an image. This means that your front-end will need to be updated after the HTTP request/response cycle has concluded. There are two ways to do this: polling via AJAX requests, or pushing via sockets.
The advantage of polling is that it is probably easier to integrate into an existing web app. The advantage of pushing the image to the client via sockets is that the client won't need to spam your server with polling requests.
Second thing to note: Reporting back the image from the scatter/gather workers could happen either via an HTTP endpoint, or via the message queue, as you suggest.
The advantage of the HTTP endpoint is that it would likely be simpler to setup. The advantage of the message queue is that the worker would not have to wait for the the HTTP response (which could take a while if you're writing a large image file to disk) before moving on to the next job.
One more thing to note: If you choose to use an HTTP endpoint to create/update the images, it is possible that multiple scatter/gather workers will be trying to do this at the same time. You'll need to handle this to prevent multiple workers from trying to write to the same file at the same time. You could handle this by using a mutex to lock the file while one process is writing to it. If you choose to use a message queue, you'll have several options for dealing with this: you could use a mutex, or you could use a FIFO queue that guarantees the order of execution, or you could limit the number of workers on the queue to one, to prevent concurrency.
I do have experience with a similar system. My team and I chose to use a message queue. It worked well for us, given our constraints. But, ultimately, you'll need to decide which will work better for you given your constraints.
EDIT
The constraints we considered in choosing a message queue over HTTP included:
Not wanting to add private endpoints to a public facing web app
Not wanting to hold up a worker to wait on an HTTP request/response
Not wanting to make synchronous that which was asynchronous
There may have been other reasons. Those are the ones I remember off the top of my head.
I wonder how to update fast numbers on a website.
I have a machine that generates a lot of output, and I need to show it on line. However my problem is the update frequency is high, and therefore I am not sure how to handle it.
It would be nice to show the last N numbers, say ten. The numbers are updated at 30Hz. That might be too much for the human eye, but the human eye is only for control here.
I wonder how to do this. A page reload would keep the browser continuously loading a page, and for a web page something more then just these numbers would need to be shown.
I might generate a raw web engine that writes the number to a page over a specific IP address and port number, but even then I wonder whether this page reloading would be too slow, giving a strange experience to the users.
How should I deal with such an extreme update rate of data on a website? Usually websites are not like that.
In the tags for this question I named the languages that I understand. In the end I will probably write in C#.
a) WebSockets in conjuction with ajax to update only parts of the site would work, disadvantage: the clients infrastructure (proxies) must support those (which is currently not the case 99% of time).
b) With existing infrastructure the approach is Long Polling. You make an XmlHttpRequest using javascript. In case no data is present, the request is blocked on server side for say 5 to 10 seconds. In case data is avaiable, you immediately answer the request. The client then immediately sends a new request. I managed to get >500 updates per second using java client connecting via proxy, http to a webserver (real time stock data displayed).
You need to bundle several updates with each request in order to get enough throughput.
You don't have to use a page reload. You can use WebSockets to establish an open two-way communication between a browser (via JavaScript) and your server.
Python Tornado has support for this built-in. Additionally, there are a couple of other Python servers that support it. Socket.IO is a great JavaScript library, with fallback, to facilitate the client side.
On the backend you can use Redis or a NewSQL database like VoltDB for fast in-memory database updates. Caching helps a lot with high latency components (esp. in a write heavy application).
On the front-end you can look into websockets and the Comet web application model http://en.wikipedia.org/wiki/Comet_%28programming%29
Many gaming companies have to deal with fast counter updates and displays - it might be worth looking into. Zynga uses a protocol call AMF http://highscalability.com/blog/2010/3/10/how-farmville-scales-the-follow-up.html
I am struggling with a C# Website design concept.
Say I have a the need for an application that increments an integer continuously all day (simple representation of any continuous long running process). I need to write a website that would allow me (and other users) to log on, view the current value, ideally witness it updating, possibly interact with it by, say, resetting it, and then log off, leaving the process running.
Can I write this as one website, or would I have to write a website to serve pages and separate application to do the continuous work?
Personally I would have the "work" be some kind of Windows Service that can be interacted with (through database state, or directly through some transport mechanism, WCF, Message Queue, whatever). The website would then just talk to the existing service and do what it needs to do (get status, update etc).
You could have one webpage as there would be no need to serve multiple pages. The page could read the counter value from internal memory, a database or a web service which is continuously updating (Maybe add an AjaxUpdate Panel to show it ticking up). You could then code a function such as ResetCounter() which would connect to the database / web service and reset the count.
Is there a problem with storing the integer in an ACID compliant database, like SQL Server? Then you can interact with a web application you build, right? Seems to be the ideal way of handling a shared object like this integer value. ACID compliance means the integer will survive a hardware failure pretty well, you can log activities about who is tweaking the integer, etc. Writing your own service that keeps the value in shared memory probably doesn't offer a huge advantage compared to transacting with a database.
There are a couple of routes you could take. I would separate this into 3 different roles:
State Management: This layers simply stores the state of the counter or work. Determine what type of data store will be used (such as SQL Server)
Worker: This layer is the 'worker' role, responsible for incrementing the counter or whatever work needs to be done. This could be a Windows Service as others have posted, but I would probably opt for Windows Workflow exposed as a WCF Service. It would be much easier to manage the 'worker' this way and offers a more scalable solution.
UI: The next layer would the actual website, such as an ASP.NET MVC application, which could subscribe to the service and make various method calls.
See Workflow Services: http://msdn.microsoft.com/en-us/library/dd456797
I'm currently in the process of building an ASP.NET MVC web application in c#.
I want to make sure that this application is built so that it can scale out in the future without the need for major re-factoring.
I'm quite keen on using some sort of queue to post any writes to my database base to and have a process which polls that queue asynchronously to perform the update. Once this data has been posted back to the database the client then needs to be updated with the new information. The implication here being that the process to write the data back to the database could take a short while based on business rules executing on the server.
My question is what would be the best way to handle the update from the client\browser perspective.
I'm thinking along the lines of posting the data back to the server and adding it to the queue and immediately sending a response to the client then polling at some frequency to get the updated data. Any best practices or patterns on this would be appreciated.
Also in terms of reading data from the database would you suggest using any particular techniques or would reading straight from db be sufficient given my scenario.
Update
Thought I'd post an update on this as it's been a while. We've actually ended up using Windows Azure but the solution is applicable to other platforms.
What we've ended up doing is using the Windows Azure Queue to post messages\commands to. This is a very quick process and returns immediately. We then have a worker role which processes these messages on another thread. This allows us to minimize any db writes\updates on the web role in theory allowing us to scale more easily.
We handle informing the user via emails or even silently depending on the type of data we are dealing with.
Not sure if this helps but why dont you have an auto refresh on the page every 30 seconds for example. This is sometimes how news feeds work on sports websites, saying the page will be updated every x minutes.
<meta http-equiv="refresh" content="120;url=index.aspx">
Why not let the user manually poll the status of the request? This is how your typical e-commerce app is implemented. When you purchase something online, the order is submitted to a queue for fullfillment. After it's submitted, the user is presented with a "Thank you for your order" page and a link where they can check the status of the order. The user can visit the link anytime to check the status, no need for an auto-poll mechanism.
Is your scenario so different from this?
Sorry in my previous answer I might have misunderstood. I was talking of a "queue" as something stored in a SQL DB, but it seems on reading your post again you are may be talking about a separate message queueing component like MSMQ or JMS?
I would never put a message queue in the front end, between a user and backend SQL DB. Queues are good for scaling across time, which is suitable between backend components, where variances in processing times are acceptable (e.g. order fulfillment)... when dealing with users, this variance is usually not acceptable.
While I don't know if I agree with the logic of why, I do know that something like jQuery is going to make your life a LOT easier. I would suggest making a RESTful web API that your client-side code consumes. For example, you want to post a new order to the system and have the client responsive? Make a post to www.mystore.com/order/create and have that return the new URI to access the order (i.e. order#) as a URI (www.mystore.com/order/1234). That response is then stored in the client code and a jQuery call is setup to poll for a response or stop polling on an error.
For further reading check out this Wikipedia article on the concept of REST.
Additionally you might consider the Reactive Extensions for .NET and within that check out the RxJS sub-project which has some pretty slick ways of handling with the polling problem without causing you to write the polling code yourself. Fun things to play with!
Maybe you can add a "pending transactions" area to the UI. When you queue a transaction, add it to the user's "pending transactions" list.
When it completes, show that in the user's "pending transactions" list the next time they request a new page.
You can make a completed transaction stay listed until the user clicks on it, or for a predetermined length of time.