I'm trying to create a simple script for geting notifications from mysql using jQuery and PHP(my code is below). At the moment jquery gets loadmore.php every second and updates the div that contains it. I was just wondering if this might put too much pressure on the server if the site would get heavy traffic?
source code: index.php -
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Untitled Document</title>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/
libs/jquery/1.3.0/jquery.min.js"></script>
<script type="text/javascript">
var auto_refresh = setInterval(
function ()
{
$('#notifications').load('loadmore.php');
}, 1000); // refresh every 10000 milliseconds
</script>
<body>
<div id="notifications"> </div>
</body>
</html>
loadmore.php -
<?php
include('config.php');
?>
<?php
$sql=mysql_query("select * from updates ORDER BY item_id DESC LIMIT 9");
while($row=mysql_fetch_array($sql))
{
$msg_id=$row['item_id'];
$message=$row['开发者_运维百科item_content'];
?>
<?php echo $message; ?><br />
<?php } ?>
If every user with a page open is requesting loadmore.php every second, you'll quickly bring the server to its knees (assuming you have more than a couple users). Think of it this way: if the average user clicks a link every minute or two, you're increasing server load by 60-120 times.
You're much better off using XMLHttpRequest
from AJAX to load dynamic content. You shouldn't need to make a call every second to get responsive updates, no matter what technology you decide to use.
If you decide to do this, here are a couple ideas to make it a little less server intensive.
- Only return new messages. Most of the time, your update ping is going to be a 0 byte response, so that will cut down on traffic quite a bit. Use jQuery to limit the UI to 9 messages and append the new messages.
- Cache the db results. It looks like the update messages would be the same to every user, so instead of making a DB call for every single update request, save the results and only allow 1 db query per second.
If you must do this every second (even though like others, I would advise you against making a call to the server that frequently), look into something like Memcached or APC to make the request trivial in nature. Do not hit the database on every request, serve it straight from the cache if possible.
Also, check out Long Polling and Node.JS that would allow something more realtime to be built.
Imagine this -
One hit every second per user 1000 active users is equal to 1000 hits/second + all other traffic
I would say that would kill most servers. If you plan on that, you'll need a robust solution to handle that kind of traffic.
Read the answers... and then I thought how much it requires to process trafic to facebook. Or any other website with that kind of attendance. Of course, you will have to handle the trafic properly, but it is NOT AT ALL a problem in itself. It is NORMAL, and it all depends on two basic factors: 1) how many users you actually plan to serve and 2) how powerful your server is
精彩评论