You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The workaround dependent-admin.js was provided in #42 as a means to optimize the time required to sent the first message to each topic after startup.
It works, wonderfully. However, the approach is generally predicated on the idea that you know all the topics a producer will send messages to at the time of initialization. Due to the structure of our applications using this library, that is not always the case and not easily obtained without some non-trivial refactoring. So I experimented with the idea of "lazy-load" wrapper around the producer that tracks topic usage and calls fetchTopicMetadata when a new topic is encountered.
I didn't expect it to yield much in performance as the whole point of this exercise was to move the metadata fetching to the startup phase before the app is considered "ready", and doing it on-demand is counter to that. When I saw the results, I immediately wondered why is this not the default, internal behavior of the Confluent producer in the first place?
In the example below, we are not loading any topic metadata in advance of the call to the send method. The wrapper tracks the last metadata load or send time for each topic and will call fetchTopicMetadata prior to send anytime a topic is uninitialized or the metadata has expired according to metadata.max.age.ms value. (The expiration portion is not exercised in the test).
Connected @ 4msMessage #0 sent @ 6msMessage #1 sent @ 7msMessage #2 sent @ 8msMessage #3 sent @ 8msMessage #4 sent @ 9msMessage #5 sent @ 9msMessage #6 sent @ 10msMessage #7 sent @ 10msMessage #8 sent @ 11msMessage #9 sent @ 11ms
Output from the Confluent Producer test:
Connected @ 4msMessage #0 sent @ 1008msMessage #1 sent @ 2015msMessage #2 sent @ 3017msMessage #3 sent @ 4021msMessage #4 sent @ 5024msMessage #5 sent @ 6026msMessage #6 sent @ 7029msMessage #7 sent @ 8033msMessage #8 sent @ 9033msMessage #9 sent @ 10037ms
The text was updated successfully, but these errors were encountered:
The workaround dependent-admin.js was provided in #42 as a means to optimize the time required to sent the first message to each topic after startup.
It works, wonderfully. However, the approach is generally predicated on the idea that you know all the topics a producer will send messages to at the time of initialization. Due to the structure of our applications using this library, that is not always the case and not easily obtained without some non-trivial refactoring. So I experimented with the idea of "lazy-load" wrapper around the producer that tracks topic usage and calls fetchTopicMetadata when a new topic is encountered.
I didn't expect it to yield much in performance as the whole point of this exercise was to move the metadata fetching to the startup phase before the app is considered "ready", and doing it on-demand is counter to that. When I saw the results, I immediately wondered why is this not the default, internal behavior of the Confluent producer in the first place?
In the example below, we are not loading any topic metadata in advance of the call to the send method. The wrapper tracks the last metadata load or send time for each topic and will call fetchTopicMetadata prior to send anytime a topic is uninitialized or the metadata has expired according to
metadata.max.age.ms
value. (The expiration portion is not exercised in the test).Output from the 'Smart' Producer test:
Output from the Confluent Producer test:
The text was updated successfully, but these errors were encountered: