Notes:
== Synopsis
A C extension to ruby enabling fast escape/unescape of
URL Encoded Strings
== Usage
URLEscape.unescape("a%20string")
URLEscape.escape("a string")
Changes:
Rack::Utils and CGI escape and unescape performance boost
=========================================================
As performance boosts are about speed, we'll start with the
benchmarks. Here is a run of spec/bench.rb, from the url_escape
source tree.
Escape
------
user system total real
URLEscape::unescape 0.090000 0.000000 0.090000 ( 0.089190)
CGI::unescape 2.820000 0.000000 2.820000 ( 2.816234)
Rack::Utils::unescape 3.140000 0.000000 3.140000 ( 3.137291)
Unescape
--------
user system total real
URLEscape::escape 0.200000 0.000000 0.200000 ( 0.196100)
CGI::escape 3.830000 0.010000 3.840000 ( 3.828438)
Rack::Utils::escape 3.880000 0.010000 3.890000 ( 3.880745)
URLEscape provides these two methods as a C extension, suitable for
use on ruby 1.8.6-8 and 1.9.1+; tested on linux, XP, and Vista.
The jruby version uses the java stdlib's java.net.URLEncoder and
URLDecoder.
### Why?
We came across a bottleneck when regression testing FXC (a web app
which serves configuration information to the FreeSWITCH softswitch)
where requests were being delayed in our rack middleware, which parses
the POST data sent by FreeSWITCH and routes requests to the ramaze
application for processing. The delay was noticable under loads of
only 50 req/second, there rack became the bottleneck, not ramaze, the
db, or any other factor. Adding the above library (on linux, with
ruby 1.9.1) removed the delay in rack, pushing the work back to
to the web app where it's free to be as slow as it must.
### What else?
The ability of large posts to slow down a web application cannot be
removed by just speeding up the POST parser. In order to alleviate the
risk of such large POSTs being used to deny a service, firewall or
web server throttling or limiting is a more reliable protection to
enable. Here are a few examples:
* Lighttpd: http://lighttpd.net
* Offers mod_evasive which limits connections per ip, as well as
the ability to limit the data rate per connection.
* Nginx: http://nginx.org
* Flexible limiting system, per vhost, per user, per connection.
* Netfilter/QoS (linux): http://l7-filter.sourceforge.net/
* Allow classifiation of HTTP packets so iptables/tc or whatever
utility you'd like can have the info it needs about the HTTP
protocol to make limiting/dropping/queueing decisions
* Others: Apache, Squid, Litespeed, many others will have various methods
of limiting size and frequency of requests.
|
