Jump to content

Recommended Posts

I would like to add an AJAX function to my page, that would go and grab information every 15-30 seconds, this code would return information, such as new messages, comments, and other things.

 

Would this be too hard on the server and/or database if there is say 500+ people viewing the page at the same time?

Link to comment
https://forums.phpfreaks.com/topic/104568-ajax-every-15-seconds/
Share on other sites

I've some bad experiences with this in the past.  For example I wrote an auction website where the auction pages would refresh the bids every second for all the items.  Turns out if enough people on the same IP had this page open then my host (1and1) gave them a temp ban for too many queries too fast.  It may have been that my code was optimized for it properly, but you never know.  Just something to watch out for.

you could use javascript setTimeout() function.

 

There is a better function for this,

setIntervol();

 

Chris

 

I know how to do it, I just would like to know if it would be a good Idea or not.

Would it chew up bandwidth like mad? basically it will go to the server, and do about ~5 queries, then return 2 hidden fields for each query made.

 

Doesn't Gmail do this and update you with new emails?

Yes they do, and the yahoo mail beta heavily uses ajax as well.

 

Lots of applications have to do things like this like ajax chat, dynamic server side tickers, etc. If you take the things your asking about into consideration, your going to be fine.

 

I like setTimeout since it's easier to degrade the timing.

 

Keep a count of all the times setTimeout is called so that you can know how long it's been since the user has been idle on a single page. If it's been over a certain time, you can assume that their Probably idle, so you reduce your ajax procedure interval to occur a bit less often, then after the next 10 or so calls, reduce a bit more, then finally after 10 more simply don't call setTimeout again so you can save your bandwidth that the user is unknowingly wasting by walking away from their machine.

 

Make sense?

 

Firebug extension for firefox is awesome for debugging your ajax in case you haven't heard of it yet.

Doesn't Gmail do this and update you with new emails?

 

No, gmail uses a push server of some kind. Basically the process works like this:

 

1) Client requests webpage where a small flash file is loaded.

2) The flash file establishes a connection with a socket server.

3) Once the connection is established the client is assigned a unique id (e.g. session id)

4) If a new email is received the data is sent to the socket server and then sent to the flash file connected via xml socket.

5) I use AS3 so I would use ExternalInterface to call a javascript function to display the new data.

 

IMHO, this is the best route for high load sites. This would cut the server load down considerably and doesn't require thousands of requests per second. I have worked on/with a ruby project called juggernaut that does exactly this. This could be done with php but, from what I have seen, php is not really a good language for socket servers. They are pretty intense on the system resources. Juggernaut uses eventmachine which is c based but with ruby wrappers.

tomfmason, Google may use a flash applet to connect to the server, but if you believe state is gained without using the user's browser at all, your wrong. Launch firebug and watch gmail request for new data at given intervals. Then, don't interact with that page for a while and watch the request's slow down. They're using a stateless protocol just like the rest of us and have to ask if new data is available. most of my sitiuations like this, I'd only as for new data from the once every 4-5 seconds, so where you get 1000's of requests per second...I have no idea.

so where you get 1000's of requests per second...I have no idea.

 

Say you have 500 users online and are sending a request every 5 seconds. That is 12 requests per minute per user or a total of 6000 requests per minute. 360,000 requests per hour in that situation seems like a lot but... I guess I could be wrong. Just as an example say each request is a total transfer of 500bytes(0.5kb) that would be 3mb per minute, 180mb per hour and  4.3gb transfer per 24 hour period. For a high load site that little request every 5 seconds could get very expensive. Not to mention the added strain on the server from all of the extra requests.  Maybe "thousands per second" was a bit of an over exaggeration but not by much.

Your absolutely right. I misinterpreted in my own brain thinking that you meant, 1 client would be sending thousands of requests.

 

Gmail still has to request data at certain intervals, and in order to conserve unused bandwidth from idle clients, they "gracefully degrade" their javascript to lengthen or stop their request intervals from idle users. Whether or not their using xmlhttprequest object, or some sort of actionscript is up to them as the user, just as it is up to us in our applications.

 

Just open up firebug and watch the requests...gmail doesn't only talk to the server when an event happens with their actionscript, a request is made to detect the event (new email, contact just logged in, etc..)

  • 2 weeks later...

OK, I decided to do one part every 60 seconds, that is less work on my/our server.

 

But now I need/want to know the best way to do a chat. Would sending a request to the server every one second be a valid way to set an online chat with one other person?  What if I wanted to chat with 2, or 3 or 4 (one on one), sending a request to the server every one second to make it fairly close to real time would be a load on the server. Is there a better way to do it, maybe like a direct connection between the two, where I could skip the server all together (doubt that is possible)?

Just throwing an idea out there but maybe using IRC wouldn't hurt.

 

I found this little tutorial on a simple IRC Connection in PHP

Surely it's enough to spark an idea or epiphany that could possibly work.

http://codingforums.com/showthread.php?t=91765

 

I'm very new to the IRC Connection/PHP thing so I'm no expert on it.

But I'm sure IRC would be faster than reading MYSQL over and over

I've played around with ajax chat a bit, but I don't really have a working solution that I'm happy with.

 

This is gonna be buggy and once you get in the code it should be overly dirty, yet as simple as I could keep it.

 

I had planned on cleaning it up, fixing the bugs and then posting, but here it is...

 

http://linardy.com/chat/

 

I still haven't even taken my own advice to slow down the setTimeout calls when a user has been idle for a certain amount of time. If I were you, I'd move the setTimeout function call to the callback function and do a bit of work to determine how long until the next call. The more amount of time since the user's last action, the longer the Interval. If they've been idle way too long for your taste...provide some sort of feedback letting them know they've timed out with a link or something to get back and dont set the next interval to happen until the user provides some sort of action (post, refresh, js_link, etc...)

 

I haven't touched the code for a couple months and was just waiting for a bit more time to fool around with it. consider it lgpl and do whatever you want with it.

 

good luck!

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.