derailed_benchmarks 1.0.1 → 1.1.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: f00460799a696f7a1779ea6bbb4a6d0bbb4e0612
-  data.tar.gz: 96d81116a29b5211015581af27c3b69ede4fd125
+  metadata.gz: 64e1d95c4daabc83570c1b4414e12e825d412224
+  data.tar.gz: a199e5d200e859f53aaeb25326d98325a860e959
 SHA512:
-  metadata.gz: b8d8d3c5a56696af7327a6ef4fbb927c04956a38dfced8d07ee229209eeb68beb00c047dbc317e0c6cff7a2685170305b65895e8a3d3ddb1c53ee93e4cf1a221
-  data.tar.gz: fdd8db66a4a0f2937b32d31a1ec3dca308c76d80ef337e6a0e817666bf0e127849083e0b594974324627a09dd86fec93e4c0443f89051018a2d02e6047a0e3ca
+  metadata.gz: 5e0e983995112c57ce5925e75ff3e2fc1491ecad771f6445158688872625887710299e42cc20650a323f39c891459b99520b61475059efc97e8ebf5f2598dc70
+  data.tar.gz: b4f2972a0bb9cd35a6bd7b26fd070638b34c4a0e1f403bb2dee84f0dc913df5aae9dfb465a549097c55c9fa54504bc25dbc54f1455e3037da0c1f254e49b4423

data/CHANGELOG.md

@@ -1,5 +1,11 @@
 # A Log of Changes!
 
+## [1.1.0] - 2015-09-09
+
+- Set custom auth user using a lambda in perf.rake
+- Changed `perf:ram_over_time` changed to `perf:mem_over_time`
+- Fixed gem warnings
+
 ## [1.0.1] - 2015-20-06
 
 - `bundle:mem` and similar tasks now keep track of duplicate requires and display them along side of memory requirements. This makes it easier to identify where components are used by multiple libraries

data/Gemfile.lock

@@ -1,12 +1,13 @@
 PATH
   remote: .
   specs:
-    derailed_benchmarks (1.0.1)
+    derailed_benchmarks (1.1.0)
       benchmark-ips (~> 2)
       get_process_mem (~> 0)
       memory_profiler (~> 0)
       rack (~> 1)
       rake (~> 10)
+      thor (~> 0.19)
 
 GEM
   remote: https://rubygems.org/
@@ -40,7 +41,7 @@ GEM
       multi_json (~> 1.0)
     arel (3.0.3)
     bcrypt (3.1.10)
-    benchmark-ips (2.2.0)
+    benchmark-ips (2.3.0)
     builder (3.0.4)
     capybara (2.4.4)
       mime-types (>= 1.16)
@@ -64,7 +65,7 @@ GEM
     mail (2.5.4)
       mime-types (~> 1.16)
       treetop (~> 1.4.8)
-    memory_profiler (0.9.1)
+    memory_profiler (0.9.4)
     mime-types (1.25.1)
     mini_portile (0.6.2)
     multi_json (1.11.0)
@@ -131,3 +132,6 @@ DEPENDENCIES
   rails (~> 3)
   sqlite3
   test-unit (~> 3.0)
+
+BUNDLED WITH
+   1.10.6

data/README.md

@@ -4,6 +4,8 @@ A series of things you can use to benchmark a Rails or Ruby app.
 
 ![](http://media.giphy.com/media/lfbxexWy71b6U/giphy.gif)
 
+[![Build Status](https://travis-ci.org/schneems/derailed_benchmarks.svg)](https://travis-ci.org/schneems/derailed_benchmarks)
+
 ## Compatibility/Requirements
 
 This gem has been tested and is known to work with Rails 3.2+ using Ruby
@@ -33,7 +35,7 @@ While executing your commands you may need to use `bundle exec` before typing th
 To use all profiling methods available also add:
 
 ```
-gem "stackprof", group: :development
+gem 'stackprof', group: :development
 ```
 
 You must be using Ruby 2.1+ to install these libraries. If you're on an older version of Ruby, what are you waiting for?
@@ -55,13 +57,13 @@ For more information on the relationship between memory and performance please r
 Each gem you add to your project can increase your memory at boot. You can get visibility into the total memory used by each gem in your Gemfile by running:
 
 ```
-$ derailed bundle:mem
+$ bundle exec derailed bundle:mem
 ```
 
 This will load each of your gems in your Gemfile and see how much memory they consume when they are required. For example if you're using the `mail` gem. The output might look like this
 
 ```
-$ derailed bundle:mem
+$ bundle exec derailed bundle:mem
 TOP: 54.1836 MiB
   mail: 18.9688 MiB
     mime/types: 17.4453 MiB
@@ -81,7 +83,7 @@ Here we can see that `mail` uses 18MiB, with the majority coming from `mime/type
 By default this task will only return results from the `:default` and `"production"` groups. If you want a different group you can run with.
 
 ```
-$ derailed bundle:mem development
+$ bundle exec derailed bundle:mem development
 ```
 
 You can use `CUT_OFF=0.3` to only show files that have above a certain memory useage, this can be used to help eliminate noise.
@@ -91,7 +93,7 @@ Note: This method won't include files in your own app, only items in your Gemfil
 The same file may be required by several libraries, since Ruby only requires files once, the cost is only associated with the first library to require a file. To make this more visible duplicate entries will list all the parents they belong to. For example both `mail` and `fog` require `mime/types. So it may show up something like this in your app:
 
 ```
-$ derailed bundle:mem
+$ bundle exec derailed bundle:mem
 TOP: 54.1836 MiB
   mail: 18.9688 MiB
     mime/types: 17.4453 MiB (Also required by: fog/storage)
@@ -111,7 +113,7 @@ fog/joyent: 0.7227 MiB
 
 If you want to see everything that requires `fog/core` you can run `CUT_OFF=0 bundle exec derailed bundle:mem` to get the full output that you can then grep through manually.
 
-Update: While `mime/types` looks horible in these examples, it's been fixed. You can add this to the top of your gemfile for free memory:
+Update: While `mime/types` looks horrible in these examples, it's been fixed. You can add this to the top of your gemfile for free memory:
 
 ```ruby
 gem 'mime-types', '~> 2.4.3', require: 'mime/types/columnar'
@@ -122,7 +124,7 @@ gem 'mime-types', '~> 2.4.3', require: 'mime/types/columnar'
 To get more info about the objects, using [memory_profiler](https://github.com/SamSaffron/memory_profiler), created when your dependencies are required you can run:
 
 ```
-$ derailed bundle:objects
+$ bundle exec derailed bundle:objects
 ```
 
 This will output detailed information about objects created while your dependencies are loaded
@@ -145,7 +147,7 @@ Once you identify a gem that creates a large amount of memory using `$ derailed
 By default this task will only return results from the `:default` and `"production"` groups. If you want a different group you can run with.
 
 ```
-$ derailed bundle:objects development
+$ bundle exec derailed bundle:objects development
 ```
 
 Note: This method won't include files in your own app, only items in your Gemfile. For that you'll need to use `derailed exec objects`. See below for more info.
@@ -155,7 +157,7 @@ Note: This method won't include files in your own app, only items in your Gemfil
 
 This benchmarking will attempt to boot your Rails app and run benchmarks against it. Unlike the static benchmarking with `$ derailed bundle:*` these will include information about your specific app. The pro is you'll get more information and potentially identify problems in your app code, the con is that it requires you to be able to boot and run your application in a `production` environment locally, which for some apps is non-trivial.
 
-You may want to check out [mini-profiler](https://github.com/MiniProfiler/rack-mini-profiler), here's a [mini-profiler walkthrough](http://www.justinweiss.com/blog/2015/05/11/a-new-way-to-understand-your-rails-apps-performance/?utm_source=rubyweekly&utm_medium=email). It's great and does slightly different benchmarking than what you'll find here.
+You may want to check out [mini-profiler](https://github.com/MiniProfiler/rack-mini-profiler), here's a [mini-profiler walkthrough](http://www.justinweiss.com/blog/2015/05/11/a-new-way-to-understand-your-rails-apps-performance). It's great and does slightly different benchmarking than what you'll find here.
 
 ### Running in Production Locally.
 
@@ -167,7 +169,7 @@ For starters try booting into a console:
 $ RAILS_ENV=production rails console
 ```
 
-You may get errors, complaining about not being able to connect to the `production` database. For this, you can either create a local database with the name of your production database, or you can copy the info from your `development` group to your `production` groupu in your `database.yml`.
+You may get errors, complaining about not being able to connect to the `production` database. For this, you can either create a local database with the name of your production database, or you can copy the info from your `development` group to your `production` group in your `database.yml`.
 
 You may be missing environment variables expected in `production` such as `SECRET_KEY_BASE`. For those you can either commit them to your `.env` file (if you're using one). Or add them directly to the command:
 
@@ -183,10 +185,10 @@ $ RAILS_ENV=production rails server
 
 You may need to disable enforcing SSL or other domain restrictions temporarially. If you do these, don't forget to add them back in before deploying any code (eek!).
 
-You can get information from STDOUT if you're using `rails_12factor` gem, or from `logs/production.log` by running
+You can get information from STDOUT if you're using `rails_12factor` gem, or from `log/production.log` by running
 
 ```
-$ tail -f logs/production.log
+$ tail -f log/production.log
 ```
 
 Once you've fixed all errors and you can run a server in production, you're almost there.
@@ -202,7 +204,7 @@ $ derailed exec --help
   $ derailed exec perf:ips  # iterations per second
   $ derailed exec perf:mem  # show memory usage caused by invoking require per gem
   $ derailed exec perf:objects  # profiles ruby allocation
-  $ derailed exec perf:ram_over_time  # outputs ram usage over time
+  $ derailed exec perf:mem_over_time  # outputs memory usage over time
   $ derailed exec perf:test  # hits the url TEST_COUNT times
 ```
 
@@ -214,13 +216,13 @@ Instead of going over each command we'll look at common problems and which comma
 If your app appears to be leaking ever increasing amounts of memory, you'll want to first verify if it's an actual unbound "leak" or if it's just using more memory than you want. A true memory leak will increase memory use forever, most apps will increase memory use until they hit a "plateau". To diagnose this you can run:
 
 ```
-$ derailed exec perf:ram_over_time
+$ bundle exec derailed exec perf:mem_over_time
 ```
 
 This will boot your app and hit it with requests and output the memory to stdout (and a file under ./tmp). It may look like this:
 
 ```
-$ derailed exec perf:ram_over_time
+$ bundle exec derailed exec perf:mem_over_time
 Booting: production
 Endpoint: "/"
 PID: 78675
@@ -239,9 +241,9 @@ PID: 78675
 Here we can see that while the memory use is increasing, it levels off around 183 MiB. You'll want to run this task using ever increasing values of `TEST_COUNT=` for example
 
 ```
-$ TEST_COUNT=5000 derailed exec perf:ram_over_time
-$ TEST_COUNT=10_000 derailed exec perf:ram_over_time
-$ TEST_COUNT=20_000 derailed exec perf:ram_over_time
+$ TEST_COUNT=5000 derailed exec perf:mem_over_time
+$ TEST_COUNT=10_000 derailed exec perf:mem_over_time
+$ TEST_COUNT=20_000 derailed exec perf:mem_over_time
 ```
 
 Adjust your counts appropriately so you can get results in a reasonable amount of time. If your memory never levels off, congrats! You've got a memory leak! I recommend copying and pasting values from the file generated into google docs and graphing it so you can get a better sense of the slope of your line.
@@ -255,7 +257,7 @@ If you're pretty sure that there's a memory leak, but you can't confirm it using
 If you've identified a memory leak, or you simply want to see where your memory use is coming from you'll want to use
 
 ```
-$ derailed exec perf:objects
+$ bundle exec derailed exec perf:objects
 ```
 
 This task hits your app and uses memory_profiler to see where objects are created. You'll likely want to run once, then run it with a higher `TEST_COUNT` so that you can see hotspots where objects are created on __EVERY__ request versus just maybe on the first.
@@ -267,7 +269,7 @@ $ TEST_COUNT=10 derailed exec perf:objects
 
 This is an expensive operation, so you likely want to keep the count lowish. Once you've identified a hotspot read [how ruby uses memory](http://www.sitepoint.com/ruby-uses-memory/) for some tips on reducing object allocations.
 
-This is is similar to `$ derailed bundle:objects` however it includes objects created at runtime. It's much more useful for actual production performance debugging, the other is more useful for library authors to debug.
+This is is similar to `$ bundle exec derailed bundle:objects` however it includes objects created at runtime. It's much more useful for actual production performance debugging, the other is more useful for library authors to debug.
 
 
 ### Memory Is large at boot.
@@ -278,7 +280,7 @@ This task does essentially the same thing, however it hits your app with one req
 
 
 ```
-$ derailed exec perf:mem
+$ bundle exec derailed exec perf:mem
 
 TOP: 54.1836 MiB
   mail: 18.9688 MiB
@@ -300,7 +302,7 @@ Well...aren't they all. If you've already looked into decreasing object allocati
 One technique is to use a "sampling" stack profiler. This type of profiling looks at what method is being executed at a given interval and records it. At the end of execution it counts all the times a given method was being called and shows you the percent of time spent in each method. This is a very low overhead method to looking into execution time. Ruby 2.1+ has this available in gem form it's called [stackprof](https://github.com/tmm1/stackprof). As you guessed you can run this with derailed benchmarks, first add it to your gemfile `gem "stackprof", group: :development` then execute:
 
 ```
-$ derailed exec perf:stackprof
+$ bundle exec derailed exec perf:stackprof
 ==================================
   Mode: cpu(1000)
   Samples: 16067 (1.07% miss rate)
@@ -342,7 +344,7 @@ From here you can dig into individual methods.
 Micro benchmarks might tell you at the code level how much faster something is, but what about the overall application speed. If you're trying to figure out how effective a performance change is to your application, it is useful to compare it to your existing app performance. To help you with that you can use:
 
 ```
-$ derailed exec perf:ips
+$ bundle exec derailed exec perf:ips
 Endpoint: "/"
 Calculating -------------------------------------
                  ips     1.000  i/100ms
@@ -355,7 +357,7 @@ This will hit an endpoint in your application using [benchmark-ips](https://gith
 If you care you can also run pure benchmark (without ips):
 
 ```
-$ derailed exec perf:test
+$ bundle exec derailed exec perf:test
 ```
 
 But I wouldn't, benchmark-ips is a better measure.
@@ -371,7 +373,7 @@ All the tasks accept configuration in the form of environment variables.
 For tasks that are run a number of times you can set the number using `TEST_COUNT` for example:
 
 ```
-$ derailed exec perf:test TEST_COUNT=100_000
+$ TEST_COUNT=100_000 bundle exec derailed exec perf:test
 ```
 
 ## Hitting a different endpoint with `PATH_TO_HIT`
@@ -387,7 +389,7 @@ $ PATH_TO_HIT=/users/new derailed exec perf:mem
 All tests are run without a webserver (directly using `Rack::Mock` by default), if you want to use a webserver set `USE_SERVER` to a Rack::Server compliant server, such as `webrick`.
 
 ```
-$ USE_SERVER=webrick derailed exec perf:mem
+$ USE_SERVER=webrick bundle exec derailed exec perf:mem
 ```
 
 Or
@@ -408,7 +410,7 @@ change this if your app doesn't run locally with `RAILS_ENV` set to
 `production`. For example:
 
 ```
-$ derailed exec perf:mem RAILS_ENV=development
+$ RAILS_ENV=development bundle exec derailed exec perf:mem 
 ```
 
 ## perf.rake
@@ -469,7 +471,7 @@ If you're trying to test an endpoint that has authentication you'll need to tell
 To enable authentication in a test run with:
 
 ```
-$ USE_AUTH=true derailed exec perf:mem
+$ USE_AUTH=true bundle exec derailed exec perf:mem
 ```
 
 See below how to customize authentication.
@@ -487,7 +489,7 @@ $ cat perf.rake
 If you want you can customize the user that is logged in by setting that value in your `perf.rake` file.
 
 ```
-DerailedBenchmarks.auth.user = User.find_or_create!(twitter: "schneems")
+DerailedBenchmarks.auth.user = -> { User.find_or_create!(twitter: "schneems") }
 ```
 
 You will need to provide a valid user, so depending on the validations you have in your `user.rb`, you may need to provide different parameters.

data/derailed_benchmarks.gemspec

@@ -23,6 +23,7 @@ Gem::Specification.new do |gem|
   gem.add_dependency "benchmark-ips",   "~> 2"
   gem.add_dependency "rack",            "~> 1"
   gem.add_dependency "rake",            "~> 10"
+  gem.add_dependency "thor",            "~> 0.19"
 
   gem.add_development_dependency "capybara", "~> 2"
   gem.add_development_dependency "rails",    "~> 3"

data/lib/derailed_benchmarks/auth_helpers/devise.rb

@@ -4,7 +4,7 @@ module DerailedBenchmarks
     # Setup adds necessarry test methods, user provides a sample user.
     # The authenticate method is called on every request when authentication is enabled
     class Devise < AuthHelper
-      attr_accessor :user
+      attr_writer :user
 
       # Include devise test helpers and turn on test mode
       # We need to do this on the class level
@@ -19,9 +19,12 @@ module DerailedBenchmarks
       end
 
       def user
-        @user ||= begin
+        if @user
+          @user = @user.call if @user.is_a?(Proc)
+          @user
+        else
           password = SecureRandom.hex
-          User.first_or_create!(email: "#{SecureRandom.hex}@example.com", password: password, password_confirmation: password)
+          @user = User.first_or_create!(email: "#{SecureRandom.hex}@example.com", password: password, password_confirmation: password)
         end
       end
 

data/lib/derailed_benchmarks/tasks.rb

@@ -97,6 +97,8 @@ namespace :perf do
 
   desc "hits the url TEST_COUNT times"
   task :test => [:setup] do
+    require 'benchmark'
+
     Benchmark.bm { |x|
       x.report("#{TEST_COUNT} requests") {
         TEST_COUNT.times {
@@ -145,15 +147,15 @@ namespace :perf do
     TOP_REQUIRE.print_sorted_children
   end
 
-  desc "outputs ram usage over time"
-  task :ram_over_time => [:setup] do
+  desc "outputs memory usage over time"
+  task :mem_over_time => [:setup] do
     require 'get_process_mem'
     puts "PID: #{Process.pid}"
     ram = GetProcessMem.new
     @keep_going = true
     begin
       unless ENV["SKIP_FILE_WRITE"]
-        ruby = `ruby -v`
+        ruby = `ruby -v`.chomp
         FileUtils.mkdir_p("tmp")
         file = File.open("tmp/#{Time.now.iso8601}-#{ruby}-memory-#{TEST_COUNT}-times.txt", 'w')
         file.sync = true
@@ -178,6 +180,11 @@ namespace :perf do
     end
   end
 
+  task :ram_over_time do
+    Kernel.warn("The ram_over_time task is deprecated. Use mem_over_time")
+    Rake::Task["perf:ram_over_time"].invoke
+  end
+
   desc "iterations per second"
   task :ips => [:setup] do
     require 'benchmark/ips'
@@ -248,6 +255,8 @@ namespace :perf do
     num = Integer(ENV["TEST_COUNT"] || 1)
     opts = {}
     opts[:ignore_files] = /#{ENV['IGNORE_FILES_REGEXP']}/ if ENV['IGNORE_FILES_REGEXP']
+    opts[:allow_files]  = "#{ENV['ALLOW_FILES']}"         if ENV['ALLOW_FILES']
+
     puts "Running #{num} times"
     report = MemoryProfiler.report(opts) do
       num.times { call_app }

data/lib/derailed_benchmarks/version.rb

@@ -1,3 +1,3 @@
 module DerailedBenchmarks
-  VERSION = "1.0.1"
+  VERSION = "1.1.0"
 end

data/test/integration/tasks_test.rb

@@ -36,6 +36,12 @@ class TasksTest < ActiveSupport::TestCase
     assert_match 'Server: "webrick"', result
   end
 
+  test 'authenticate with a custom user' do
+    env = { "AUTH_CUSTOM_USER" => "true", "PATH_TO_HIT" => "authenticated", "USE_AUTH" => "true", "TEST_COUNT" => "2" }
+    result = rake 'perf:test', env: env
+    assert_match 'Auth: true', result
+  end
+
   test 'test' do
     rake "perf:test"
   end
@@ -72,11 +78,11 @@ class TasksTest < ActiveSupport::TestCase
     rake "perf:mem"
   end
 
-  test 'ram_over_time' do
-    rake "perf:ram_over_time"
+  test 'mem_over_time' do
+    rake "perf:mem_over_time"
   end
 
   test 'ips' do
-    rake "perf:ram_over_time"
+    rake "perf:mem_over_time"
   end
 end

data/test/rails_app/perf.rake

@@ -2,3 +2,7 @@ $LOAD_PATH << File.expand_path("../../../lib", __FILE__)
 
 require 'derailed_benchmarks'
 require 'derailed_benchmarks/tasks'
+
+if ENV['AUTH_CUSTOM_USER']
+  DerailedBenchmarks.auth.user = -> { User.first_or_create!(email: "user@example.com", password: 'password') }
+end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: derailed_benchmarks
 version: !ruby/object:Gem::Version
-  version: 1.0.1
+  version: 1.1.0
 platform: ruby
 authors:
 - Richard Schneeman
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2015-06-20 00:00:00.000000000 Z
+date: 2015-09-09 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: memory_profiler
@@ -80,6 +80,20 @@ dependencies:
     - - "~>"
       - !ruby/object:Gem::Version
         version: '10'
+- !ruby/object:Gem::Dependency
+  name: thor
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.19'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.19'
 - !ruby/object:Gem::Dependency
   name: capybara
   requirement: !ruby/object:Gem::Requirement
@@ -222,7 +236,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 2.4.5
+rubygems_version: 2.4.5.1
 signing_key: 
 specification_version: 4
 summary: Benchmarks designed to performance test your ENTIRE site