dmytro/nagira

Increase Max thread count. Performance Tuning of Nagira/Sinatra for _full call.

Opened this issue · 4 comments

hvyas commented

How could we do performance improvement of Nagira / Sinatra frame work to get better results. We have certain integrations that are utilizing Nagira to get the _full dump but its taking lot of time (output is approximately 45MB size). many times in a day it fails with 500 internal error - particularly there are overlapping _full calls:
"GET /_status/_full HTTP/1.1" 500 30 15.5245"

Often I'm seeing below in nagira.logs so I was wondering if I can increase the max thread count (or something similar) to achieve better performance? I've much beefier box.

Snippet form the logs:
Puma 2.8.2 starting...

  • Min threads: 0, max threads: 16
  • Environment: production
  • Listening on tcp://0.0.0.0:4567
    == Sinatra/1.4.5 has taken the stage on 4567 for production with backup from Puma
dmytro commented

Hmm... Probably not easy. Currently there's only single thread responding to HTTP requests and another background thread for file parsing. I'll need to see how Puma works to make several HTTP threads talking to the same parsing thread.

Let me see.

hvyas commented

Thanks so much @dmytro for your quick response! Appreciate your help.

I can spin up another issue if required for this query - but wanted to check if Nagira can communicate to multiple Nagios servers (so that we can have Nagira as top layer) since we have 10-15 Nagios servers.

dmytro commented

No, Nagira itself cannot 'talk' to Nagios. It's only parsing Nagios data
files on the filesystem, so it is physically limited to single server.

But Nagira can sit on multiple servers, then you would need to write some
integration, that will talk to Nagira API. That was actually main driver to
develop Nagira.

For example, you could have Rails application collecting data from multiple
Nagira servers.

Dmytro Kovalov
http://dmytro.github.com

2015-05-13 18:32 GMT+09:00 hvyas notifications@github.com:

How could we do performance improvement of Nagira / Sinatra frame work to
get better results. We have certain integrations that are utilizing Nagira
to get the _full dump but its taking lot of time (output is approximately
45MB size). many times in a day it fails with 500 internal error -
particularly there are overlapping _full calls:
"GET /_status/_full HTTP/1.1" 500 30 15.5245"

Often I'm seeing below in nagira.logs so I was wondering if I can increase
the max thread count (or something similar) to achieve better performance?
I've much beefier box.

Snippet form the logs:
Puma 2.8.2 starting...

  • Min threads: 0, max threads: 16
  • Environment: production
  • Listening on tcp://0.0.0.0:4567 == Sinatra/1.4.5 has taken the stage
    on 4567 for production with backup from Puma

—
Reply to this email directly or view it on GitHub
#33.

hvyas commented

Makes sense! thanks again!