在连续Ajax请求的性能问题？ [英] Performance issue in continous ajax requests?

问题描述

我创建了一个ajax的聊天应用程序是这样的检查和放大器;得到消息的每一秒。并能正常工作。

I created a ajax chat application something like this to check & get messages every second. and it works fine.

  function get_messages(user_id) {
    $.ajax({
      type    : "POST",
      url     : "messages/get_messages", 
      cache   : false,
      data    : {
        user_id : user_id 
      },
      success : function(data) {
        if(data != '') {
          var obj = $.parseJSON(data);
          var messages = obj.messages;
        }
      }
    });
    setTimeout(function() { get_messages(user_id) }, 1000);
  }

我的问题是，当很多人用这个应用了很多Ajax请求到服务器的每一秒，没有任何性能问题或服务器问题，在做这样的。什么是这样做？最好的做法

My question is, When lot of people use this application a lot to Ajax requests to server every second, is there any performance issue or server issue in doing like this, . What is the best practice for doing this ??

感谢您的宝贵建议：）

推荐答案

做这样的聊天是具有聊天窗口最好的办法正确地说，作为一个＆LT; IFRAME＆GT; 有一个脚本，该脚本将继续运行，并喂以新邮件客户端，所以你不必使用AJAX请求淹没服务器的永久连接。这可以通过调用来实现一个使用ob_flush（）（只是为了确保）和的flush（）印刷新的东西后， ，导致客户端立即接收的更新。但首先你得prepare在PHP中做一些设置正确的行为：

The best way to do chats like this is having the "chat window" properly said as an <iframe> with a permanent connection to a script that will remain running and feeding the client with the new messages so you don't have to overwhelm the server with AJAX requests. This can be achieved by calling a ob_flush() (just to make sure) and flush() after printing new stuff, causing the client to receive the updates immediately. But first you have to prepare the PHP to behave properly by doing some settings:

ini_set('zlib.output_compression', 'off');
ini_set('output_buffering', 'off');
set_time_limit(0);

如果你要使用会话，别忘了会话锁定为prevent并发写入，所以从 $搜集你所需要的信息后，_ SESSION 您必须使用 session_write_close（）释放会话否则用户将无法发帖等。

If you are going to use sessions, don't forget sessions are locked to prevent concurrent writes, so after gathering the information you need from $_SESSION you must release the session by using session_write_close() otherwise the user will be unable to post messages etc.

您脚本还应该检查活动和输出的东西给客户，如果在聊天窗口保持空闲时间超过两分钟。它prevents被终止由浏览器的连接。它不必是任何视觉，一些评论像＆LT;！ - 永葆 - ＆GT; 将尽

Your script should also check for inactivity and output something to the client if the chat window remain idle for more than a couple minutes. It prevents the connection from being terminated by the browser. It doesn't have to be anything visual, something commented like <!-- keep alive --> will do.

现在，在那里你会从中获取新的信息？有这样做，一对夫妇的选择：

Now, where you gonna get the new messages from? There are a couple options for doing that:

1. 套接字。你可以在服务器端运行此聊天服务器的应用程序，所有的聊天窗口PHP脚本将连接到要与新的聊天线路供电。当用户提交一个新的消息，其发送到聊天服务器，并将其传播到聊天窗口脚本。这个聊天服务器可以安全地用PHP写的呢！

1. Sockets. You can have this Chat Server application running in server-side that all the Chat Window PHP scripts will connect to to be fed with the new chat lines. When a user submit a new message, its sent to the Chat Server and it broadcast to the Chat Window scripts. This Chat Server can safely be written in PHP too!

一个文件。最简单的方法。每个聊天窗口PHP脚本为只读，而 fseek的（）到结束打开同一个文件。循环检查，如果它的！的feof（）每秒几次来读取它的新的生产线，如果theres任何。当用户发送新邮件，你只需追加此消息，文件和把戏完成。

A file. The easiest way. Every Chat Window PHP script open this same file for read-only, and fseek() to its end. Loops checking if its !feof() a couple times per second to read the new lines from it, if theres any. When a user send a new message you just have append this message to the file and the trick is done.

SQL。不建议，因为每一个聊天窗口PHP脚本将打开到RDBMS新的连接，最终将达到它的极限，但你可以尝试SQLite的不使用RDBMS。

SQL. Not recommended because every Chat Window PHP script will open a new connection to the RDBMS and eventually will reach its limit, but you can try SQLite that don't use RDBMS.

这篇关于在连续Ajax请求的性能问题？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！