QJsondocument slowness when hooked up to a QSlider

[jsulm]

@Kris-Revi OK, watched once more - yes, there is one change at the end of the video. It should work with QNetwork & QJsonDocument.
Can you post your current code?

[Kris Revi]

@jsulm

class software(QtWidgets.QMainWindow):
    def __init__(self, parent=None):
        QtWidgets.QWidget.__init__(self, parent)
        self.ui = Ui_MainWindow()
        self.ui.setupUi(self)
        self.ui.Brightnessslider.valueChanged.connect(self.adjustBrightness)

        self.nam = QtNetwork.QNetworkAccessManager()

    def doPost(self, toUrl, tojson):
        try:
            print(tojson)
            document = QJsonDocument(tojson)

            request = QtNetwork.QNetworkRequest(QtCore.QUrl(toUrl))
            request.setHeader(QtNetwork.QNetworkRequest.ContentTypeHeader, "application/json; charset=UTF-8")

            self.nam.post(request, document.toJson())
        except Exception as e:
            print(e)

    def adjustBrightness(self):
        self.doPost(f"{self.boardURL}/ledBrightness", {'brightness': self.ui.Brightnessslider.value()})

[SGaist]

One thing comes to mind: QNAM handles up to 6 requests in parallel and then queues the other ones to be execute as soon as possible. requests as well as httplib2 do not have that kind of consideration as they are not asynchronous therefore I think that what you might be observing might be related to architectural differences.

[Kris Revi]

@SGaist and sadly there is nothing i can do there? :/ nothing i can turn off or adjust?

[mrjj]

@Kris-Revi
Hi
As far as i know, you cannot alter the limit of 6.

[Christian Ehrlicher]

I'm pretty sure that's not a problem of QNAM but somewhere else. Maybe the device does not answer fast enough or so so that QNAM is waiting for the response very long.

[Kris Revi]

@Christian-Ehrlicher sadly it is QNAM! when using "requests", "httplib2" or "urllib3" it is INSTANT response! no queue or waiting!

[mrjj]

@Kris-Revi
And the other end uses the same parsing and reaction code regards less of you using
httplib2 or NAM ?
So the only difference is the sending?

[Kris Revi]

@mrjj exactly!

[mrjj]

@Kris-Revi
Well its very likely SGaist is right and what you see is related to architectural differences.
NAM is async so pr request it will have a slight delay before actually sending compared to
a lib which is blocking and sends at once.
That said its normally very fast and even the slider will generate heaps of
signals, it should fast catch up if parsing is fast enough.

If you limit your sending to 6 outstanding, does it then react almost as fast ?

i mean something like.
self.doPost(f"{self.boardURL}/ledBrightness", {'brightness': 10})
self.doPost(f"{self.boardURL}/ledBrightness", {'brightness': 20})
self.doPost(f"{self.boardURL}/ledBrightness", {'brightness': 30})
self.doPost(f"{self.boardURL}/ledBrightness", {'brightness': 40})
self.doPost(f"{self.boardURL}/ledBrightness", {'brightness': 50})
self.doPost(f"{self.boardURL}/ledBrightness", {'brightness': 60})

[Christian Ehrlicher]

You must be something doing very wrong:

static int s_requestFinishedCount = 0;
static const int s_maxRequests = 100;

int main(int argc, char *argv[])
{
    QCoreApplication app(argc, argv);
    QElapsedTimer timer;
    timer.start();
    QNetworkAccessManager nam;
    QNetworkRequest req(QUrl::fromUserInput("http://192.168.178.200/"));
    for (int i = 0; i < s_maxRequests; ++i)
    {
      QNetworkReply *reply = nam.get(req);
      QObject::connect(reply, &QNetworkReply::finished,
                       reply, []()
      {
        qDebug() << "s_requestFinishedCount:" << s_requestFinishedCount;
        if (++s_requestFinishedCount == s_maxRequests)
          QCoreApplication::quit();
      });
      QObject::connect(reply, &QNetworkReply::finished,
                       reply, &QNetworkReply::deleteLater);
    }
    int ret =app.exec();
    qDebug() << "Elapsed:" << timer.elapsed() << ", ret: " << ret;

    return ret;
}

--> 580ms

shell:

date
for start in {1..100};
do
  wget -nv http://192.168.178.200 2>&1 > /dev/null
done
date

--> 11 seconds

The ip is a raspi 1 delivering a very small website

[Kris Revi]

@mrjj sadly it looks like if i can't controll / adjust / remove the queue system from QNAM im stuck using either "requests", "httplib2" or "urllib3" as they are instant :/ i can't have that queue system it takes ages befor the brightness levels of the LED's are where the slider is set to :/

[kshegunov]

@Kris-Revi said in QJsondocument slowness when hooked up to a QSlider:

@mrjj sadly it looks like if i can't controll / adjust / remove the queue system from QNAM im stuck using either "requests", "httplib2" or "urllib3" as they are instant :/ i can't have that queue system it takes ages befor the brightness levels of the LED's are where the slider is set to :/

I'm pretty sure with QNAM you're flooding the device sending near 10 times the payload (i.e. you're DoS-ing your device). What you can and should do instead is to disentangle the slider from the communication and buffer the slider's events instead of flushing them directly through the network. That is you introduce a timer that ticks every 200ms or so (which is below the typical reaction time of a human anyway), and send a message to the device if the slider's value has changed in the meantime. In Qt this'd look something like this:

QObject::connect(slider, &QAbstractSlider::valueChanged, controller, &ControllerClass::setValue);
QObject::connect(timer, &QTimer::timeout, controller, &ControllerClass::sendNetworkData);

where all the slots and signals do the obvious - the ControllerClass::setValue just saves the new value and if it's different from the previous raises an internal dirty state. ControllerClass::sendNetworkData checks if the state is dirty, and if so, sends the new data and resets the flag.