Request optimizations #339
Conversation
… sub When setting up the request and checking if global sub should be created, we do not need to use the task completion source as we are not in an async flow; hence we never let the caller execute something in the meantime.
|
@ColinSullivan1 having the global subscription created immediately when connected, is that avoided due to not creating an unnecessary subscription? Could this be OK if we added config for the behavior? E.g |
|
Reverted a commit. As it's not possible to specify both |
|
In my app's case, we have maybe only one or two request-reply usages. All the rest are publish. We use web services for request/reply (and authorization). In our case, lazily creating the global subscription would be our preference. Is there a performance gain by creating it immediately for heavy request/reply scenarios? |
|
Possibly this will solve #202 as well |
|
@ColinSullivan1 For ease, removing interlocked etc. a Guid would be easy. But I guess you don't want a longer subscription etc. than necessary |
|
@danielwertheim , GUID would certainly work, but imo this will be faster and because the first token of the global inbox subject is a random set of bytes seeded by a GUI, we should be safe the way it is, and it'll reduce pressure at scale (smaller subjects as you mentioned). |
After these changes when running the Benchmarks included I see an increase with about 20% in the request async flow.
When debugging and monitoring GC activity (as discussed in #299), both with and without a specified timeout, I see a highly reduced GC activity also leading to reducing CPU activity.