librelist archives

« back to archive

Sidekiq and New Relic, New Relic responds to my request

Sidekiq and New Relic, New Relic responds to my request

From:
Hank Beaver
Date:
2012-10-12 @ 02:07
I sent a request to New Relic, who I use for many servers. I wanted to see
if I could help a little like was suggested on the Wiki,
https://github.com/mperham/sidekiq/wiki/Problems-and-Troubleshooting.

Here was my request to New Relic:

"Subject: Is there planned support for threadsafe Ruby Agent/GEM?

We have transitioned to Sidekiq (http://mperham.github.com/sidekiq/) which
uses Ruby 1.9 threads. It has come to our attention from the Sidekiq team
that newrelic_rpm gem is not threadsafe. This obviously impacts our
application and can have the potential for causing major issues. Is there
any plan to make the gem threadsafe?

Thanks,
Hank"

This was the response from New Relic:

"I hadn't heard that our gem wasn't threadsafe, so we asked our senior Java
agent engineer and this is what he had to say:

----------------
Well, it depends on what's meant by "thread safe". There are mutex locks on
the shared data structures so it should be technically "thread safe" though
this is mostly untested. Even if it passed all tests though, the mutex
locks would make it much slower than it would need to be if we used a more
fine-grained approach.
------------------

what experience are you having with our gem not being threadsafe that is a
problem? We certainly run a lot of copies of it on the same servers at the
same time under very high load ourselves."

I presume this now leaves a "he said, she said" situation, and I might need
to dig up some more information and help make a better case to New Relic.
I'll take care of writing it up and doing as much work as I can since I'm a
customer, but if anyone has any ideas on a retort, I'd welcome the advice.

Also, if I have phrased the question incorrectly or perhaps not been
nuanced enough in my request, I'm welcome to correction. I thought I'd let
the team know. If there's anything I can do to help, please send me a
message.

Thanks,

Hank

Re: [sidekiq] Sidekiq and New Relic, New Relic responds to my request

From:
Mike Perham
Date:
2012-10-12 @ 02:24
I've been told by the ruby agent developer himself that I'd have to roll 
my own thread safety. I guess we can look at the rpm client code and see 
for ourselves. 

On 11 Oct 2012, at 19:07, Hank Beaver <hbeaver@gmail.com> wrote:

> I sent a request to New Relic, who I use for many servers. I wanted to 
see if I could help a little like was suggested on the Wiki, 
https://github.com/mperham/sidekiq/wiki/Problems-and-Troubleshooting. 
> 
> Here was my request to New Relic:
> 
> "Subject: Is there planned support for threadsafe Ruby Agent/GEM?
> 
> We have transitioned to Sidekiq (http://mperham.github.com/sidekiq/) 
which uses Ruby 1.9 threads. It has come to our attention from the Sidekiq
team that newrelic_rpm gem is not threadsafe. This obviously impacts our 
application and can have the potential for causing major issues. Is there 
any plan to make the gem threadsafe?
> Thanks, 
> Hank"
> 
> This was the response from New Relic:
> 
> "I hadn't heard that our gem wasn't threadsafe, so we asked our senior 
Java agent engineer and this is what he had to say:
> 
> ---------------- 
> Well, it depends on what's meant by "thread safe". There are mutex locks
on the shared data structures so it should be technically "thread safe" 
though this is mostly untested. Even if it passed all tests though, the 
mutex locks would make it much slower than it would need to be if we used 
a more fine-grained approach. 
> ------------------
> 
> what experience are you having with our gem not being threadsafe that is
a problem? We certainly run a lot of copies of it on the same servers at 
the same time under very high load ourselves."
> 
> I presume this now leaves a "he said, she said" situation, and I might 
need to dig up some more information and help make a better case to New 
Relic. I'll take care of writing it up and doing as much work as I can 
since I'm a customer, but if anyone has any ideas on a retort, I'd welcome
the advice.
> 
> Also, if I have phrased the question incorrectly or perhaps not been 
nuanced enough in my request, I'm welcome to correction. I thought I'd let
the team know. If there's anything I can do to help, please send me a 
message.
> 
> Thanks,
> 
> Hank
> 
> 
> 
> 

Re: [sidekiq] Sidekiq and New Relic, New Relic responds to my request

From:
Hank Beaver
Date:
2012-10-12 @ 02:27
Oh well. I'll let my pair know. Perhaps we can help out some. Thanks for
all the great work!

H

On Thu, Oct 11, 2012 at 10:24 PM, Mike Perham <mperham@gmail.com> wrote:

> I've been told by the ruby agent developer himself that I'd have to roll
> my own thread safety. I guess we can look at the rpm client code and see
> for ourselves.
>
>
> On 11 Oct 2012, at 19:07, Hank Beaver <hbeaver@gmail.com> wrote:
>
> I sent a request to New Relic, who I use for many servers. I wanted to see
> if I could help a little like was suggested on the Wiki,
> https://github.com/mperham/sidekiq/wiki/Problems-and-Troubleshooting.
>
> Here was my request to New Relic:
>
> "Subject: Is there planned support for threadsafe Ruby Agent/GEM?
>
>  We have transitioned to Sidekiq (http://mperham.github.com/sidekiq/)
> which uses Ruby 1.9 threads. It has come to our attention from the Sidekiq
> team that newrelic_rpm gem is not threadsafe. This obviously impacts our
> application and can have the potential for causing major issues. Is there
> any plan to make the gem threadsafe?
>
> Thanks,
> Hank"
>
> This was the response from New Relic:
>
> "I hadn't heard that our gem wasn't threadsafe, so we asked our senior
> Java agent engineer and this is what he had to say:
>
> ----------------
> Well, it depends on what's meant by "thread safe". There are mutex locks
> on the shared data structures so it should be technically "thread safe"
> though this is mostly untested. Even if it passed all tests though, the
> mutex locks would make it much slower than it would need to be if we used a
> more fine-grained approach.
> ------------------
>
> what experience are you having with our gem not being threadsafe that is a
> problem? We certainly run a lot of copies of it on the same servers at the
> same time under very high load ourselves."
>
> I presume this now leaves a "he said, she said" situation, and I might
> need to dig up some more information and help make a better case to New
> Relic. I'll take care of writing it up and doing as much work as I can
> since I'm a customer, but if anyone has any ideas on a retort, I'd welcome
> the advice.
>
> Also, if I have phrased the question incorrectly or perhaps not been
> nuanced enough in my request, I'm welcome to correction. I thought I'd let
> the team know. If there's anything I can do to help, please send me a
> message.
>
> Thanks,
>
> Hank
>
>
>
>