Requiring grape hugely slows down Goliath - ruby

I've written a 'Hello World' app using Goliath, and I decided to mount Grape on top of it:
#!/usr/bin/env ruby
require 'rubygems'
require 'bundler/setup'
Bundler.setup :default
require 'goliath'
require 'grape' # <-- Comment out this line will hugely increase performance, but why?
class Server < Goliath::API
def response(env)
[200, {}, 'Hello, world!']
end
end
I benchmarked it:
ab -n 1000 -c 100 http://localhost:9000/
It shows that about 250 requests can be handled per second. But when I comment out the line require 'grape', this value suddenly increased to about 700. Can anybody answer why the simple require can bring such a huge difference?
P.S. I use MRI 2.2.2

Are you running Goliath in production mode? You have to set -e prod of it will do code re-loading on each request.

Related

Sinatra app executes during load instead of after run method issued

This is a stripped down example of a real app I am building. When I execute my app, this is the result I get. You'll notice that it says that it is running before it is starting. You'll also notice it never says running after the start is issued.
bundle exec rackup
Using thin;
Sapp::App running.
Starting Sapp::App
== Sinatra (v1.4.7) has taken the stage on 4567 for development with backup from Thin
Thin web server (v1.7.0 codename Dunder Mifflin)
Maximum connections set to 1024
Listening on localhost:4567, CTRL+C to stop
My config.ru is:
# http://www.rubydoc.info/gems/webmachine/Webmachine/Adapters/Rack
$started = false
require 'thin'
require 'sinatra'
set :server, (ENV['RACK_ENV'] == 'production' || ENV['RACK_ENV'] == 'staging' ? 'rack' : 'thin')
puts "Using #{settings.server};"
load 'webmachine/adapters/rack.rb'
load File.join(File.dirname(__FILE__), 'sapp.rb')
$started = true
puts 'Starting Sapp::App'
#Sapp::App.run!
Sinatra::Application.run!
I am setting $started just to try to fix this problem, but it doesn't help. My app is executed before it is set. I could control that but, and this is the rub, it does not execute after the run is issued.
sapp.rb is:
ENV['RACK_ENV'] ||= 'development'
Bundler.setup
$: << File.expand_path('../', __FILE__)
$: << File.expand_path('../lib', __FILE__)
require 'dotenv'
Dotenv.load(
File.expand_path("../.env.#{ENV['RACK_ENV']}", __FILE__),
File.expand_path("../.env", __FILE__))
module Sapp
class App < Sinatra::Application
puts 'Sapp::App has been started.' if $started
puts 'Sapp::App running.'
end
end
In the end, if nothing else, Once it says "Starting Sapp::App", it should also say "Sapp::App has been started." and "Sapp::App running."
For the record, both these options do the same thing:
Sapp::App.run!
Sinatra::Application.run!
Okay, I get it. I put the code in a class, but not it a method. Load or require both run open code like this. I need to wrap it in methods, and execute the methods, to do what I want to do.
Sinatra examples, which I followed, don't make this clear and simply avoid the topic. Many are so simple it doesn't make a difference, and some are just coded within the config.ru. I am coming from Rails and, while I knew this from Rails, it didn't make much of a difference since the vast majority of the code already exists in methods.

Goliath not being asynchronous

I am running a simple goliath server on my localhost with Ruby 1.9.3, and it's not running http requests asynchronously. Here's the code:
require 'goliath'
require 'em-synchrony'
require 'em-synchrony/em-http'
class Server < Goliath::API
use Goliath::Rack::Validation::RequestMethod, %w(GET PUT POST)
def initialize
super
puts "Started up Bookcover server... Let 'em come!"
end
def response(env)
thumbnail_cover_url, large_book_cover_url = ["http://riffle-bookcovers.s3.amazonaws.com/B00GJYXA5I-thumbnail.jpg", "http://riffle-bookcovers.s3.amazonaws.com/B00GJYXA5I-original.jpg"]
puts "start"
a = EM::HttpRequest.new(thumbnail_cover_url).get
b = EM::HttpRequest.new(large_book_cover_url).get
puts "done"
[200, {}, "Hello World"]
end
end
When I run ab -n 100 http://127.0.0.1:9000/ I can see it waits for each request to be done, which means that the calls are blocking.
However, according to the documentation Goliath uses Em-synchrony to let me write "synchronous-looking" code, which is not the case here.
I would appreciate any hints and comments!
Credits go to igrigorik for the answer. I quote from his answer here:
You also need to specify the concurrency level when you run ab... e.g.
ab -c 10 :)
Also, make sure you run it in production mode (-e prod).

Why this sinatra code is not working

I'm having a hard time figuring out what I'm doing wrong here. The result is empty and I'm looking it to return hello (calling the method testing through the before helper).
require 'rubygems'
require 'sinatra'
get '/' do
end
before do
testing
end
def testing
return "hello"
end
There are several problems here. For one thing you have to actually call the output or variable you want in the view, most typically as an instance variable (otherwise every user gets the same output.) Take the modified code below for example:
require 'rubygems'
require 'sinatra'
get '/' do
#word
end
before do
testing
end
def testing
#word = "hello"
end
Check out the Sinatra Book, a free online resource, for information on getting started with Sinatra.
Because you are not calling the output on the Get request, you need to tell your Get Method to return an output. Like thekungfuman suggested. or try the Minimal Hello World Sinatra app as follows:
#imports
require 'rubygems'
require 'sinatra'
#Get Request on Root ("/")
get '/' do
"Hello Sinatra World!"
end
Also it's useful to put your program under a class, so you can also do :
#imports
require 'rubygems'
require 'sinatra/base'
#My Application Class
class AppName < Sinatra::base
get '/' do
'Hello Sinatra World!'
end
end
AppName.run!
This way you can also use this as a seperate app file and import it within other files like.
require 'app_name' #replace this with the name of the physical file
#Run Application "AppName"
AppName.run!

Do not necessary require(s) matter?

I want to be able to have one ruby file that can require all the common dependencies, so that other files can just have one require on this shared file.for example; I have foo.rb and bar.rb and allrequires.rb. I want to have the line require "allrequires.rb" in both foo.rb and bar.rb, but bar.rb doesn't need all the requires.
Does it matter if I use require in .rb file that do not really require that file? Could it have an impact on performance maybe?
I am currently on ruby 1.8.7 (2010-08-16 patchlevel 302) [i386-mingw32]
Update
It looks like it is not the best idea to 'share'/use all requires in both .rb files. What would be solution to that?
Right now I can think of using file name in a condition.
There's two main performance penalties:
The time taken to do the require itself. In Ruby 1.9.1 and Ruby 1.9.2, the time taken to do all the requires had worse than linear scalability - if you doubled the number of requires, it took you more than twice as long - I think it took you four times as long.
The time taken to execute the code in the file being required. If you have code like the following, then executing the code will take a non-trivial amount of time.
class MyClass
MY_CONSTANT = File.read("data.txt")
end
Another approach of conditional requiring, the following script gives no error on the JSON parser because it is named require1.rb, in scripts that have no name like require1.rb of script2.rb the gem isn't required
require 'json' if "require1.rb, script2.rb"[File.basename(__FILE__)]
p File.basename(__FILE__)
text = '[{ "name" : "car", "status": "good"}, { "name" : "bus", "status": "bad"},{ "name" : "taxi", "status": "soso"},
{"noname":"", "status" : "worse"}
]'
data = JSON.parse(text)
p data.collect { |item| item['name'] }
EDIT: here a version that uses an array
["require1.rb","script1.rb"].find{|script|require 'json' if script===File.basename(__FILE__)}
Yes, there will be a speedpanalty, you can benchmark how mutch to consider if it realy matters.
With multiple require's i put hem in my code like this so that it doens't take much screenspace.
['green_shoes','Hpricot'].each(&method(:require))
You could also do a conditional require, but that would be ugly having all around your code
begin
data = JSON.parse(text)
rescue
require 'json_pure'
data = JSON.parse(text)
end
So in short, give each rb its own require's
My final solution is (in case someone finds it useful):
requires.rb is called from web.rb or testweb.rb, rufus.rb or testrufus.rb
called_from=caller[0].split(":")[0]
puts "loading web 'requires' for file: #{called_from} ..." if (["web"].any?{|s| called_from[s]})
puts "loading web 'requires' for file: #{called_from} ..." if (["rufus"].any?{|s| called_from[s]})
puts "loading web 'requires' for file: #{called_from} ..." if (["settings"].any?{|s| called_from[s]})
require 'rubygems'
require 'socket' if (["web","settings"].any?{|s| called_from[s]})
require 'ruby-growl' if (["web","settings","rufus"].any?{|s| called_from[s]})
require 'sinatra' if (["web"].any?{|s| called_from[s]})
Thank you #Andrew for the explanation and #peter for the hint how to solve this.

Using Sinatra for larger projects via multiple files

It seems that in Sinatra all route handlers are being written into a single file, if I understand right it acts as a one large/small controller. Is there any way to split it into separate independent files, so when let's say somebody calls "/" - one action is executed, and if smth like "/posts/2" is received then another action - similar logic that is applied in PHP?
Here is a basic template for Sinatra apps that I use. (My larger apps have 200+ files broken out like this, not counting vendor'd gems, covering 75-100 explicit routes. Some of these routes are Regexp routes covering an additional 50+ route patterns.) When using Thin, you run an app like this using:
thin -R config.ru start
Edit: I'm now maintaining my own Monk skeleton based on the below called Riblits. To use it to copy my template as the basis for your own projects:
# Before creating your project
monk add riblits git://github.com/Phrogz/riblits.git
# Inside your empty project directory
monk init -s riblits
File Layout:
config.ru
app.rb
helpers/
init.rb
partials.rb
models/
init.rb
user.rb
routes/
init.rb
login.rb
main.rb
views/
layout.haml
login.haml
main.haml
config.ru
root = ::File.dirname(__FILE__)
require ::File.join( root, 'app' )
run MyApp.new
app.rb
# encoding: utf-8
require 'sinatra'
require 'haml'
class MyApp < Sinatra::Application
enable :sessions
configure :production do
set :haml, { :ugly=>true }
set :clean_trace, true
end
configure :development do
# ...
end
helpers do
include Rack::Utils
alias_method :h, :escape_html
end
end
require_relative 'models/init'
require_relative 'helpers/init'
require_relative 'routes/init'
helpers/init.rb
# encoding: utf-8
require_relative 'partials'
MyApp.helpers PartialPartials
require_relative 'nicebytes'
MyApp.helpers NiceBytes
helpers/partials.rb
# encoding: utf-8
module PartialPartials
def spoof_request(uri,env_modifications={})
call(env.merge("PATH_INFO" => uri).merge(env_modifications)).last.join
end
def partial( page, variables={} )
haml page, {layout:false}, variables
end
end
helpers/nicebytes.rb
# encoding: utf-8
module NiceBytes
K = 2.0**10
M = 2.0**20
G = 2.0**30
T = 2.0**40
def nice_bytes( bytes, max_digits=3 )
value, suffix, precision = case bytes
when 0...K
[ bytes, 'B', 0 ]
else
value, suffix = case bytes
when K...M then [ bytes / K, 'kiB' ]
when M...G then [ bytes / M, 'MiB' ]
when G...T then [ bytes / G, 'GiB' ]
else [ bytes / T, 'TiB' ]
end
used_digits = case value
when 0...10 then 1
when 10...100 then 2
when 100...1000 then 3
else 4
end
leftover_digits = max_digits - used_digits
[ value, suffix, leftover_digits > 0 ? leftover_digits : 0 ]
end
"%.#{precision}f#{suffix}" % value
end
module_function :nice_bytes # Allow NiceBytes.nice_bytes outside of Sinatra
end
models/init.rb
# encoding: utf-8
require 'sequel'
DB = Sequel.postgres 'dbname', user:'bduser', password:'dbpass', host:'localhost'
DB << "SET CLIENT_ENCODING TO 'UTF8';"
require_relative 'users'
models/user.rb
# encoding: utf-8
class User < Sequel::Model
# ...
end
routes/init.rb
# encoding: utf-8
require_relative 'login'
require_relative 'main'
routes/login.rb
# encoding: utf-8
class MyApp < Sinatra::Application
get "/login" do
#title = "Login"
haml :login
end
post "/login" do
# Define your own check_login
if user = check_login
session[ :user ] = user.pk
redirect '/'
else
redirect '/login'
end
end
get "/logout" do
session[:user] = session[:pass] = nil
redirect '/'
end
end
routes/main.rb
# encoding: utf-8
class MyApp < Sinatra::Application
get "/" do
#title = "Welcome to MyApp"
haml :main
end
end
views/layout.haml
!!! XML
!!! 1.1
%html(xmlns="http://www.w3.org/1999/xhtml")
%head
%title= #title
%link(rel="icon" type="image/png" href="/favicon.png")
%meta(http-equiv="X-UA-Compatible" content="IE=8")
%meta(http-equiv="Content-Script-Type" content="text/javascript" )
%meta(http-equiv="Content-Style-Type" content="text/css" )
%meta(http-equiv="Content-Type" content="text/html; charset=utf-8" )
%meta(http-equiv="expires" content="0" )
%meta(name="author" content="MeWho")
%body{id:#action}
%h1= #title
#content= yield
Absolutely. To see an example of this I recommend downloading the Monk gem, described here:
https://github.com/monkrb/monk
You can 'gem install' it via rubygems.org. Once you have the gem, generate a sample app using the instructions linked above.
Note that you don't have to use Monk for your actual development unless you want to (in fact I think it may not be current). The point is to see how you can easily structure your app in the MVC style (with separate controller-like route files) if you want to.
It's pretty simple if you look at how Monk handles it, mostly a matter of requiring files in separate directories, something like (you'll have to define root_path):
Dir[root_path("app/**/*.rb")].each do |file|
require file
end
Do a Google search for "Sinatra boilerplate" to get some ideas for how others are laying out their Sinatra applications. From that you can probably find one that suits your needs or simply make your own. It's not too hard to do. As you develop more Sinatra apps, you can add to your boilerplate.
Here's what I made and use for all of my projects:
https://github.com/rziehl/sinatra-boilerplate
I know this is an old query but I still can't believe no one mentioned Padrino You can use it as a framework on top of Sinatra, or piecemeal adding only the gems that interest you. It kicks ten buttloads of ass!
The key for modularity on Sinatra for larger projects is learning to use the underlying tools.
SitePoint has a very good tutorial from where you can see modular Sinatra apps and helpers. However you should pay special attention to one important detail. You keep multiple Sinatra apps and mount them with Rackup. Once you know how to write a basic app look at the config.ru file of that tutorial and observe how they mount independent Sinatra apps.
Once you learn to run Sinatra with Rack a whole new world of modularity strategies will open up. This obviously invites to try something really useful: now you can rely on having individual Gems for each sub application, what might enable you to easily version your modules.
Do not underestimate the power of using gem-modules for your app. You can easily test experimental changes in a well delimited environment and easily deploy them. Equally easy to revert back if something goes wrong.
There are a thousand ways to organize your code, so it would not hurt trying to get a layout similar to Rails. However there are also some great posts about how to customize your own structure. That post covers other frequent needs of most web developers.
If you have the time, I encourage you to learn more about Rack, the common ground for any Ruby based web application. It might have a far lesser impact in how you do your work, but there are always certain tasks that most people do on their apps that fits better as a Rack middleware.
My approach to host different projects on the same site is to use sinatra/namespace in such way:
server.rb
require "sinatra"
require "sinatra/namespace"
if [ENV["LOGNAME"], ENV["USER"]] == [nil, "naki"]
require "sinatra/reloader"
register Sinatra::Reloader
set :port, 8719
else
set :environment, :production
end
for server in Dir.glob "server_*.rb"
require_relative server
end
get "/" do
"this route is useless"
end
server_someproject.rb
module SomeProject
def self.foo bar
...
end
...
end
namespace "/someproject" do
set :views, settings.root
get "" do
redirect request.env["REQUEST_PATH"] + "/"
end
get "/" do
haml :view_someproject
end
post "/foo" do
...
SomeProject.foo ...
end
end
view_someproject.haml
!!!
%html
...
Another detail about subprojects I used was to add their names, description and routes to some kind of global variable, that is used by "/" to make a guide homepage, but I don't have a snippet right now.
Reading the docs here:
Sinatra Extensions
It appears that Sinatra allows you to decompose your application into Ruby Modules, which can be pulled in through the Sinatra "register" method or "helpers" methods, like so:
helpers.rb
require 'sinatra/base'
module Sinatra
module Sample
module Helpers
def require_logged_in()
redirect('/login') unless session[:authenticated]
end
end
end
end
routing/foos.rb
require 'sinatra/base'
module Sinatra
module Sample
module Routing
module Foos
def self.registered(app)
app.get '/foos/:id' do
# invoke a helper
require_logged_in
# load a foo, or whatever
erb :foos_view, :locals => { :foo => some_loaded_foo }
end
end
end
end
end
end
app.rb
#!/usr/bin/env ruby
require 'sinatra'
require_relative 'routing/foos'
class SampleApp < Sinatra::Base
helpers Sinatra::Sample::Helpers
register Sinatra::Sample::Routing::Foos
end
When Monk didn't work for me, I started working on templates myself.
If you think about it, there is nothing special about tying up a set of files. The monk philosophy was explained to me early in 2011 during RedDotRubyConf and they have specifically told me that it's really optional to use it especially now that it's hardly maintained.
This is a good start for those who want to use ActiveRecord:
Simple Sinatra MVC
https://github.com/katgironpe/simple-sinatra-mvc

Resources