Add attribution to the author

Closes #38648

guides/source/debugging_rails_applications.md

@@ -252,12 +252,13 @@ logger.tagged("BCX") { logger.tagged("Jason") { logger.info "Stuff" } } # Logs "
 ```
 
 ### Impact of Logs on Performance
+
 Logging will always have a small impact on the performance of your Rails app,
-        particularly when logging to disk. Additionally, there are a few subtleties:
+particularly when logging to disk. Additionally, there are a few subtleties:
 
 Using the `:debug` level will have a greater performance penalty than `:fatal`,
-      as a far greater number of strings are being evaluated and written to the
-      log output (e.g. disk).
+as a far greater number of strings are being evaluated and written to the
+log output (e.g. disk).
 
 Another potential pitfall is too many calls to `Logger` in your code:
 
@@ -269,6 +270,7 @@ In the above example, there will be a performance impact even if the allowed
 output level doesn't include debug. The reason is that Ruby has to evaluate
 these strings, which includes instantiating the somewhat heavy `String` object
 and interpolating the variables.
+
 Therefore, it's recommended to pass blocks to the logger methods, as these are
 only evaluated if the output level is the same as — or included in — the allowed level
 (i.e. lazy loading). The same code rewritten would be:
@@ -281,6 +283,9 @@ The contents of the block, and therefore the string interpolation, are only
 evaluated if debug is enabled. This performance savings are only really
 noticeable with large amounts of logging, but it's a good practice to employ.
 
+INFO: This section was written by [Jon Cairns at a StackOverflow answer](https://stackoverflow.com/questions/16546730/logging-in-rails-is-there-any-performance-hit/16546935#16546935)
+and it is licensed under [cc by-sa 4.0](https://creativecommons.org/licenses/by-sa/4.0/).
+
 Debugging with the `byebug` gem
 ---------------------------------