# Kubo versions \> 0.15.0 gateway and slow IPNS performance

**URL:** <https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012>\
**Category:** Help\
**Tags:** go-ipfs, ipns, http-gateway\
**Created:** [February 20, 2023, 11:07pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012 "2023-02-20T23:07:25Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![eth-limo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/eth-limo/32/7456_2.png) [@eth-limo](https://discuss.ipfs.tech/u/eth-limo)\
**Post date:** [February 20, 2023, 11:07pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/1 "2023-02-20T23:07:25Z")

</div>

Hello IPFS community,

We’re testing Kubo upgrades in our dev environment. When upgrading to anything above v0.15.0 we’ve noticed that gateway requests for IPNS names now take anywhere from 3-4m to resolve. Rolling back to v0.15.0 resolves the issue.

In the [release notes](https://github.com/ipfs/kubo/releases#-hardened-ipns-record-verification) for v0.16.0 and above, Kubo now ignores IPNS v1 signatures and is only compatible with v2:

```auto
Records that do not have a valid IPNS V2 signature, or exceed the max size
limit, will no longer pass verification, and will be ignored by Kubo when
resolving /ipns/{libp2p-key} content paths.

```

Could this be related to the slow performance we’re seeing with newer versions of Kubo?

The slow behavior can be re-created by running Kubo \> 0.15.0 with the following:

```plaintext
$ ipfs config --json DNS.Resolvers '{"eth.": "https://dns.eth.limo/dns-query"}'

# Slow IPNS example: /ipns/k51qzi5uqu5dmjnxaa3ed22c0a6xaoyw5d75uacizdpc4u9rmxnqialvwat8y9/
$ time curl http://localhost:8080/ipns/simple.eth/ -s -o /dev/null

real	3m0.025s
user	0m0.021s
sys	0m0.010s

# Working IPFS example: /ipfs/bafybeighxhsavoanjqkqvnnpbkvoweurybjt7gauunbg37ueahcbze5ise/
$ time curl http://localhost:8080/ipns/vitalik.eth/ -s -o /dev/null

real	0m0.223s
user	0m0.007s
sys	0m0.006s

```

The node on which these tests were performed is publicly accessible and works fine when downgrading to Kubo 0.15.0.

Has anyone noticed this or has experience troubleshooting similar issues? Are there any debugging utilities or logs that might shed some insight into what’s responsible for the slowness? A large percentage of ENS dWebsites use IPNS now, so obviously we don’t want to deploy an upgrade that will negatively impact user experience.

Any advice is much appreciated! Thank you.

---

<div class="post-metadata">

**Author:** ![Discordian](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/discordian/32/4692_2.png) [@Discordian](https://discuss.ipfs.tech/u/Discordian)\
**Post date:** [February 21, 2023, 4:26pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/2 "2023-02-21T16:26:26Z")

</div>

Wow great post, I wish I had a direct answer for you. I do have a question though, are you using [IPNS PubSub](https://github.com/ipfs/kubo/blob/master/docs/experimental-features.md#ipns-pubsub)? And if not, does enabling that improve your situation at all?

---

<div class="post-metadata">

**Author:** ![eth-limo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/eth-limo/32/7456_2.png) [@eth-limo](https://discuss.ipfs.tech/u/eth-limo)\
**Post date:** [February 21, 2023, 4:34pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/3 "2023-02-21T16:34:24Z")

</div>

Hi @Discordian,

Yes, we do have IPNS Pub/Sub enabled. Here is a snippet from our Systemd unit file:

```auto
ExecStart=/usr/bin/ipfs daemon --enable-gc --migrate=true --enable-pubsub-experiment --enable-namesys-pubsub

```

I have not noticed any improvement using this flag.

---

<div class="post-metadata">

**Author:** ![Discordian](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/discordian/32/4692_2.png) [@Discordian](https://discuss.ipfs.tech/u/Discordian)\
**Post date:** [February 21, 2023, 4:36pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/4 "2023-02-21T16:36:31Z")

</div>

> [@eth-limo](#):
>
> I have not noticed any improvement using this flag.

Wow surprising to me, I found resolution times after the first to go much faster with that enabled.

My next idea is (if you have the resources for it, IIRC this increases your memory requirement) to see how the [Accelerated DHT Client](https://github.com/ipfs/kubo/blob/master/docs/experimental-features.md#accelerated-dht-client) fares for you. As I found this to be critical for my VPS node.

---

<div class="post-metadata">

**Author:** ![eth-limo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/eth-limo/32/7456_2.png) [@eth-limo](https://discuss.ipfs.tech/u/eth-limo)\
**Post date:** [February 21, 2023, 4:37pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/5 "2023-02-21T16:37:32Z")

</div>

We have been using the AcceleratedDHT too!

```auto
/usr/bin/ipfs config --json Experimental.AcceleratedDHTClient true

```

---

<div class="post-metadata">

**Author:** ![Discordian](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/discordian/32/4692_2.png) [@Discordian](https://discuss.ipfs.tech/u/Discordian)\
**Post date:** [February 21, 2023, 4:38pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/6 "2023-02-21T16:38:14Z")

</div>

Oh my! Perhaps @Jorropo has an idea (or maybe knows who might?). Very sorry for the inconvenience here.

---

<div class="post-metadata">

**Author:** ![eth-limo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/eth-limo/32/7456_2.png) [@eth-limo](https://discuss.ipfs.tech/u/eth-limo)\
**Post date:** [February 21, 2023, 4:39pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/7 "2023-02-21T16:39:15Z")

</div>

Thank you for looking into this. It’s been quite a headache for us. Hopefully we can get to the root cause and proceed with our upgrade.

---

<div class="post-metadata">

**Author:** ![Discordian](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/discordian/32/4692_2.png) [@Discordian](https://discuss.ipfs.tech/u/Discordian)\
**Post date:** [February 21, 2023, 5:50pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/8 "2023-02-21T17:50:03Z")

</div>

> [@eth-limo](#):
>
> Hopefully we can get to the root cause and proceed with our upgrade.

Absolutely, I will raise this thread everywhere I can to try to get you answers 🙏

---

<div class="post-metadata">

**Author:** ![ylempereur](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/ylempereur/32/5528_2.png) [@ylempereur](https://discuss.ipfs.tech/u/ylempereur)\
**Post date:** [February 21, 2023, 6:11pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/9 "2023-02-21T18:11:45Z")

</div>

Here is a bug I reported back in September that may (or may not) be related. The fact it happened for the same version and has to do with discovery when using the accelerated DHT is what makes me think they could be related.

> <https://github.com/ipfs/kubo/issues/9309>
>
> \### Checklist
> 
> \- \[X\] This is a bug report, not a question. Ask questions on \[dis…cuss.ipfs.io\](https://discuss.ipfs.io).
> \- \[X\] I have searched on the \[issue tracker\](https://github.com/ipfs/kubo/issues?q=is%3Aissue) for my bug.
> \- \[X\] I am running the latest \[kubo version\](https://dist.ipfs.tech/#kubo) or have an issue updating.
> 
> \### Installation method
> 
> ipfs-update or dist.ipfs.tech
> 
> \### Version
> 
> \`\`\`Text
> Kubo version: 0.16.0-rc1
> Repo version: 12
> System version: amd64/darwin
> Golang version: go1.19.1
> \`\`\`
> 
> 
> \### Config
> 
> \`\`\`json
> "ResourceMgr": {
> "Enabled": false
> },
> \`\`\`
> 
> 
> \### Description
> 
> Compared to previous versions (0.15 and prior), the hourly network scan done by the AcceleratedDHTClient causes a much higher CPU spike and finds far fewer peers (as reported by \`ipfs stats dht wan\`, 1K-3K vs 8K-10K, around the same time).
> 
> Something has changed (not for the better), and I made sure to turn off ResourceMgr in both cases.
> 
> Please advise.

---

<div class="post-metadata">

**Author:** ![Jorropo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jorropo/32/3230_2.png) [@Jorropo](https://discuss.ipfs.tech/u/Jorropo)\
**Post date:** [February 21, 2023, 6:20pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/10 "2023-02-21T18:20:59Z")

</div>

This should not be impacted by the signature change, it’s the same bytes under the hood except we use different fields from the protobuf.  
I don’t know without investigating and I don’t really have time right now for this sorry, one thing I would check is if the `ipfs dht get` command also sees a slow down between 0.15 and 0.15+ (the point is to see if the slow down are in the dht or ipns codepaths).

---

<div class="post-metadata">

**Author:** ![eth-limo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/eth-limo/32/7456_2.png) [@eth-limo](https://discuss.ipfs.tech/u/eth-limo)\
**Post date:** [February 21, 2023, 10:12pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/11 "2023-02-21T22:12:56Z")

</div>

Here are some comparisons between each version and whether or not the AcceleratedDHT client is enabled. I’m happy to provide additional diagnostics.

**v18.0.1**

`AcceleratedDHT: false`

```auto
$ time ipfs dht get -v -- /ipns/k51qzi5uqu5dmjnxaa3ed22c0a6xaoyw5d75uacizdpc4u9rmxnqialvwat8y9 | grep says | wc -l
27

real	0m17.181s
user	0m0.009s
sys 0m0.039s

$ time ipfs dht get -v -- /ipns/k51qzi5uqu5djwbl0zcd4g9onue26a8nq97c0m9wp6kir1gibuyjxpkqpoxwag | grep says | wc -l
0

real	0m0.429s
user	0m0.018s
sys 0m0.022s

```

`AcceleratedDHT: true`

```auto
$ time ipfs dht get -v -- /ipns/k51qzi5uqu5dmjnxaa3ed22c0a6xaoyw5d75uacizdpc4u9rmxnqialvwat8y9 | grep says | wc -l
10

real	0m0.300s
user	0m0.012s
sys 0m0.007s

$ time ipfs dht get -v -- /ipns/k51qzi5uqu5djwbl0zcd4g9onue26a8nq97c0m9wp6kir1gibuyjxpkqpoxwag | grep says | wc -l
0

real	0m0.085s
user	0m0.008s
sys 0m0.009s

```

* * *

**v15.0.0**

`AcceleratedDHT: true`

```auto
$ time ipfs dht get -v -- /ipns/k51qzi5uqu5dmjnxaa3ed22c0a6xaoyw5d75uacizdpc4u9rmxnqialvwat8y9 | grep says | wc -l
10

real	0m0.581s
user	0m0.008s
sys 0m0.008s

$ time ipfs dht get -v -- /ipns/k51qzi5uqu5djwbl0zcd4g9onue26a8nq97c0m9wp6kir1gibuyjxpkqpoxwag | grep says | wc -l
0

real	0m0.133s
user	0m0.004s
sys 0m0.014s

```

`AcceleratedDHT: false`

```auto
$ time ipfs dht get -v -- /ipns/k51qzi5uqu5dmjnxaa3ed22c0a6xaoyw5d75uacizdpc4u9rmxnqialvwat8y9 | grep says | wc -l
88

real	0m20.587s
user	0m0.001s
sys 0m0.080s

$ time ipfs dht get -v -- /ipns/k51qzi5uqu5djwbl0zcd4g9onue26a8nq97c0m9wp6kir1gibuyjxpkqpoxwag | grep says | wc -l
0

real	0m0.198s
user	0m0.011s
sys 0m0.035s

```

I’m not sure if the full output from `ipfs dht get` is useful so I’ve omitted it for now. Please let me know and I’ll include it if necessary.

Are there any other diagnostics that could aid in troubleshooting this?

---

<div class="post-metadata">

**Author:** ![Jorropo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jorropo/32/3230_2.png) [@Jorropo](https://discuss.ipfs.tech/u/Jorropo)\
**Post date:** [February 21, 2023, 10:56pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/12 "2023-02-21T22:56:19Z")

</div>

That intresting so it seems to be dht related, I recently merged some fixes for a latency bug in the DHT, but I’m suprised this would effect this, could you please retry with 0.19-rc1 when it is released (planned for this week) ?

---

<div class="post-metadata">

**Author:** ![eth-limo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/eth-limo/32/7456_2.png) [@eth-limo](https://discuss.ipfs.tech/u/eth-limo)\
**Post date:** [February 21, 2023, 11:17pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/13 "2023-02-21T23:17:45Z")

</div>

Absolutely! I’ll keep an eye on the releases this week and report back with my findings. Thank you.

---

<div class="post-metadata">

**Author:** ![hector](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/hector/32/178_2.png) [@hector](https://discuss.ipfs.tech/u/hector)\
**Post date:** [February 22, 2023, 12:12pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/14 "2023-02-22T12:12:35Z")

</div>

Can this be a resource manager issue?

---

<div class="post-metadata">

**Author:** ![Jorropo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jorropo/32/3230_2.png) [@Jorropo](https://discuss.ipfs.tech/u/Jorropo)\
**Post date:** [February 22, 2023, 12:59pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/15 "2023-02-22T12:59:40Z")

</div>

Maybe, we would expect the inverse behaviour tho (accelerated slowing down and normal client working more or less as usual).

---

<div class="post-metadata">

**Author:** ![guseggert](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/guseggert/32/5519_2.png) [@guseggert](https://discuss.ipfs.tech/u/guseggert)\
**Post date:** [February 23, 2023, 4:11pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/16 "2023-02-23T16:11:20Z")

</div>

The normal client does more work in a single DHT lookup than the accelerated client, so with no more info it still seems possible that libp2p resource manager is throttling and slowing things down.

Could you try running the same tests on v18.0.1 with resource manager disabled? That’s `Swarm.ResourceMgr.Enabled = false`. This will at least tell us if it’s RM or not, if it is then we can work on tweaking the RM limits.

---

<div class="post-metadata">

**Author:** ![eth-limo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/eth-limo/32/7456_2.png) [@eth-limo](https://discuss.ipfs.tech/u/eth-limo)\
**Post date:** [February 27, 2023, 3:44pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/17 "2023-02-27T15:44:39Z")

</div>

Disabling `ResourceMgr` _appeared_ to partially alleviate _some_ of the poor gateway performance for one of the test cases but the rest are still unusable:

v18.0.1  
`Swarm.ResourceMgr.Enabled = false`

Unreachable/slow IPNS gateway request

```auto
$ time ipfs dht get -v -- /ipns/k51qzi5uqu5dmjnxaa3ed22c0a6xaoyw5d75uacizdpc4u9rmxnqialvwat8y9 | grep says | wc -l
10

real	0m0.371s
user	0m0.010s
sys 0m0.009s

# Extremely slow
$ time curl -so /dev/null http://localhost:8080/ipns/k51qzi5uqu5dmjnxaa3ed22c0a6xaoyw5d75uacizdpc4u9rmxnqialvwat8y9/

real	3m0.016s
user	0m0.013s
sys 0m0.006s

```

Unreachable/slow IPNS gateway request

```auto
$ time ipfs dht get -v -- /ipns/k51qzi5uqu5dm7gcgw5wxlf81aszjbihejohdv6pjewxwhtsjoimufognxl8fz | grep says | wc -l
10

real	0m0.324s
user	0m0.008s
sys 0m0.009s

# Extremely slow
$ time curl -so /dev/null http://localhost:8080/ipns/k51qzi5uqu5dm7gcgw5wxlf81aszjbihejohdv6pjewxwhtsjoimufognxl8fz/

real	3m0.122s
user	0m0.006s
sys 0m0.012s

```

Successful IPNS gateway request

```auto
$ time ipfs dht get -v -- /ipns/k51qzi5uqu5djwbl0zcd4g9onue26a8nq97c0m9wp6kir1gibuyjxpkqpoxwag | grep says | wc -l
0

real	0m0.124s
user	0m0.003s
sys 0m0.018s

# Noticeable improvement
$ time curl -so /dev/null http://localhost:8080/ipns/k51qzi5uqu5djwbl0zcd4g9onue26a8nq97c0m9wp6kir1gibuyjxpkqpoxwag/

real	0m0.216s
user	0m0.000s
sys 0m0.010s

```

I’m not really sure why one of the test sites is able to be retrieved but the others are not. I’ve got plenty of additional examples if those would be helpful.

---

<div class="post-metadata">

**Author:** ![eth-limo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/eth-limo/32/7456_2.png) [@eth-limo](https://discuss.ipfs.tech/u/eth-limo)\
**Post date:** [May 16, 2023, 8:33pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/18 "2023-05-16T20:33:58Z")

</div>

Just tried again with v0.20.0 and got the same results - IPNS performance is just incredibly slow. @Jorropo do you have any other suggestions that I can try?

edit - I should mention that almost every single IPNS gateway request completes approximately in 1m. Is this some kind of configurable timeout?

---

<div class="post-metadata">

**Author:** ![0xc0de4c0ffee](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/0xc0de4c0ffee/32/7672_2.png) [@0xc0de4c0ffee](https://discuss.ipfs.tech/u/0xc0de4c0ffee)\
**Post date:** [June 1, 2023, 7:09am UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/19 "2023-06-01T07:09:30Z")

</div>

🙏 @eth-limo,  
I’m still not sure what’s causing this issues 🤕 back to testing multiple gateways, services and versions.

IPNS published from web3.storage/w3name service

- ❌ dweb.link (504)  
[https://k51qzi5uqu5dmgi2q98r638vet29ef6up32m3rixduu32urkurm6kj4rq8hufy.ipns.dweb.link](https://k51qzi5uqu5dmgi2q98r638vet29ef6up32m3rixduu32urkurm6kj4rq8hufy.ipns.dweb.link)
- ❌ .ipfs.io (504)  
[https://ipfs.io/ipns/k51qzi5uqu5dmgi2q98r638vet29ef6up32m3rixduu32urkurm6kj4rq8hufy](https://ipfs.io/ipns/k51qzi5uqu5dmgi2q98r638vet29ef6up32m3rixduu32urkurm6kj4rq8hufy)
- ✅ ipfs2.eth.limo [https://k51qzi5uqu5dmgi2q98r638vet29ef6up32m3rixduu32urkurm6kj4rq8hufy.ipfs2.eth.limo](https://k51qzi5uqu5dmgi2q98r638vet29ef6up32m3rixduu32urkurm6kj4rq8hufy.ipfs2.eth.limo)
- ✅ .cf-ipfs.com  
[https://k51qzi5uqu5dmgi2q98r638vet29ef6up32m3rixduu32urkurm6kj4rq8hufy.ipns.cf-ipfs.com](https://k51qzi5uqu5dmgi2q98r638vet29ef6up32m3rixduu32urkurm6kj4rq8hufy.ipns.cf-ipfs.com)

IPNS published from [https://dwebservices.xyz/](https://dwebservices.xyz/)

- ✅ dweb.link  
[https://k51qzi5uqu5dhhcu1pop9pynjg2g3l6vrlt379x6huzy2zhyg54o1u6csnuwi3.ipns.dweb.link](https://k51qzi5uqu5dhhcu1pop9pynjg2g3l6vrlt379x6huzy2zhyg54o1u6csnuwi3.ipns.dweb.link)
- ✅ .ipfs.io  
[https://ipfs.io/ipns/k51qzi5uqu5dhhcu1pop9pynjg2g3l6vrlt379x6huzy2zhyg54o1u6csnuwi3](https://ipfs.io/ipns/k51qzi5uqu5dhhcu1pop9pynjg2g3l6vrlt379x6huzy2zhyg54o1u6csnuwi3)
- ✅ ipfs2.eth-limo [https://k51qzi5uqu5dhhcu1pop9pynjg2g3l6vrlt379x6huzy2zhyg54o1u6csnuwi3.ipfs2.eth.limo](https://k51qzi5uqu5dhhcu1pop9pynjg2g3l6vrlt379x6huzy2zhyg54o1u6csnuwi3.ipfs2.eth.limo)
- ✅ .cf-ipfs.com  
[https://k51qzi5uqu5dhhcu1pop9pynjg2g3l6vrlt379x6huzy2zhyg54o1u6csnuwi3.ipns.cf-ipfs.com](https://k51qzi5uqu5dhhcu1pop9pynjg2g3l6vrlt379x6huzy2zhyg54o1u6csnuwi3.ipns.cf-ipfs.com)

I’m update this with results from local/browser Helia nodes and Fleek/other services soon…

---

<div class="post-metadata">

**Author:** ![eth-limo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/eth-limo/32/7456_2.png) [@eth-limo](https://discuss.ipfs.tech/u/eth-limo)\
**Post date:** [June 1, 2023, 9:57pm UTC](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012/20 "2023-06-01T21:57:36Z")

</div>

Testing again with v0.20.0 _without_ `--enable-pubsub-experiment` and `--enable-namesys-pubsub` seemed to do the trick!

```auto
time ipfs resolve -r /ipns/k51qzi5uqu5djhw4rskl5h4ylujy8cwbhn3bcmgwxjzclrebis7uusb1gnfnmo/
/ipfs/QmXGSRcFfVhvwepRZFbg97AkTRo6kt23UDCiMYLcEzv8FC

real	0m0.704s
user	0m0.018s
sys 0m0.033s

```

I followed the instructions [here](https://github.com/ipfs/kubo/blob/master/docs/debug-guide.md) for debugging. I found many instances of hung goroutines relating to these flags:

```auto
goroutine 1435999 [select, 1542 minutes]:
github.com/libp2p/go-yamux/v4.(*Stream).Read(0xc00baae2a0, {0xc0093a0630, 0x1, 0x1})
        github.com/libp2p/go-yamux/v4@v4.0.0/stream.go:111 +0x1a9
github.com/libp2p/go-libp2p/p2p/muxer/yamux.(*stream).Read(0xe7707c?, {0xc0093a0630?, 0x100c00bc1d2c0?, 0x203000?})
        github.com/libp2p/go-libp2p@v0.27.3/p2p/muxer/yamux/stream.go:17 +0x1e
github.com/libp2p/go-libp2p/p2p/net/swarm.(*Stream).Read(0xc00976a700, {0xc0093a0630?, 0x80?, 0x7fad1e107430?})
        github.com/libp2p/go-libp2p@v0.27.3/p2p/net/swarm/swarm_stream.go:55 +0x33
github.com/multiformats/go-multistream.(*lazyClientConn[...]).Read(0xc0047f5ea0?, {0xc0093a0630?, 0x1?, 0x1?})
        github.com/multiformats/go-multistream@v0.4.1/lazyClient.go:68 +0xb8
github.com/libp2p/go-libp2p/p2p/host/basic.(*streamWrapper).Read(0xc0078c1530?, {0xc0093a0630?, 0x3c500?, 0xc710302babf?})
        github.com/libp2p/go-libp2p@v0.27.3/p2p/host/basic/basic_host.go:1156 +0x27
github.com/libp2p/go-libp2p-pubsub.(*PubSub).handlePeerDead(0x0?, {0x2c0f6c0, 0xc0084fd640})
        github.com/libp2p/go-libp2p-pubsub@v0.9.3/comm.go:147 +0x86
created by github.com/libp2p/go-libp2p-pubsub.(*PubSub).handleNewPeer
        github.com/libp2p/go-libp2p-pubsub@v0.9.3/comm.go:128 +0x398

```

```auto
goroutine 586 [select, 89 minutes]:
github.com/ipfs/boxo/namesys/republisher.(*Republisher).Run(0xc001100870, {0x2c060b8, 0xc0012a8480})
        github.com/ipfs/boxo@v0.8.1/namesys/republisher/repub.go:79 +0x12a
github.com/jbenet/goprocess.(*process).Go.func1()
        github.com/jbenet/goprocess@v0.1.4/impl-mutex.go:134 +0x36
created by github.com/jbenet/goprocess.(*process).Go
        github.com/jbenet/goprocess@v0.1.4/impl-mutex.go:133 +0x238

```

I’m not entirely sure what changed starting in v0.16.0 with regards to these features. I did find an open [issue](https://github.com/ipfs/kubo/issues/9717) regarding the deprecation of namesys/pubsub in general, so it might be related. Thank you to everyone who assisted in troubleshooting this problem. I’m more than happy to provide additional findings if this can help anyone else.

[Next page](https://discuss.ipfs.tech/t/kubo-versions-0-15-0-gateway-and-slow-ipns-performance/16012.md?page=2)