> The short version is that logging showed up in hello world benchmarks
> and as a result some optimisation, of questionable real world utility,
> took place.  Buffering up a bunch of writes into a single write does
> make a difference though and it seems mostly harmless.

I've been working quite extensively with logging recently and can also
confirm that there is little if any performance benefit from
BufferedLogger's buffering (buffering can improve performance, but not
the way BufferedLogger does it). Its only real advantage is grouping
together the log messages from each request. There are also bugs with
the implementation in multi-threaded applications addressed here
https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/6671.

> You can set your own logger instance in application.rb if you want to
> use something simpler / customised.

My problem with Rails logging has always been that it is way too
sparse in that messages are logged without any sort of context
(timestamp, process id, log level). This can make interpreting logs
from a busy application quite painful and makes buffering necessary to
provide some sort of context by grouping all messages from each
request.

Logging has always been one of the least customizable and rudimentary
parts of Rails. It is true that you can swap out different logging
solutions, but it practice it either requires monkey patching
BufferedLogger or reimplementing all of its methods. I would advocate
that Rails should use something like the lumberjack gem (http://
github.com/bdurand/lumberjack) in place of BufferedLogger. This sort
of architecture would provide Rails with a standard, supported logging
interface, and allow for better log formats and a simpler means of
writing messages to non-file based devices (syslog, mongodb, etc.).

Brian

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Reply via email to