parse-сервер и длинный опрос - PullRequest
0 голосов
/ 05 сентября 2018

У меня есть клиент, у которого есть какое-то нестандартное оборудование с довольно ограниченными возможностями (если говорить о питании и подключении) и домашнее решение (IIS + SQL Server). Один из основных способов, которым эта установка работает с асинхронным типом связи, - вариант длинного опроса с разумным временем ожидания.

Я изучаю возможность переключения их серверного решения с помощью parse-server, и мне любопытно, есть ли у кого-либо опыт или понимание использования parse-server с запросами с длинным опросом. В частности, мне любопытно, возможно ли добиться длительного опроса с помощью облачного кода (я предполагаю, что это возможно) и является ли это жизнеспособным маршрутом с точки зрения ресурсов и производительности.

Я подозреваю, что все будет хорошо, если посмотреть на то, что другие писали об эффективности Node JS при проведении открытых соединений, но я бы хотел услышать от любого, кто знает об этом.

1 Ответ

0 голосов
/ 30 сентября 2018

Итак, я создал простой тест, чтобы увидеть, как parse-сервер обрабатывает длинные опросы. Я создал конечную точку облачного кода, которая оставляет соединение открытым в течение 30 секунд перед возвратом:

async function sleep(seconds) 
{
    var millisecondsToWait = seconds * 1000
    return new Promise(resolve => setTimeout(resolve, millisecondsToWait));
}

Parse.Cloud.define('test', async function (req) {
    await sleep(30)
    return 'Hi'
})

И я написал bash-скрипт, который запускает множество запросов в конечной точке цикла:

#!/bin/bash

for i in {0..200}
do
    curl -X POST -H 'X-Parse-Application-Id: myapp' -H 'X-Parse-REST-API-Key: someString' -H 'Content-Type: application/json' http://localhost:5050/parse/functions/test &
done

Результат показывает, что у parse-сервера нет проблем с длительным опросом. Использование ресурсов процессом узла существенно не изменилось во время теста.

Так что в маловероятном случае, если кто-нибудь окажется с такой потребностью в будущем, вы должны быть в безопасности.

...