[GH-ISSUE #217] OCR performance question #175

New issue

Closed

opened 2026-02-25 21:31:22 +03:00 by kerem · 3 comments

kerem commented

2026-02-25 21:31:22 +03:00

Owner

Originally created by @amo13 on GitHub (Nov 19, 2020).
Original GitHub issue: https://github.com/ciur/papermerge/issues/217

Originally assigned to: @ciur on GitHub.

I dropped a whole lot of documents into the papermerge inbox to initially fill my papermerge instance, maybe between 60 and 100. By reloading the inbox page I could see that the documents got digested in a matter of minutes. They all got added to the correct folders and got correctly tagged as set in the automations. All in all it went very well and very fast!
After some time, maybe a week or so, without adding documents, without really using papermerge, I dropped 16 more documents into the inbox. Those were of the same nature as the other ones before, same sender, same sort of content, same number of pages. But this time, it took ages for papermerge to actually digest them, move and tag them according to the automations.

On montag at 06:00, there were 13 documents left to be processed inside the inbox.
On tuesday at 10:30, there were still 6 left
On wednesday at 06:00, still 2 left to be processed.

During all that time, the cpu was running at 100% on each core, used up by tesseract.

Does this sound normal? What strikes me here is that on my initial drop of (many many more) documents, it went so fast to digest them and that it took ages to process the second (and much smaller) batch of documents. Thanks for sharing any thoughts on this!

Info:

OS: Arch Linux
CPU: Intel J4205
Database SQLite
Using Redis
Papermerge Version 1.5

Originally created by @amo13 on GitHub (Nov 19, 2020). Original GitHub issue: https://github.com/ciur/papermerge/issues/217 Originally assigned to: @ciur on GitHub. I dropped a whole lot of documents into the papermerge inbox to initially fill my papermerge instance, maybe between 60 and 100. By reloading the inbox page I could see that the documents got digested in a matter of minutes. They all got added to the correct folders and got correctly tagged as set in the automations. All in all it went very well and very fast! After some time, maybe a week or so, without adding documents, without really using papermerge, I dropped 16 more documents into the inbox. Those were of the same nature as the other ones before, same sender, same sort of content, same number of pages. But this time, it took ages for papermerge to actually digest them, move and tag them according to the automations. On montag at 06:00, there were 13 documents left to be processed inside the inbox. On tuesday at 10:30, there were still 6 left On wednesday at 06:00, still 2 left to be processed. During all that time, the cpu was running at 100% on each core, used up by tesseract. Does this sound normal? What strikes me here is that on my initial drop of (many many more) documents, it went so fast to digest them and that it took ages to process the second (and much smaller) batch of documents. Thanks for sharing any thoughts on this! **Info:** - OS: Arch Linux - CPU: Intel J4205 - Database SQLite - Using Redis - Papermerge Version 1.5

kerem

2026-02-25 21:31:22 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-25 21:31:22 +03:00

Author

Owner

@ciur commented on GitHub (Nov 20, 2020):

@amo13, can you please confirm that you use redis as message broker (I saw in description, but still..) ?
You can confirm that by checking if folder queue (in project directory) is empty.
Another way to double check that redis is doing the job - check that redis db is populated with jobs as documents are added.

@ciur commented on GitHub (Nov 20, 2020): @amo13, can you please confirm that you use redis as message broker (I saw in description, but still..) ? You can confirm that by checking if folder ``queue`` (in project directory) is empty. Another way to double check that redis is doing the job - check that redis db is populated with jobs as documents are added.

kerem commented

2026-02-25 21:31:22 +03:00

Author

Owner

@amo13 commented on GitHub (Nov 20, 2020):

Yes, I use redis as a message broker, just as described here.

There is only one file 2788761550_9e0db55e-91f9-44dc-aa14-a6499cfd3375.d1474b39-b45f-3f37-8c33-95dc25a30f7a.msg in my queue folder and it's from Nov. 11th, so I guess it's still from before the change to use redis.

With redis-cli monitor, I see a lot of these (around one per second, you can see the timestamps on the left):

1605859284.640895 [0 127.0.0.1:46986] "INFO"
1605859284.979793 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1"
1605859285.127574 [0 127.0.0.1:53592] "PUBLISH" "/0.celeryev/worker.heartbeat" "{\"body\": \"eyJob3N0bmFtZSI6ICJjZWxlcnlAbG9jYWxob3N0IiwgInV0Y29mZnNldCI6IDAsICJwaWQiOiAxNzkwMTcxLCAiY2xvY2siOiA2NTg4ODQsICJmcmVxIjogMi4wLCAiYWN0aXZlIjogMCwgInByb2Nlc3NlZCI6IDM0OTU3LCAibG9hZGF2ZyI6IFsxLjI2LCAxLjI4LCAxLjNdLCAic3dfaWRlbnQiOiAicHktY2VsZXJ5IiwgInN3X3ZlciI6ICI1LjAuMCIsICJzd19zeXMiOiAiTGludXgiLCAidGltZXN0YW1wIjogMTYwNTg1OTI4NS4xMjY1MjI1LCAidHlwZSI6ICJ3b3JrZXItaGVhcnRiZWF0In0=\", \"content-encoding\": \"utf-8\", \"content-type\": \"application/json\", \"headers\": {\"hostname\": \"celery@localhost\"}, \"properties\": {\"delivery_mode\": 1, \"delivery_info\": {\"exchange\": \"celeryev\", \"routing_key\": \"worker.heartbeat\"}, \"priority\": 0, \"body_encoding\": \"base64\", \"delivery_tag\": \"d70d9869-06a3-4585-9013-2d6e8f18f549\"}}"
1605859285.641144 [0 127.0.0.1:46986] "INFO"
1605859285.984043 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1"
1605859286.640219 [0 127.0.0.1:46986] "INFO"
1605859286.986099 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1"
1605859287.129791 [0 127.0.0.1:53592] "PUBLISH" "/0.celeryev/worker.heartbeat" "{\"body\": \"eyJob3N0bmFtZSI6ICJjZWxlcnlAbG9jYWxob3N0IiwgInV0Y29mZnNldCI6IDAsICJwaWQiOiAxNzkwMTcxLCAiY2xvY2siOiA2NTg4ODYsICJmcmVxIjogMi4wLCAiYWN0aXZlIjogMCwgInByb2Nlc3NlZCI6IDM0OTU3LCAibG9hZGF2ZyI6IFsxLjI0LCAxLjI4LCAxLjI5XSwgInN3X2lkZW50IjogInB5LWNlbGVyeSIsICJzd192ZXIiOiAiNS4wLjAiLCAic3dfc3lzIjogIkxpbnV4IiwgInRpbWVzdGFtcCI6IDE2MDU4NTkyODcuMTI4ODI2LCAidHlwZSI6ICJ3b3JrZXItaGVhcnRiZWF0In0=\", \"content-encoding\": \"utf-8\", \"content-type\": \"application/json\", \"headers\": {\"hostname\": \"celery@localhost\"}, \"properties\": {\"delivery_mode\": 1, \"delivery_info\": {\"exchange\": \"celeryev\", \"routing_key\": \"worker.heartbeat\"}, \"priority\": 0, \"body_encoding\": \"base64\", \"delivery_tag\": \"7cc73bb4-0546-4383-8c3d-0439f5e91a56\"}}"
1605859287.644848 [0 127.0.0.1:46986] "INFO"
1605859287.989608 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1"
1605859288.641108 [0 127.0.0.1:46986] "INFO"
1605859288.992903 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1"
1605859289.132515 [0 127.0.0.1:53592] "PUBLISH" "/0.celeryev/worker.heartbeat" "{\"body\": \"eyJob3N0bmFtZSI6ICJjZWxlcnlAbG9jYWxob3N0IiwgInV0Y29mZnNldCI6IDAsICJwaWQiOiAxNzkwMTcxLCAiY2xvY2siOiA2NTg4ODgsICJmcmVxIjogMi4wLCAiYWN0aXZlIjogMCwgInByb2Nlc3NlZCI6IDM0OTU3LCAibG9hZGF2ZyI6IFsxLjI0LCAxLjI4LCAxLjI5XSwgInN3X2lkZW50IjogInB5LWNlbGVyeSIsICJzd192ZXIiOiAiNS4wLjAiLCAic3dfc3lzIjogIkxpbnV4IiwgInRpbWVzdGFtcCI6IDE2MDU4NTkyODkuMTMxNjE3NSwgInR5cGUiOiAid29ya2VyLWhlYXJ0YmVhdCJ9\", \"content-encoding\": \"utf-8\", \"content-type\": \"application/json\", \"headers\": {\"hostname\": \"celery@localhost\"}, \"properties\": {\"delivery_mode\": 1, \"delivery_info\": {\"exchange\": \"celeryev\", \"routing_key\": \"worker.heartbeat\"}, \"priority\": 0, \"body_encoding\": \"base64\", \"delivery_tag\": \"efb512c2-36dc-445a-96f6-2f3d91d3a1ca\"}}"
1605859289.640535 [0 127.0.0.1:46986] "INFO"
1605859289.996195 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1"
1605859290.640982 [0 127.0.0.1:46986] "INFO"
1605859290.997795 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1"
1605859291.135484 [0 127.0.0.1:53592] "PUBLISH" "/0.celeryev/worker.heartbeat" "{\"body\": \"eyJob3N0bmFtZSI6ICJjZWxlcnlAbG9jYWxob3N0IiwgInV0Y29mZnNldCI6IDAsICJwaWQiOiAxNzkwMTcxLCAiY2xvY2siOiA2NTg4OTAsICJmcmVxIjogMi4wLCAiYWN0aXZlIjogMCwgInByb2Nlc3NlZCI6IDM0OTU3LCAibG9hZGF2ZyI6IFsxLjIyLCAxLjI3LCAxLjI5XSwgInN3X2lkZW50IjogInB5LWNlbGVyeSIsICJzd192ZXIiOiAiNS4wLjAiLCAic3dfc3lzIjogIkxpbnV4IiwgInRpbWVzdGFtcCI6IDE2MDU4NTkyOTEuMTM0NTE1OCwgInR5cGUiOiAid29ya2VyLWhlYXJ0YmVhdCJ9\", \"content-encoding\": \"utf-8\", \"content-type\": \"application/json\", \"headers\": {\"hostname\": \"celery@localhost\"}, \"properties\": {\"delivery_mode\": 1, \"delivery_info\": {\"exchange\": \"celeryev\", \"routing_key\": \"worker.heartbeat\"}, \"priority\": 0, \"body_encoding\": \"base64\", \"delivery_tag\": \"e3730d41-d9ea-4c8d-91dc-c47c246d88fb\"}}"
1605859291.641637 [0 127.0.0.1:46986] "INFO"
1605859292.002464 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1"
1605859292.640716 [0 127.0.0.1:46986] "INFO"
1605859293.004677 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1"
1605859293.109021 [0 127.0.0.1:53572] "SET" "unacked_mutex" "9ac13ea62b0611eb91357085c22c40d8" "PX" "300000" "NX"
1605859293.109568 [0 127.0.0.1:53572] "ZREVRANGEBYSCORE" "unacked_index" "1605855693.1084867" "0" "WITHSCORES"
1605859293.110096 [0 127.0.0.1:53572] "EVALSHA" "c3f8721cbb97f72bc19e972846bd7aaf91901658" "1" "unacked_mutex" "9ac13ea62b0611eb91357085c22c40d8"
1605859293.110201 [0 lua] "get" "unacked_mutex"
1605859293.110219 [0 lua] "del" "unacked_mutex"
1605859293.138120 [0 127.0.0.1:53592] "PUBLISH" "/0.celeryev/worker.heartbeat" "{\"body\": \"eyJob3N0bmFtZSI6ICJjZWxlcnlAbG9jYWxob3N0IiwgInV0Y29mZnNldCI6IDAsICJwaWQiOiAxNzkwMTcxLCAiY2xvY2siOiA2NTg4OTIsICJmcmVxIjogMi4wLCAiYWN0aXZlIjogMCwgInByb2Nlc3NlZCI6IDM0OTU3LCAibG9hZGF2ZyI6IFsxLjIyLCAxLjI3LCAxLjI5XSwgInN3X2lkZW50IjogInB5LWNlbGVyeSIsICJzd192ZXIiOiAiNS4wLjAiLCAic3dfc3lzIjogIkxpbnV4IiwgInRpbWVzdGFtcCI6IDE2MDU4NTkyOTMuMTM3MTA5NSwgInR5cGUiOiAid29ya2VyLWhlYXJ0YmVhdCJ9\", \"content-encoding\": \"utf-8\", \"content-type\": \"application/json\", \"headers\": {\"hostname\": \"celery@localhost\"}, \"properties\": {\"delivery_mode\": 1, \"delivery_info\": {\"exchange\": \"celeryev\", \"routing_key\": \"worker.heartbeat\"}, \"priority\": 0, \"body_encoding\": \"base64\", \"delivery_tag\": \"5a63873c-6f2a-49f9-902e-e09bed8099f1\"}}"

After dropping a document into the inbox (using the web-ui), I was not able to see anything more than those heartbeats in the redis monitor. (Maybe I just missed it, I can't be so sure since there is a constant message flood with nextcloud adding a lot more message flood, and it might take ages again the the one document to finish processing. Maybe something would appear in the redis monitor upon OCR end?) The queue folder didn't change either though.
redis-cli INFO | grep ^db shows me only one db, which should be my nextcloud instance. (But I don't really know how redis works and what that means)

@amo13 commented on GitHub (Nov 20, 2020): Yes, I use redis as a message broker, just as described [here](https://github.com/ciur/papermerge/issues/198#issuecomment-717712591). There is only one file `2788761550_9e0db55e-91f9-44dc-aa14-a6499cfd3375.d1474b39-b45f-3f37-8c33-95dc25a30f7a.msg` in my queue folder and it's from Nov. 11th, so I guess it's still from before the change to use redis. With `redis-cli monitor`, I see a lot of these (around one per second, you can see the timestamps on the left): ``` 1605859284.640895 [0 127.0.0.1:46986] "INFO" 1605859284.979793 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1" 1605859285.127574 [0 127.0.0.1:53592] "PUBLISH" "/0.celeryev/worker.heartbeat" "{\"body\": \"eyJob3N0bmFtZSI6ICJjZWxlcnlAbG9jYWxob3N0IiwgInV0Y29mZnNldCI6IDAsICJwaWQiOiAxNzkwMTcxLCAiY2xvY2siOiA2NTg4ODQsICJmcmVxIjogMi4wLCAiYWN0aXZlIjogMCwgInByb2Nlc3NlZCI6IDM0OTU3LCAibG9hZGF2ZyI6IFsxLjI2LCAxLjI4LCAxLjNdLCAic3dfaWRlbnQiOiAicHktY2VsZXJ5IiwgInN3X3ZlciI6ICI1LjAuMCIsICJzd19zeXMiOiAiTGludXgiLCAidGltZXN0YW1wIjogMTYwNTg1OTI4NS4xMjY1MjI1LCAidHlwZSI6ICJ3b3JrZXItaGVhcnRiZWF0In0=\", \"content-encoding\": \"utf-8\", \"content-type\": \"application/json\", \"headers\": {\"hostname\": \"celery@localhost\"}, \"properties\": {\"delivery_mode\": 1, \"delivery_info\": {\"exchange\": \"celeryev\", \"routing_key\": \"worker.heartbeat\"}, \"priority\": 0, \"body_encoding\": \"base64\", \"delivery_tag\": \"d70d9869-06a3-4585-9013-2d6e8f18f549\"}}" 1605859285.641144 [0 127.0.0.1:46986] "INFO" 1605859285.984043 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1" 1605859286.640219 [0 127.0.0.1:46986] "INFO" 1605859286.986099 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1" 1605859287.129791 [0 127.0.0.1:53592] "PUBLISH" "/0.celeryev/worker.heartbeat" "{\"body\": \"eyJob3N0bmFtZSI6ICJjZWxlcnlAbG9jYWxob3N0IiwgInV0Y29mZnNldCI6IDAsICJwaWQiOiAxNzkwMTcxLCAiY2xvY2siOiA2NTg4ODYsICJmcmVxIjogMi4wLCAiYWN0aXZlIjogMCwgInByb2Nlc3NlZCI6IDM0OTU3LCAibG9hZGF2ZyI6IFsxLjI0LCAxLjI4LCAxLjI5XSwgInN3X2lkZW50IjogInB5LWNlbGVyeSIsICJzd192ZXIiOiAiNS4wLjAiLCAic3dfc3lzIjogIkxpbnV4IiwgInRpbWVzdGFtcCI6IDE2MDU4NTkyODcuMTI4ODI2LCAidHlwZSI6ICJ3b3JrZXItaGVhcnRiZWF0In0=\", \"content-encoding\": \"utf-8\", \"content-type\": \"application/json\", \"headers\": {\"hostname\": \"celery@localhost\"}, \"properties\": {\"delivery_mode\": 1, \"delivery_info\": {\"exchange\": \"celeryev\", \"routing_key\": \"worker.heartbeat\"}, \"priority\": 0, \"body_encoding\": \"base64\", \"delivery_tag\": \"7cc73bb4-0546-4383-8c3d-0439f5e91a56\"}}" 1605859287.644848 [0 127.0.0.1:46986] "INFO" 1605859287.989608 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1" 1605859288.641108 [0 127.0.0.1:46986] "INFO" 1605859288.992903 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1" 1605859289.132515 [0 127.0.0.1:53592] "PUBLISH" "/0.celeryev/worker.heartbeat" "{\"body\": \"eyJob3N0bmFtZSI6ICJjZWxlcnlAbG9jYWxob3N0IiwgInV0Y29mZnNldCI6IDAsICJwaWQiOiAxNzkwMTcxLCAiY2xvY2siOiA2NTg4ODgsICJmcmVxIjogMi4wLCAiYWN0aXZlIjogMCwgInByb2Nlc3NlZCI6IDM0OTU3LCAibG9hZGF2ZyI6IFsxLjI0LCAxLjI4LCAxLjI5XSwgInN3X2lkZW50IjogInB5LWNlbGVyeSIsICJzd192ZXIiOiAiNS4wLjAiLCAic3dfc3lzIjogIkxpbnV4IiwgInRpbWVzdGFtcCI6IDE2MDU4NTkyODkuMTMxNjE3NSwgInR5cGUiOiAid29ya2VyLWhlYXJ0YmVhdCJ9\", \"content-encoding\": \"utf-8\", \"content-type\": \"application/json\", \"headers\": {\"hostname\": \"celery@localhost\"}, \"properties\": {\"delivery_mode\": 1, \"delivery_info\": {\"exchange\": \"celeryev\", \"routing_key\": \"worker.heartbeat\"}, \"priority\": 0, \"body_encoding\": \"base64\", \"delivery_tag\": \"efb512c2-36dc-445a-96f6-2f3d91d3a1ca\"}}" 1605859289.640535 [0 127.0.0.1:46986] "INFO" 1605859289.996195 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1" 1605859290.640982 [0 127.0.0.1:46986] "INFO" 1605859290.997795 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1" 1605859291.135484 [0 127.0.0.1:53592] "PUBLISH" "/0.celeryev/worker.heartbeat" "{\"body\": \"eyJob3N0bmFtZSI6ICJjZWxlcnlAbG9jYWxob3N0IiwgInV0Y29mZnNldCI6IDAsICJwaWQiOiAxNzkwMTcxLCAiY2xvY2siOiA2NTg4OTAsICJmcmVxIjogMi4wLCAiYWN0aXZlIjogMCwgInByb2Nlc3NlZCI6IDM0OTU3LCAibG9hZGF2ZyI6IFsxLjIyLCAxLjI3LCAxLjI5XSwgInN3X2lkZW50IjogInB5LWNlbGVyeSIsICJzd192ZXIiOiAiNS4wLjAiLCAic3dfc3lzIjogIkxpbnV4IiwgInRpbWVzdGFtcCI6IDE2MDU4NTkyOTEuMTM0NTE1OCwgInR5cGUiOiAid29ya2VyLWhlYXJ0YmVhdCJ9\", \"content-encoding\": \"utf-8\", \"content-type\": \"application/json\", \"headers\": {\"hostname\": \"celery@localhost\"}, \"properties\": {\"delivery_mode\": 1, \"delivery_info\": {\"exchange\": \"celeryev\", \"routing_key\": \"worker.heartbeat\"}, \"priority\": 0, \"body_encoding\": \"base64\", \"delivery_tag\": \"e3730d41-d9ea-4c8d-91dc-c47c246d88fb\"}}" 1605859291.641637 [0 127.0.0.1:46986] "INFO" 1605859292.002464 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1" 1605859292.640716 [0 127.0.0.1:46986] "INFO" 1605859293.004677 [0 127.0.0.1:53570] "BRPOP" "celery" "celery\x06\x163" "celery\x06\x166" "celery\x06\x169" "1" 1605859293.109021 [0 127.0.0.1:53572] "SET" "unacked_mutex" "9ac13ea62b0611eb91357085c22c40d8" "PX" "300000" "NX" 1605859293.109568 [0 127.0.0.1:53572] "ZREVRANGEBYSCORE" "unacked_index" "1605855693.1084867" "0" "WITHSCORES" 1605859293.110096 [0 127.0.0.1:53572] "EVALSHA" "c3f8721cbb97f72bc19e972846bd7aaf91901658" "1" "unacked_mutex" "9ac13ea62b0611eb91357085c22c40d8" 1605859293.110201 [0 lua] "get" "unacked_mutex" 1605859293.110219 [0 lua] "del" "unacked_mutex" 1605859293.138120 [0 127.0.0.1:53592] "PUBLISH" "/0.celeryev/worker.heartbeat" "{\"body\": \"eyJob3N0bmFtZSI6ICJjZWxlcnlAbG9jYWxob3N0IiwgInV0Y29mZnNldCI6IDAsICJwaWQiOiAxNzkwMTcxLCAiY2xvY2siOiA2NTg4OTIsICJmcmVxIjogMi4wLCAiYWN0aXZlIjogMCwgInByb2Nlc3NlZCI6IDM0OTU3LCAibG9hZGF2ZyI6IFsxLjIyLCAxLjI3LCAxLjI5XSwgInN3X2lkZW50IjogInB5LWNlbGVyeSIsICJzd192ZXIiOiAiNS4wLjAiLCAic3dfc3lzIjogIkxpbnV4IiwgInRpbWVzdGFtcCI6IDE2MDU4NTkyOTMuMTM3MTA5NSwgInR5cGUiOiAid29ya2VyLWhlYXJ0YmVhdCJ9\", \"content-encoding\": \"utf-8\", \"content-type\": \"application/json\", \"headers\": {\"hostname\": \"celery@localhost\"}, \"properties\": {\"delivery_mode\": 1, \"delivery_info\": {\"exchange\": \"celeryev\", \"routing_key\": \"worker.heartbeat\"}, \"priority\": 0, \"body_encoding\": \"base64\", \"delivery_tag\": \"5a63873c-6f2a-49f9-902e-e09bed8099f1\"}}" ``` After dropping a document into the inbox (using the web-ui), I was not able to see anything more than those heartbeats in the redis monitor. (Maybe I just missed it, I can't be so sure since there is a constant message flood with nextcloud adding a lot more message flood, and it might take ages again the the one document to finish processing. Maybe something would appear in the redis monitor upon OCR end?) The `queue` folder didn't change either though. `redis-cli INFO | grep ^db` shows me only one db, which should be my nextcloud instance. (But I don't really know how redis works and what that means)

kerem commented

2026-02-25 21:31:22 +03:00

Author

Owner

@amo13 commented on GitHub (Dec 11, 2020):

I am not quite sure why, but currently, without having changed anything, the OCR of newly dropped documents into the inbox is again fast as lightning. I am closing this for now, since it seems to be unclear why it slowed down so horribly in the first place as described above. I will come back to this if I notice another massive slowdown without apparent reason...

@amo13 commented on GitHub (Dec 11, 2020): I am not quite sure why, but currently, without having changed anything, the OCR of newly dropped documents into the inbox is again fast as lightning. I am closing this for now, since it seems to be unclear why it slowed down so horribly in the first place as described above. I will come back to this if I notice another massive slowdown without apparent reason...