I'm starting a personal project, so I have at the moment complete architectural/design control. I'm just planning out the structure at this point. My goal is some sort of web forum, chat thing. The difference is it should update live, new posts growing on client views soon after they've hit the server.
I think to use ajax and jquery to download a viewed thread's new posts (from a tomcat server), the posts will be some small XML structure that is compiled into a nice post on the client side. This hopefully reduces my bandwidth costs. Bandwidth is my primary concern. I'm worried that having a few users with a javascript thread polling the server every ten seconds will cause a storm of http requests to my server, even if the content is small.
Is there a better way than having each user perform polling? I can write the backend in any structure neccessary, frontend too for that matter. I want to stay away from Flash and Silverlight. As a public webpage it might end up with a lot of viewers (every web dev's deam). Having everyone polling at 30 second intervals will be an incredible number of hits to support, and 30 seconds is probably too slow for 'live view' anyway!
My preferred language is JSP.
Client side pooling is not the only option to implement "live view". You should consider, so called "Reverse AJAX" technique as well.
Furthermore you could use some of well established frameworks that provide you with that functionality out of the box: DWR or even JSF(ice faces).
Related
I am working on my first webapp project which I plan to publish using a remote server. I have a question about the architecture.
My webapp is to scrape tweets using twitterscraper Python package. A user who visits the website enters some keywords and click "Scrape" button. A Python backend scrapes the tweets containing the keywords, goes through some Natural Language Processing analysis, and visualise the result in charts. This twitterscraper package lets you scrape tweets using Beautiful Soup, therefore you don't need to create an API credential. The scraping speed depends on the bandwidth of the internet that you are using.
I made a Python script, JavaScript file, html file and css file. In my local environment the webapp works perfectly.
So the question is, after I put these files on the hosting server and publish the webapp, when a user clicks "Scrape" button, on what does the scraping speed depend? The bandwidth of the internet that the user is using? Or is there any "bandwidth" that the server is relying on?
As I said I am very new to this kind of architecture. So it would also be nice to suggest me an alternative way for structuring this kind of webapp. Thank you!
Where the bottle-neck is depends on a bunch of different variables.
If you're doing a lot of data manipulation, but you don't have a lot of CPU time allocated to the program (i.e. there are too many users for your processor to handle), it could slow down there.
If you don't have sufficient memory, and you're trying to parse and return a lot of data, it could slow down there.
Because you're also talking to Twitter, whatever the bandwidth restrictions are between your server and the twitter server will affect the speed at which you can retrieve results from their API, and so the time it takes your program to respond to a user.
There's also the connection between yourself and the user. If that's slow, it could affect your program.
What I am trying to build here looks something like this.
MyClients(Multiple) <------> Server(Me) <------> TheirClients(multiple, live)
MyClient1 (HTML)
Through Server (HTML -> Servlet -> Android)
HisClient1 (uses Android app)(monitored live by MyClient1)
HisClient2 (uses Android app)(monitored live by MyClient1)
...
...
The flow: (Can have multiple MyClients and HisClints online at the same time)
MyClient comes online.
Timely pinging HisClients get connected to the Server.
MyClient gets notified.
MyClient sends request to HisClient through server.
HisClient replies through Server.
MyClient is updated.
On the HisClient end i.e. Android, I'm running TCP Socket() to timely ping the server and stay alive. Cannot use URLConnection as the client have to stay alive all the time if the server requests something. Also I don't want to use any external library, so GCM is not an option.
On the MyClient side, I first tried using PHP but it is inefficient of handling multiple live clients. Then, after some searching I came to know that Servlets are good in such cases. So I started developing a Servlet.
Now the questions are:
Am I going in the right direction? I mean is there anything better for such a scenario? If yes, what and how? I mean what are the APIs and how will it maintain the live traffic?
If no, how do you handle multiple live HisClients with Servlet? I know, here multiple is not a problem but how to keep them live and keep updating MyClient?
Why are you going to spend so much time reinventing the wheel? Maintaining 100 connections with a web socket isn't hard. Maintaining 1,000,000 will be impossible. If you need an event system, use something like Amazon SNS or Pubnub to distribute events. Sure, you'll add a couple of Kbytes or MBytes to your app. But how will you know you can scale your solution?
Maintaining any kind of a connection will be just waiting for a scalability nightmare. Make things a bit less tightly coupled and you'll be much better off.
I'm creating a personal application which displays stock quotes realtime (updating every second), and I was wondering what was the best way to approach this project?
I'm going to query using Yahoo YQL: example query.
I've been researching WebSockets and sockets.io, but I don't believe you can use this unless you own the server with the data. Is this approach not possible?
Send an XMLHttpRequest every second? This seems really bad for some reason, just seeing all the requests in the developer tools makes me cringe and my laptop heat up.
Any thoughts? I've heard of people using an iframe or something to make the requests?
I cannot for the love of programming figure out how Google and Yahoo do it.
An IFRAME that updates each second would have similar effect than an AJAX request every second. Some pages uses an IFRAME that refresh each X time, but there is no magic there, an IFRAME is like another browser window inside the web page.
You are right about websockets, the server must expose a websocket endpoint, otherwise is not possible. If you have this option, go for it.
There is other push technology named "Server Sent Events" (aka SSE, Event Source): http://caniuse.com/eventsource Again the server must expose it, but it basically allows the client to keep a persistent connection to the server, and this push events to the client. Again if you have this option, and websocket is not available, go for it.
If you are not in control of the server, and the only provided option is regular HTTP calls, I guess you have no other option. Please mind that some trading providers limit the amount of requests you can do per minute, or limit the amount of times the information changes per minute, so maybe doing one per second your are not achieving anything relevant... or you can get yourself banned.
I'm pretty new to javascript and API's but I think a google or yahoo API (Application Programming Interface) would be appropriate to link the stock quotes to your app.
I'm already tossing around a solution but as I haven't done something like this before I wanted to check what SO thought before implementation.
Basically I need to modify an existing web based application that has approximately 20 users to add push notifications. It is important that the users get the notifications at the same time (PC-A shouldn't get an alert 20 seconds before PC-B). Currently the system works off of AJAX requests, sending to the server every 20 seconds and requesting any updates and completely rebuilding the table of data each time (even if data hasn't changed). This seems really sloppy so there's two methods I've come up with.
Don't break the connection from server-client. This idea I'm tossing around involves keeping the connection between server and client active the entire time. Bandwidth isn't really an issue with any solution as this is in an internal network for only approximately 20 people. With this solution the server could push Javascript to the client whenever there's an update and modify the table of data accordingly. Again, it's very important that every connected PC receives the updates as close to the same time as possible. The main drawback to this is my experience, I've never done it before so I'm not sure how well it'd work or if it's just generally a bad idea.
Continue with the AJAX request, but only respond in intervals. A second solution I've thought of would be to allow the clients to make AJAX requests as per usual (currently every 20 seconds) but have the server only respond in 30 second intervals (eg 2:00:00 and 2:00:30 regardless of how many AJAX requests it recieves in that span of time). This would require adjusting the timeout for the AJAX request to prevent the request timing out, but it sounds okay in theory, at least to me.
This is for an internal network only, so bandwidth isn't the primary concern, more so that the notification is received as close to each other as possible. I'm open to other ideas, those are just the two that I have thought of so far.
Edit
Primarily looking for pros and cons of each approach. DashK has another interesting approach but I'm wondering if anyone has experience with any of these methods and can attest to the strengths and weaknesses of each approach, or possibly another method.
If I understand well your needs I think you should take a look to Comet
Comet is a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it. Comet is an umbrella term, encompassing multiple techniques for achieving this interaction. All these methods rely on features included by default in browsers, such as JavaScript, rather than on non-default plugins.
The Comet approach differs from the original model of the web, in which a browser requests a complete web page at a time.
How about using an XMPP server to solve the problem?
Originally designed to be an Instant Messaging platform, XMPP is a messaging protocol that enables users in the system to exchange messages. (There's more to this - But let's keep it simple.)
Let's simplify the scenario a little bit. Imagine the following:
You're a system admin. When the system
has a problem, you need to let all the
employees, about 20 of them, know that
the system is down.
In the old days, every employee will
ask you, "Is the system up?" every
hour or so, and you'll response
passively. While this works, you are
overloaded - Not by fixing system
outage, but by 20 people asking for
system status every hour.
Now, AIM is invented! Since every
employee has access to AIM, you
thought, "Hey, how about having every
single one of them join a 'System
Status' chat room, and I'll just send
a message to the room when the system
is down (or is back)?" By doing so,
employees who are interested in
knowing system status will simply join
the 'System Status' room, and will be
notified of system status update.
Back to the problem we're trying to solve...
System admin = "System" who wants to notify the web app users.
Employees = Web app users who wants to receive notification.
System Status chat room = Still, system Status chat room
When web app user signs on to your web app, make the page automatically logs them onto the XMPP server, and join the system status chat room.
When system wants to notify the user, write code to logon to the XMPP server, join the chat room, and broadcast a message to the room.
By using XMPP, you don't have to worry about:
Setting up "Lasting connection" - Some open source XMPP server, eJabberd/OpenFire, has built-in support for BOSH, XMPP's implementation of the Comet model.
How the message is delivered
You however will need the following:
Find a Javascript library that can help you to logon to an XMPP server. (Just Google. There're a lot.)
Find a XMPP library for the server-side code. (XMPP library exists for both Java & C#. But I'm not sure what system you're using behind the scene.)
Manually provision each user on the XMPP server (Seems like you only have 20 people. That should be easy - However, if the group grows bigger, you may want to perform auto-provisioning - Which is achievable through client-side Javascript XMPP library.)
As far as long-lasting AJAX calls, this implementation is limited by the at-most-2-connection-to-the-same-domain issue. If you used up one connection for this XMPP call, you only have 1 more connection to perform other AJAX calls in the web-app. Depending on how complex your webapp is, this may or may not be desirable, since if 2 AJAX calls have already been made, any subsequent AJAX call will have to wait until one of the AJAX pipeline freed up, which may cause "slowness" on your app.
You can fix this by converting all AJAX calls into XMPP messages, and have a bot-like user on the server to listen to those messages, and response to it by, say, sending back HTML snippets/JSON objects with the data. This however might be too much for what you're trying to achieve.
Ahh. Hope this makes sense... or not. :p
See http://ajaxpatterns.org/HTTP_Streaming
It allows You to push data from the server when server wants it. Not just after the query.
You could use this technique without making large changes to the current application, and synchronize output by the time on the server.
In addition to the other two great options above, you could look at Web Workers if you know they have latest Chrome, Safari, FF, or Opera for a browser.
A Worker has the added benefit of not operating in the same thread as the rest of the page, so performance will be better. The downside is that, for security purposes, you can only send string data between the two scripts and the worker does not have window or document context. However, JSON can be represented as a string, so there's really no limit to the data.
Workers can receive data multiple times and asynchronously. You set the onmessage handler to act each time it receives something.
If you can ask every user to use a specific browser (Latest Safari or Chrome), you can try WebSockets too.
what they do on this demo is exactly what i wanna do.
http://www.lightstreamer.com/demo/RoundTripDemo/
i wonder what comet technique they are using.
it cant be iframe cause on Firefox i can open two tabs with same link. with iframe u cant do that. and it cant be long polling with ajax cause i didnt see it polled anything with firebug.
someone knows the answer? (would be great with some link to good tutorials that do exactly the same thing with same technique).
Whilst digging through the obfuscated scripts is not something I fancy right now, judging by the contents of the page DOM it is posting data from a <form> inside a hidden <iframe> to send data to the server, and having the server send back <script> tags with code to pass data back to the caller.
This is a rather heavyweight and obtrusive technique. It was the only way of doing in-page server communication in the days before XMLHttpRequest existed; I typically wouldn't use it today.
(I wish WebSocket would hurry up and get implemented, doing away with all the long-polling nastiness.)
Looks like several techniques developed by Lightstream which include "vanilla" comet. A brief excerpt from the Lightstreamer white paper:
Each Lightstreamer client typically opens a single permanent connection
with Lightstreamer Server, on which the push updates relating to an
arbitrary number of items, frames and windows travel by means of
multiplexing techniques.
The white paper and demos are very interesting...
Once I developed a module for the Lighttpd web server. The module implemented a Full Duplex Ajax technique, very similar to Comet. In my blog posts you'll find everything you need about FDAjax / Comet, JavaScript examples, problems with firewalls and anti-virus programs, etc.
Lighttpd project seems to be dead. As far I know there is a similar module for the popular nginx. However in future we'll use web sockets.
BTW I used few HTTP addresses (www1.example.com, www2.example.com, ...) to work around the browsers limit of max two IP concurrent connections to the same web server. www[n] were in fact resolved to the same IP address. In case of possible lockup, a browser was automatically redirected to the next www[n] address.