search

swisspost / vertx-redisques

A highly scalable redis-persistent queuing system for vertx
Other
13 stars 8 forks source link

HTTP API very slow #213

Closed mcweba closed 1 month ago

mcweba commented 3 months ago

The /queuing/monitor and /queuing/statistics HTTP API endpoints in newer vertx-redisques versions are really slow. The other endpoints like /queuing/queues or /queuing/locks are fast in the newer versions too. Check the two compared versions below:

3.0.31

curl -o /dev/null  -s -w "Response Time: %{time_total}s\n"  http://localhost:7018/queuing/monitor
Response Time: 0.006s

4.1.2

curl -o /dev/null  -s -w "Response Time: %{time_total}s\n"  http://localhost:7018/queuing/monitor
Response Time: 0.780s

This is around 130 times slower in the new version. One thing related could be that newer versions have more output. See:

{
    "queues": [
        {
            "name": "nemo-to-dormakaba-v2",
            "size": 151,
            "lastDequeueAttempt": "",
            "lastDequeueSuccess": "",
            "nextDequeueDueTimestamp": ""
        },
        {
            "name": "edds-delivery",
            "size": 50,
            "lastDequeueAttempt": "",
            "lastDequeueSuccess": "",
            "nextDequeueDueTimestamp": ""
        },
        {
            "name": "edds-deliveryEvent-kafka-fwd",
            "size": 17,
            "lastDequeueAttempt": "",
            "lastDequeueSuccess": "",
            "nextDequeueDueTimestamp": ""
        }
    ]
}

The output of the older versions is:

{
    "queues": [
        {
            "name": "nemo-to-dormakaba-v2",
            "size": 3010
        },
        {
            "name": "edds-delivery",
            "size": 111
        },
        {
            "name": "edds-sisy-signatureEvent-kafka-fwd",
            "size": 59
        }
    ]
}
hiddenalpha commented 3 months ago

Maybe related?

mcweba commented 3 months ago

QueueStatistics can be disabled by configuration. In this case I would also expect the API to not collect/process this data. Therefore the response times should be as fast as before

mcweba commented 1 month ago

Fixed in v4.1.3