derailed_benchmarks 1.3.0 → 1.3.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: b7d529865331b3c126efb52e13518c229ee35404
-  data.tar.gz: 4fa199d4d5ca3ffe0c80b10a3ad42828ab5dc3bf
+  metadata.gz: c95cc3fd294dd14030ec457fcd746aa388a7de20
+  data.tar.gz: 643e3f6d830fd7b0e256b484eef779d68f7e2b1a
 SHA512:
-  metadata.gz: e6ef7f085eff11d02879fa383d2084d4fd437feace36a75e3182bc159980c5e21be3d277fd841c7efa675d269d4c3eed0cf3e46ec4d2dbd47faf28dbc1ceb63b
-  data.tar.gz: 1fc3922d1ac62bf7d3b22b0234f51dac5e7ef93ccdc025f4041ef156db9fcc022bd384f0e093d57b452286222241b01de6eeb6662a756948a605c767cbdc87cd
+  metadata.gz: be87224b84945a0c9e9dec491647df53b2371de77b6c2fd4af672c63743a9e9137fe59b9da7d4d8a96f7ab610e49fb3a220eec6b930d87e09c965051ffbcda85
+  data.tar.gz: bbce0a2c86379d1e2a8a2f1bc278fb6982415a3af58263ce17d62a093632ec50ccabc4ab34972871c339646d85ff609833fa884d2803883792f8dceb9acc980c

data/CHANGELOG.md

@@ -1,5 +1,10 @@
 # A Log of Changes!
 
+## [1.3.1]
+
+- Allow for use with Rack 11.
+
+
 ## [1.3.0] - 2015-01-07
 
 - Allow environment variable to skip Active Record setup.

data/Gemfile.lock

@@ -1,13 +1,13 @@
 PATH
   remote: .
   specs:
-    derailed_benchmarks (1.3.0)
+    derailed_benchmarks (1.3.1)
       benchmark-ips (~> 2)
       get_process_mem (~> 0)
       heapy (~> 0)
       memory_profiler (~> 0)
       rack (>= 1)
-      rake (~> 10)
+      rake (> 10, < 12)
       thor (~> 0.19)
 
 GEM
@@ -42,7 +42,7 @@ GEM
       multi_json (~> 1.0)
     arel (3.0.3)
     bcrypt (3.1.10)
-    benchmark-ips (2.3.0)
+    benchmark-ips (2.5.0)
     builder (3.0.4)
     capybara (2.4.4)
       mime-types (>= 1.16)

data/README.md

@@ -42,7 +42,7 @@ You must be using Ruby 2.1+ to install these libraries. If you're on an older ve
 
 ## Use
 
-There are two ways to use benchmark an app. Derailed can either try to boot your web app and run requests against it while benchmarking, or it can statically give you more information about the dependencies that are in your Gemfile. Booting your app will always be more accurate, but if you cannot get your app to run in production locally, you'll still find the static information useful.
+There are two ways to benchmark an app. Derailed can either try to boot your web app and run requests against it while benchmarking, or it can statically give you more information about the dependencies that are in your Gemfile. Booting your app will always be more accurate, but if you cannot get your app to run in production locally, you'll still find the static information useful.
 
 ## Static Benchmarking
 
@@ -75,8 +75,8 @@ TOP: 54.1836 MiB
 
 _Aside: A "MiB", which is the [IEEE] and [IEC] symbol for Mebibyte, is 2<sup>20</sup> bytes / 1024 Kibibytes (which are in turn 1024 bytes)._
 
-[IEEE]: http://en.wikipedia.org/wiki/IEEE_1541-2002
-[IEC]: http://en.wikipedia.org/wiki/IEC_80000-13
+[IEEE]: https://en.wikipedia.org/wiki/IEEE_1541-2002
+[IEC]: https://en.wikipedia.org/wiki/IEC_80000-13
 
 Here we can see that `mail` uses 18MiB, with the majority coming from `mime/types`. You can use this information to prune out large dependencies you don't need. Also if you see a large memory use by a gem that you do need, please open up an issue with that library to let them know (be sure to include reproduction instructions). Hopefully as a community we can identify memory hotspots and reduce their impact. Before we can fix performance problems, we need to know where those problems exist.
 
@@ -88,7 +88,7 @@ $ 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.
 
-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 mem`. See below for more info.
+Note: This method won't include files in your own app, only items in your Gemfile. For that you'll need to use `bundle exec derailed exec mem`. See below for more info.
 
 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:
 
@@ -101,7 +101,7 @@ TOP: 54.1836 MiB
     mail/message: 0.3906 MiB
 ```
 
-That way you'll know that simply removing the top level library (mail) would not result in a memory reduction. The output is trucated after the first two entries:
+That way you'll know that simply removing the top level library (mail) would not result in a memory reduction. The output is truncated after the first two entries:
 
 
 ```
@@ -141,7 +141,7 @@ allocated memory by gem
    8103432  json-1.8.2
 ```
 
-Once you identify a gem that creates a large amount of memory using `$ derailed bundle:mem` you can pull that gem into it's own Gemfile and run `$ derailed bundle:objects` to get detailed information about it. This information can be used by contributors and library authors to identify and eliminate object creation hotspots.
+Once you identify a gem that creates a large amount of memory using `$ bundle exec derailed bundle:mem` you can pull that gem into it's own Gemfile and run `$ bundle exec derailed bundle:objects` to get detailed information about it. This information can be used by contributors and library authors to identify and eliminate object creation hotspots.
 
 
 By default this task will only return results from the `:default` and `"production"` groups. If you want a different group you can run with.
@@ -150,14 +150,14 @@ By default this task will only return results from the `:default` and `"producti
 $ 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.
+Note: This method won't include files in your own app, only items in your Gemfile. For that you'll need to use `bundle exec derailed exec objects`. See below for more info.
 
 
 ## Dynamic app Benchmarking
 
-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.
+This benchmarking will attempt to boot your Rails app and run benchmarks against it. Unlike the static benchmarking with `$ bundle exec 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). 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/articles/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.
 
@@ -198,7 +198,7 @@ Once you've fixed all errors and you can run a server in production, you're almo
 You can run commands against your app by running `$ derailed exec`. There are sections on setting up Rack and using authenticated requests below. You can see what commands are available by running:
 
 ```
-$ derailed exec --help
+$ bundle exec derailed exec --help
   $ derailed exec perf:allocated_objects  # outputs allocated object diff after app is called TEST_COUNT times
   $ derailed exec perf:gc  # outputs GC::Profiler.report data while app is called TEST_COUNT times
   $ derailed exec perf:ips  # iterations per second
@@ -241,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:mem_over_time
-$ TEST_COUNT=10_000 derailed exec perf:mem_over_time
-$ TEST_COUNT=20_000 derailed exec perf:mem_over_time
+$ TEST_COUNT=5000 bundle exec derailed exec perf:mem_over_time
+$ TEST_COUNT=10_000 bundle exec derailed exec perf:mem_over_time
+$ TEST_COUNT=20_000 bundle exec 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.
@@ -264,7 +264,7 @@ This task hits your app and uses memory_profiler to see where objects are create
 
 
 ```
-$ TEST_COUNT=10 derailed exec perf:objects
+$ TEST_COUNT=10 bundle exec 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.
@@ -273,7 +273,7 @@ This is is similar to `$ bundle exec derailed bundle:objects` however it include
 
 ## I want a Heap Dump
 
-If you're still struggling with runtime memory you can generate a heap dump that can later be analyzed using [heap_inspect](https://github.com/schneems/heap_inspect).
+If you're still struggling with runtime memory you can generate a heap dump that can later be analyzed using [heap_inspect](https://github.com/schneems/heapy).
 
 ```
 $ bundle exec derailed exec perf:heap
@@ -406,7 +406,7 @@ $ TEST_COUNT=100_000 bundle exec derailed exec perf:test
 By default tasks will hit your homepage `/`. If you want to hit a different url use `PATH_TO_HIT` for example if you wanted to go to `users/new` you can execute:
 
 ```
-$ PATH_TO_HIT=/users/new derailed exec perf:mem
+$ PATH_TO_HIT=/users/new bundle exec derailed exec perf:mem
 ```
 
 ### Using a real web server with USE_SERVER
@@ -420,7 +420,7 @@ $ USE_SERVER=webrick bundle exec derailed exec perf:mem
 Or
 
 ```
-$ USE_SERVER=puma derailed exec perf:mem
+$ USE_SERVER=puma bundle exec derailed exec perf:mem
 ```
 
 This boots a webserver and hits it using `curl` instead of in memory. This is useful if you think the performance issue is related to your webserver.

data/derailed_benchmarks.gemspec

@@ -23,7 +23,7 @@ Gem::Specification.new do |gem|
   gem.add_dependency "get_process_mem", "~> 0"
   gem.add_dependency "benchmark-ips",   "~> 2"
   gem.add_dependency "rack",            ">= 1"
-  gem.add_dependency "rake",            "~> 10"
+  gem.add_dependency "rake",            "> 10", "< 12"
   gem.add_dependency "thor",            "~> 0.19"
 
   gem.add_development_dependency "capybara", "~> 2"

data/lib/derailed_benchmarks/tasks.rb

@@ -80,7 +80,7 @@ namespace :perf do
       sleep 1
 
       def call_app(path = File.join("/", PATH_TO_HIT))
-        cmd = "curl http://localhost:#{@port}#{path} -s --fail 2>&1"
+        cmd = "curl 'http://localhost:#{@port}#{path}' -s --fail 2>&1"
         response = `#{cmd}`
         raise "Bad request to #{cmd.inspect} Response:\n#{ response.inspect }" unless $?.success?
       end

data/lib/derailed_benchmarks/version.rb

@@ -1,3 +1,3 @@
 module DerailedBenchmarks
-  VERSION = "1.3.0"
+  VERSION = "1.3.1"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: derailed_benchmarks
 version: !ruby/object:Gem::Version
-  version: 1.3.0
+  version: 1.3.1
 platform: ruby
 authors:
 - Richard Schneeman
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2016-01-07 00:00:00.000000000 Z
+date: 2016-03-24 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: heapy
@@ -84,16 +84,22 @@ dependencies:
   name: rake
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">"
       - !ruby/object:Gem::Version
         version: '10'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '12'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">"
       - !ruby/object:Gem::Version
         version: '10'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '12'
 - !ruby/object:Gem::Dependency
   name: thor
   requirement: !ruby/object:Gem::Requirement
@@ -250,7 +256,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 2.5.0
+rubygems_version: 2.5.1
 signing_key: 
 specification_version: 4
 summary: Benchmarks designed to performance test your ENTIRE site