Длинный опрос XHR для приложения чата (вместо сокетов)? - PullRequest
Новая
       64

Длинный опрос XHR для приложения чата (вместо сокетов)?

0 голосов
/ 22 апреля 2020

Мне нужно создать систему чата пользователя в реальном времени. Мне удалось создать простой скрипт AJAX / PHP / MySQL для чата, но меня беспокоит одна вещь в части PHP / MySQL: 

while(true) {
    // ...SELECT * FROM messages ORDER BY date DESC LIMIT 1...

    if($row['date'] > $_POST['last']) {
        echo json_encode($row);

        break;
    }

    sleep(1);
}

Не значит ли это, что она будет SELECT таблица каждую 1 секунду, и не перегрузит ли это сервер?

Я пытался использовать PHP сокеты, но это был кошмар. Мне пришлось купить SSL-сертификат, а также, когда сервер проходил тестирование со многими пользователями, я решил пока использовать систему длительного вытягивания. Если я правильно помню, Facebook использовал длинный опрос XHR перед переключением на сокеты (если они вообще переключались).

1 Ответ

0 голосов
/ 23 апреля 2020

Ну, ваш вопрос слишком обобщенный. Хотя это в основном зависит от нагрузки, которую вы получите, и особенностей вашего сервера, обычно не рекомендуется использовать длинные опросы.

В вашем вопросе сделаны определенные предположения, которые не совсем верны.

Мне пришлось купить сертификат SSL, а также

А вы? Насколько я знаю, есть бесплатные эмитенты сертификатов, такие как letsencrypt. Проблема здесь, возможно, вы используете общий хостинг с доступом только по FTP. Подумайте о получении VPS от какого-либо облачного провайдера, например DigitalOcean. Там у вас будет полный доступ к виртуальной среде. И большинство самых дешевых VPS имеют ту же цену, которую вы можете получить на общем хостинге.

Facebook использовал длинный опрос XHR перед переключением на сокеты

Да, они были и иногда они отступают к ним тоже. Но, прежде всего - у них много вычислительной мощности. Они могут позволить себе эти вещи. И, во-вторых, веб-чат facebook не самое быстрое приложение, которое я когда-либо использовал:)

-

С индексированными столбцами и несколькими записями в обычном MySQL единственном экземпляре вы не будете заметить какие-либо замедления. Когда данные растут, как и пользователи (одновременные подключения), вы постепенно обнаружите, что вам нужно оптимизировать вещи, и однажды вы в конечном итоге go окажете пользу WebSocket.

PHP в глубине души не должен быть асинхронным. Все асин c вещи вместе со всем событием l oop, которое вам нужно будет сделать самостоятельно или составить несколько фреймворков, чтобы прийти на помощь.

Я бы вообще предложил полную проприетарную реализацию WebSocket с асинхронное время выполнения. Вы либо посмотрите на Ratchet для PHP или используйте ws для Node.js.

...