gevent_uwsgi use more cpu

[youyueyinfeng]

HI, I'm testing the performance between gevent_uwsgi and gevent. The test case is 5000 connection only send PING/PONG.

The result is that gevent_uwsgi use almost twice cpu than gevent. I modify the self._event.wait(timeout) in curious, and then gevent_uwsgi use almost same cpu as gevent.

def wait(self):
        """Waits and returns received messages.
        If running in compatibility mode for older uWSGI versions,
        it also sends messages that have been queued by send().
        A return value of None means that connection was closed.
        This must be called repeatedly. For uWSGI < 2.1.x it must
        be called from the main greenlet."""
        while True:
            if self._req_ctx is not None:
                try:
                    msg = uwsgi.websocket_recv(request_context=self._req_ctx)
                except IOError:  # connection closed
                    return None
                return self._decode_received(msg)
            else:
                # we wake up at least every 3 seconds to let uWSGI
                # do its ping/ponging
                # ---- HERE. I changed the timeout  -----
                event_set = self._event.wait(timeout=3*1000000)
                ....

The uwsgi version I used is 2.0.19.1, the latest version in pypip, which is also the latest version in uwsgi documentation. So the gevent_uwsgi will wake up every 3 seconds. The comment said that it wake up for uwsgi ping/pong. But I don't understand why engineio need do uwsgi ping/pong again, since it already did its ping/pong. Is it because the uwsgi default config websocket-ping-freq and websocket-pong-tolerance ?

[miguelgrinberg]

This code was contributed to the project many years ago. I do not use uwsgi and I'm not familiar with its internals, so I can't really answer your questions.

I fail to see how a timeout of 3 seconds can cause a big performance issue, however. Do you want to share your testing code so that I can try this myself?

[youyueyinfeng]

The test code in #228 can reproduce as well. When ALL_USER = 5000, the uwsgi process use 25% cpu shown by top. If changed the timeout to 3 * 100000, the process use 15% cpu.

[miguelgrinberg]

The code that you sent me to use is not a good benchmark. It has the following problems:

• You are running the server and the client on the same system, which makes it hard to separate the performance of one vs. the other.
• You are only evaluating performance of connection requests, which is not at all representative of the life of a Socket.IO connection.
• Your client test code does not actually check that a connection is made. By changing the timeout you are basically not paying attention to incoming events (which the current implementation tends to every 3 seconds). I haven't debugged your script, but I would imagine if there are incoming events and you are ignoring them that is a problem, don't you think? What use is to get better CPU if the incoming events on the websocket are not handled?

[youyueyinfeng]

• I runned the test code using two machine.
• Yeah, it just tests the performance dealing with free connections, which just need to send ping/pong. There's no affect in active connection case whether to change timeout or not.
• It's a simple test code. if client fails to connect, it will print traceback. In fact, all clients connect successfully.
• That's the point I want to learn. What incoming events refer to? Message sent from client using selector to catch. Message to send to client using send() to set event directly. In normal case, engineio business doesn't need to use timeout. Do you mean something like abnormal disconnection?

[miguelgrinberg]

That's the point I want to learn. What incoming events refer to?

Did you try debugging this code to see what those incoming events are? As I said, this was contributed to the project about 5 years ago, and I accepted it assuming the contributor knew what they were doing. I just confirmed that it works, but did not really do an in-depth analysis. If you find ways to improve this code I'm all for doing it.

[youyueyinfeng]

Well, it's hard to debug, since I didn't meet a case that need timeout. As I said, after changing timeout to 3*100000, all seem working well. Maybe it just wakes up to do uwsgi ping/pong as the comment says.

Perhaps the way to solve this or similar problem is engineio can support a custom async driver, so that user can write their own code without modifying the source. Anyway, thanks for communication.

[juneoh]

Similar to what we've been experiencing, possibly #296