Hi Darcy Very appreciated you have run such detailed code level investment. Basically, I would say you are on the right road and understood things right. Here is something in my head that may provide more help. 1. Register used to be designed as a low-frequency operation. 2. The register process(you could read the register process code) requires a storage level lock, even we don't use `hash` rather than `first only`. Or like you said, open more queue channels. Those wouldn't help much. Also at the same time you have very high risk about the storage crash or id conflicts.
The solutions could be 1. Check your endpoints and operation names in your applications, should include the parameter. Try to format them without it. For the parameter, I mean something like account id, order id, etc. which are countless in the system of runtime. Actually, this would crash the backend eventually, even register is not the issue. Because SkyWalking registers an integer id for every endpoint. Once the endpoints are countless, your IDs will run out sooner or later. 2. The whole register things have been removed since the next release, 8.0.0, to ease the performance issue you are facing. But, keep in mind, even we don't have register performance and ID run out issues, the aggregation payloads are still there, and cause higher payload than expected, but not crash. Actually, we introduced this in the last week's bi-weekly online meeting in M andarin, take a look https://space.bilibili.com/390683219. Sheng Wu 吴晟 Twitter, wusheng1108 darcy dai <[email protected]> 于2020年4月22日周三 下午4:15写道： > hi all, there are some problems with the registration mechanism to > discuss. because of the size limit of the email, I wrote the article in > Evernote， link: > https://app.yinxiang.com/fx/ef016297-12f1-4b16-878d-7815af1394e1 < > https://app.yinxiang.com/fx/ef016297-12f1-4b16-878d-7815af1394e1> > Thank you for your patience!
