# Why is IPNS so slow **URL:** \ **Category:** Uncategorized\ **Created:** [June 25, 2020, 3:55pm UTC](https://discuss.ipfs.tech/t/why-is-ipns-so-slow/8510 "2020-06-25T15:55:50Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![unconst](https://avatars.discourse-cdn.com/v4/letter/u/90ced4/32.png) [@unconst](https://discuss.ipfs.tech/u/unconst)\ **Post date:** [June 25, 2020, 3:55pm UTC](https://discuss.ipfs.tech/t/why-is-ipns-so-slow/8510/1 "2020-06-25T15:55:51Z")
Re opening this thread: > [@Why ipns is so slow](https://discuss.ipfs.tech/t/why-ipns-is-so-slow/2161): > > It usually takes 2~ minutes for command ipfs name publish \(running on my local). And also more 2 minutes for ipfs name resolve \(running on my digitalocean vps). " It usually takes 2~ minutes for command `ipfs name publish ` (running on my local). And also more 2 minutes for `ipfs name resolve ` (running on my digitalocean vps). " Has this been resolved? ---
**Author:** ![adin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/adin/32/2679_2.png) [@adin](https://discuss.ipfs.tech/u/adin)\ **Post date:** [June 26, 2020, 7:13pm UTC](https://discuss.ipfs.tech/t/why-is-ipns-so-slow/8510/2 "2020-06-26T19:13:00Z")
IPNS publish/resolve times using the DHT are unfortunately still slower than they could/should be since as of today (06/26/20) much of the network is still running pre 0.5 nodes that are behind NATs and are advertising themselves to the rest of the network. As more people upgrade to go-ipfs \>=0.5 network performance should increase, however there’s also interest in figuring out a good way to upgrade the network for new nodes without waiting for users to upgrade their nodes. However, if you use IPNS over PubSub (`--enable-namesys-pubsub`) and the publishers and subscribers are running go-ipfs \>=0.5 then an IPNS resolve should be about as fast as an IPFS resolve. ---
**Author:** ![sebastiendan](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/sebastiendan/32/3530_2.png) [@sebastiendan](https://discuss.ipfs.tech/u/sebastiendan)\ **Post date:** [December 22, 2020, 6:48am UTC](https://discuss.ipfs.tech/t/why-is-ipns-so-slow/8510/3 "2020-12-22T06:48:52Z")
Any news on this interest in figuring out a way for updated nodes to not be slowed down by legacy nodes? ---
**Author:** ![sebastiendan](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/sebastiendan/32/3530_2.png) [@sebastiendan](https://discuss.ipfs.tech/u/sebastiendan)\ **Post date:** [April 2, 2021, 9:12am UTC](https://discuss.ipfs.tech/t/why-is-ipns-so-slow/8510/4 "2021-04-02T09:12:30Z")
Hi @adin, would you have any update about this? Thanks! ---
**Author:** ![BladeMcCool](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/blademccool/32/4636_2.png) [@BladeMcCool](https://discuss.ipfs.tech/u/BladeMcCool)\ **Post date:** [April 2, 2021, 6:13pm UTC](https://discuss.ipfs.tech/t/why-is-ipns-so-slow/8510/5 "2021-04-02T18:13:53Z")
as of 2 months ago the :latest tagged docker image was still delivering an 0.4.xxx version . i had no idea until i tried to use stuff that didnt exist. fun times. manually told it to use 0.8 after that. could this be the cause for a lack of higher versions being deployed? ---
**Author:** ![adin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/adin/32/2679_2.png) [@adin](https://discuss.ipfs.tech/u/adin)\ **Post date:** [April 5, 2021, 4:24pm UTC](https://discuss.ipfs.tech/t/why-is-ipns-so-slow/8510/6 "2021-04-05T16:24:17Z")
IPNS Publishes + Resolves have gotten faster, although they’re still not as fast as they could be. IPNS over PubSub is still going to be the fastest resolution option though. If you want to use IPNS over the DHT-only you can speed things up significantly by using `-dhtrc` and setting it to a smaller number (it defaults to 20, so 10 or even 5 should be much faster). Is your main concern about publish or resolve times? ---
**Author:** ![adin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/adin/32/2679_2.png) [@adin](https://discuss.ipfs.tech/u/adin)\ **Post date:** [April 5, 2021, 4:24pm UTC](https://discuss.ipfs.tech/t/why-is-ipns-so-slow/8510/7 "2021-04-05T16:24:23Z")
Today I can see that [latest](https://hub.docker.com/layers/ipfs/go-ipfs/latest/images/sha256-4db70b44b457c823e73d2c540c5e122d95f9abb35a7aa49f5e3b02cd7ec8a162?context=explore) and [v0.8.0](https://hub.docker.com/layers/ipfs/go-ipfs/v0.8.0/images/sha256-4db70b44b457c823e73d2c540c5e122d95f9abb35a7aa49f5e3b02cd7ec8a162?context=explore) have the same digests and so should match. ---
**Author:** ![sebastiendan](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/sebastiendan/32/3530_2.png) [@sebastiendan](https://discuss.ipfs.tech/u/sebastiendan)\ **Post date:** [April 15, 2021, 5:19am UTC](https://discuss.ipfs.tech/t/why-is-ipns-so-slow/8510/8 "2021-04-15T05:19:31Z")
[Sorry, didn’t get notified of your reply] > [@adin](#): > > Is your main concern about publish or resolve times? Actually I’m concerned about both. But my question was really about this specific statement of yours: > [@adin](#): > > however there’s also interest in figuring out a good way to upgrade the network for new nodes without waiting for users to upgrade their nodes. ---
**Author:** ![adin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/adin/32/2679_2.png) [@adin](https://discuss.ipfs.tech/u/adin)\ **Post date:** [April 15, 2021, 7:04am UTC](https://discuss.ipfs.tech/t/why-is-ipns-so-slow/8510/9 "2021-04-15T07:04:45Z")
> [@adin](#): > > however there’s also interest in figuring out a good way to upgrade the network for new nodes without waiting for users to upgrade their nodes. Ah, not much progress on a defined playbook here. So far there are two major options available with their own tradeoffs: 1. Just run two DHTs for some period of time before sunsetting the older one (e.g. one with protocol /ipfs/kad/1.0.0, and the other with /ipfs/kad/2.0.0) and try them both in parallel. 2. Try nesting one DHT inside of another one, i.e. by saying that every member of /ipfs/kad/2.0.0 is also a member of /ipfs/kad/1.0.0 it’s possible to start queries in the new DHT and continue them in the old one. Option 2 is nice because it’s less resource intensive and nicely scales to if there are multiple version upgrades happening together. However, it adds some complexity in implementation and management (e.g. some of the Sybil resistance rules, such as those described in [Hardening the IPFS public DHT against eclipse attacks | IPFS Blog & News](https://blog.ipfs.io/2020-10-30-dht-hardening/), are a little weird to enforce in smaller networks). These aren’t game stoppers, but putting in the rest of the work here will probably end up waiting until doing a protocol-level upgrade becomes important enough to rise to the top of the TODO list. ---
**Author:** ![zacharywhitley](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/zacharywhitley/32/2670_2.png) [@zacharywhitley](https://discuss.ipfs.tech/u/zacharywhitley)\ **Post date:** [April 15, 2021, 11:41am UTC](https://discuss.ipfs.tech/t/why-is-ipns-so-slow/8510/10 "2021-04-15T11:41:53Z")
Speaking of updates, I always thought it would be cool if Ipfs-update pulled the new ipfs version from ipfs if a daemon was running. There isn’t really a compelling need to do that but it would be cool from a dogfooding perspective. It would also be nice if the GitHub and ipfs distros page listed the cid’s as well. ---
**Author:** ![adin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/adin/32/2679_2.png) [@adin](https://discuss.ipfs.tech/u/adin)\ **Post date:** [April 15, 2021, 1:16pm UTC](https://discuss.ipfs.tech/t/why-is-ipns-so-slow/8510/12 "2021-04-15T13:16:27Z")
I’d recommend starting a new thread to talk about that, this one has drifted pretty far off topic already 😃. Feel free to tag me though.