php – 事件源的性能

我目前正在开发一个大项目,需要服务器发送的事件实现.我决定使用事件源传输,并从简单的聊天开始.目前,客户端仅侦听新的聊天消息事件,但项目将来会有更多事件.首先,我真的很关心服务器端脚本和循环,其次,我不确定使用MysqL 数据库作为存储(在这种情况下,用于聊天消息)实际上是一个很好的做法.
当前循环会在数据库中显示新消息：

$statement = $connect->prepare("SELECT id, event, user, message FROM chat WHERE id > :last_event_id");
while(TRUE) {
    try {
        $statement->execute(array(':last_event_id' => $lastEventId));
        $result = $statement->fetchAll();
        foreach($result as $row) {
            echo "id: " . $row['id'] . "\n";
            echo "event: " . $row['event'] . "\n";
            echo "data: |" . $row['user'] . "| >>> \n";
            echo "data: " . $row['message'] . "\n\n";
            $lastEventId++;
        }
    } catch(PDOException $PDOEX) {
        echo $PDOEX->getMessage();
    }
    ob_flush();
    flush();
    usleep(10000);
}

从我读到的这种循环是不可避免的,我的任务是优化它的性能.目前我在while()和合理(？)usleep()之外使用预准备语句.

那么,那些有服务器端事件经验的人的问题：

>这种技术是否合理地用于中等负载的网站(1000-5000用户在线)？
>如果是,有什么方法可以提高性能？
>在这种情况下,MysqL 数据库可能成为瓶颈吗？

感谢任何帮助,因为问题非常复杂,搜索信息不会给我任何提示或方法来测试它.

解决方法:

是否会同时连接所有1000个用户？你使用Apache与PHP？如果是这样,我认为你真正关心的是内存：每个用户都持有一个套接字,一个Apache进程和一个 PHP实例.对于你自己的设置,你需要自己测量,但如果我们说每个20MB,那就是1000个用户的20GB内存.如果你收紧东西,那么每个进程都是12MB,仍然是每1000个用户12GB. (一个m2.xlarge EC2实例有17GB的内存,所以如果你预算每500-1000个用户中的一个,我认为你会好的.)

相比之下,使用10秒的轮询时间,cpu使用率非常低.出于同样的原因,我不认为轮询MysqL DB会成为瓶颈,但在这个使用级别,我会考虑让每个DB写入也写入memcached.基本上,如果你不介意投入一些硬件,你的方法看起来是可行的.它不是最有效的内存使用,但如果你熟悉PHP,它可能是程序员时间最有效的使用.

更新：刚刚看到OP的评论,并意识到usleep(10000)是0.01s,而不是10s.哎呀！这改变了一切：

>你的cpu使用率现在很高！
>您需要在脚本顶部使用set_time_limit(0)：在严格限制下,您将很快达到默认的30秒cpu使用率.
>您应该使用通知队列服务,而不是轮询数据库.

我使用队列服务而不是memcached,你可以找到现成的东西,或者很容易在PHP中编写自定义的东西.您仍然可以将MysqL作为主数据库并让您的队列服务轮询MysqL;这里的区别是你只有一个进程密集地轮询它,而不是一千个.队列服务是一个简单的套接字服务器,它接受来自每个前端PHP脚本的连接.每次轮询发现新消息时,它都会将其广播到已连接到它的所有客户端. (有不同的方法来构建它,但我希望这能给你一般的想法.)

在前面的PHP脚本上,使用带有15秒超时的socket_select()调用.它只在没有数据时唤醒,所以在其余时间使用零cpu. (15秒超时是这样你可以发送SSE保持活动.)

(Source for the 20MB and 12MB figures)

php – 事件源的性能

相关推荐