Saving Three Months of Latency with a Single OpenTelemetry Trace

I wish posts like this would explore the relative savings rather than the absolute. On its own I don’t feel like that saving is really telling me much, taken to the extreme you could just not run the service at all and save all the time - a tongue in cheek example but in context is this saving a big deal or is it just engineering looking for small efficiencies to justify their time?

Re: Saving Three Months of Latency with a Single OpenTelemetry Trace

#6

Post by tnolet » Fri, Jun 07, 2024, 3:04 PM UTC

simonbarker87 wrote: post #5

I wish posts like this would explore the relative savings rather than the absolute. On its own I don’t feel like that saving is really telling me much, taken to the extreme you could just not run the service at all and save all the time - a tongue in cheek example but in context is this saving a big deal or is it just engineering looking for small efficiencies to justify their time?

Hey, I work at Checkly and asked my coworker (who wrote the post) to give some more background on this. I can assure you, we're busy and this was not done for some vanity price!

Re: Saving Three Months of Latency with a Single OpenTelemetry Trace

#7

Post by cdelsolar » Fri, Jun 07, 2024, 3:05 PM UTC

μs isn't picoseconds, it's microseconds, which are a million times bigger...

Re: Saving Three Months of Latency with a Single OpenTelemetry Trace

#8

Post by janOsch » Fri, Jun 07, 2024, 3:08 PM UTC

simonbarker87 wrote: post #5

I wish posts like this would explore the relative savings rather than the absolute. On its own I don’t feel like that saving is really telling me much, taken to the extreme you could just not run the service at all and save all the time - a tongue in cheek example but in context is this saving a big deal or is it just engineering looking for small efficiencies to justify their time?

I'm the author of the post. You raise a good point about relative savings. Based on last week's data, our change reduced the task time by 40ms from an average of 3440ms, and this task runs 11 million times daily. This translates to a saving of about 1% on compute.

Re: Saving Three Months of Latency with a Single OpenTelemetry Trace

#9

Post by brunoarueira » Fri, Jun 07, 2024, 3:09 PM UTC

simonbarker87 wrote: post #5

I wish posts like this would explore the relative savings rather than the absolute. On its own I don’t feel like that saving is really telling me much, taken to the extreme you could just not run the service at all and save all the time - a tongue in cheek example but in context is this saving a big deal or is it just engineering looking for small efficiencies to justify their time?

I agree, but this post looks like an advertisement about the service itself.

Re: Saving Three Months of Latency with a Single OpenTelemetry Trace

#10

Post by simonbarker87 » Fri, Jun 07, 2024, 3:12 PM UTC

janOsch wrote: post #8

simonbarker87 wrote: post #5

I wish posts like this would explore the relative savings rather than the absolute. On its own I don’t feel like that saving is really telling me much, taken to the extreme you could just not run the service at all and save all the time - a tongue in cheek example but in context is this saving a big deal or is it just engineering looking for small efficiencies to justify their time?

I'm the author of the post. You raise a good point about relative savings. Based on last week's data, our change reduced the task time by 40ms from an average of 3440ms, and this task runs 11 million times daily. This translates to a saving of about 1% on compute.

Thanks for the follow up, sounds like a decent saving and investment of time then.