Performance Tuning

Scalability

Falcon uses an asynchronous event-driven reactor to provide non-blocking IO. It uses one Fiber per request, which have minimal overhead. Falcon can handle a large number of in-flight requests including long-running connections like websockets, HTTP/2 streaming, etc.

• Improving Ruby Concurrency – Comparison of Falcon and Puma.

Falcon Benchmark

The falcon-benchmark suite looks at how various servers respond to different levels of concurrency across several sample applications.

Memory Usage

Falcon uses async-container to start multiple copies of your application. Each instance of your application is isolated by default for maximum fault-tolerance. However, this can lead to increased memory usage. Preloading parts of your application reduce this overhead and in addition can improve instance start-up time. To understand your application memory usage, you should use process-metrics which take into account memory shared between processes.

Preloading

Falcon offers two mechanisms for preloading code.

Preloading Gems

By default, falcon will load all gems in the preload group:

# In gems.rb:

source "https://rubygems.org"

group :preload do
	# List any gems you want to be pre-loaded into the falcon process before forking.
end

Preloading Files

Create a file in your application called preload.rb. You can put this file anywhere in your application.

Falcon Serve

falcon serve has a --preload option which accepts the path to this file.

Falcon Host

falcon.rb applications may have a preload configuration option.

System Limitations

If you are expecting to handle many simultaneous connections, please ensure you configure your file limits correctly.

Errno::EMFILE: Too many open files - accept(2)

This means that your system is limiting the number of files that can be opened by falcon. Please check the ulimit of your system and set it appropriately.