Requests handled very slowly
Arnout Engelen
I recently installed calagator, and it is very slow - so slow that
this is certainly a problem with my installation rather than with the
software itself. Being new to Ruby, however, I'm at a loss as to where
to look.
I started calagator as documented with './script/server'. Looking at
the firebug 'net view', requests usually take between 5 and 55 seconds
(!). Looking at the server logging, however, it says 'completed in
6ms', which looks fine. It appears it takes a while until the server
actually starts handling the request.
Does anyone have any idea what could cause this? What more information
do you need? The server is Debian Linux (lenny with some ruby
backports installed), the client Ubuntu Linux with Firefox. The client
can visit other (non-ruby) sites on the same server without trouble.
Memory and CPU load don't seem particulary high.
Regards,
Arnout
Igal Koshevoy
> I started calagator as documented with './script/server'. Looking at
> the firebug 'net view', requests usually take between 5 and 55 seconds
> (!). Looking at the server logging, however, it says 'completed in
> 6ms', which looks fine. It appears it takes a while until the server
> actually starts handling the request.
>
webserver and disables caching and other performance optimizations. When
you run a real server, you'll want to application in the much faster
"production" mode using something like Phusion Passenger
(http://www.modrails.com/) or Thin (http://code.macournoyer.com/thin/)
or Unicorn (http://unicorn.bogomips.org/).
Firebug makes pages appear to be much slower than they really are.
However, even these shouldn't slow down the app as much as you're
describing. Pages load in under a second for me on development mode
through Firebug.
I suspect that there's something else going on with your server:
Is the app as slow if you access it directly from your server, e.g.,
using elinks/lynx to run a browser?
If you keep hitting "reload" in this server-side web browser, is the
Ruby process the thing that's consuming your CPU?
Are you running out of memory and swapping?
Are you proxying requests through something that could be slowing it down?
Is your server just old/slow or gives you very limited CPU cycles, e.g.,
Dreamhost shared hosting?
Etc.
-igal
Arnout Engelen
> Arnout Engelen wrote:
> > Looking at
> > the firebug 'net view', requests usually take between 5 and 55 seconds
> > (!).
>
> However, even these shouldn't slow down the app as much as you're
> describing. Pages load in under a second for me on development mode
> through Firebug.
> I suspect that there's something else going on with your server:
Agreed.
> Is the app as slow if you access it directly from your server, e.g.,
> using elinks/lynx to run a browser?
Yes, same behaviour.
> If you keep hitting "reload" in this server-side web browser, is the
> Ruby process the thing that's consuming your CPU?
CPU usage basically remains low.
> Are you running out of memory and swapping?
> Are you proxying requests through something that could be slowing it down?
> Is your server just old/slow or gives you very limited CPU cycles, e.g.,
> Dreamhost shared hosting?
3x nope... it's a 1ghz machine with ~1g memory and plenty of swap, not
doing very heavy tasks. Other sites (php, perl) on the same machine
are not slow. If it'd be resources like this, I'd expect the server
logging to report long response times, too, instead of fairly quick
ones (i.e. 'Completed in 5ms (View: 3, DB: 12)').
Arnout
Igal Koshevoy
hardware component like CPU, memory, disk, network, etc. Unless we can
isolate the component that's limiting performance, I'm unsure if we'll
be able to resolve this.
I'd like to see a complete log entry for one of these slow requests.
You'll want to start up the app (e.g. ./script/server) and access a URL
from it using a console-based web browser running on the same machine
until the app has begun responding, then request the page again now that
the app is running. Reply with the complete log entry for the final
request, e.g., if you hit the home page (http://localhost:3000/), look
for a log entry that starts with "Processing SiteController#index" and
continues till the first mention of "Completed in XXXms". Also report
about how many seconds this took in real time, especially if these are
significantly different.
You may also want to try the above while the app is running in "preview"
mode, which activates the "production" mode's optimizations but uses the
"development" database. You can start the app with `./script/server -e
preview` to do this. In this mode, the app should respond very quickly
once it's cached a page.
-igal
Sam Goldstein
--
You received this message because you are subscribed to the Google Groups "PDX Tech Calendar" group.
To post to this group, send email to pdx-tech...@googlegroups.com.
To unsubscribe from this group, send email to pdx-tech-calen...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pdx-tech-calendar?hl=en.
Arnout Engelen
On Jan 11, 8:09 pm, Arnout Engelen <arnout.enge...@gmail.com> wrote:
> On Jan 11, 2:28 am, Igal Koshevoy <i...@pragmaticraft.com> wrote:
> > Is the app as slow if you access it directly from your server, e.g.,
> > using elinks/lynx to run a browser?
>
> Yes, same behaviour.
Turns out you were right on the money here. I didn't realize webrick
is single-threaded, so when I performed some requests directly from
the server, they seemed slow because webrick was still stuck handling
some requests still running from the client.
Due to some local misconfiguration (which i haven't fully tracked down
yet), (reverse) DNS requests apparently made by webrick somehow timed
out or failed, very, slowly. That's a pretty credible explanation of
slowness without excessive resource usage.
Adding the following to script/server:
require 'socket'
BasicSocket.do_not_reverse_lookup = true
... provided a working workaround for now, until i figure out what
exactly is wrong with my DNS setup (or replace webrick with a proper
webserver).
Thanks for all the pointers!
Regards,
Arnout
Sam Goldstein
Igal Koshevoy
> I'm happy to report I resolved my problem.
>
> I didn't realize webrick is single-threaded, so when I performed some requests directly from
> the server, they seemed slow because webrick was still stuck handling
> some requests still running from the client.
>
The single-threaded approach is actually quite common. The
./script/server is really just intended for development.
> Due to some local misconfiguration (which i haven't fully tracked down
> yet), (reverse) DNS requests apparently made by webrick somehow timed
> out or failed, very, slowly. That's a pretty credible explanation of
> slowness without excessive resource usage.
>
Yikes. You probably have a dead or slow DNS nameserver in your
/etc/resolve.conf. Try sending queries directly to servers listed there
using dig/nslookup/etc to identify which one's misbehaving, comment it
out or find a better one -- which may require talking to your hosting
provider -- and put the fastest nameserver at the top.
You may also want to install the Linux package for nscd, which
transparently caches all nameserver queries and thus makes repeat
requests very fast.
I've also read at various times that disabling IPv6 significantly helps
speed name resolution.
> Adding the following to script/server:
>
> require 'socket'
> BasicSocket.do_not_reverse_lookup = true
>
> ... provided a working workaround for now, until i figure out what
> exactly is wrong with my DNS setup
Interesting workaround.
> or replace webrick with a proper webserver
>
If you use "thin", a good Ruby web server (sudo gem install thin), you
can run "rake server:help" and it'll help you generate the config files,
and then you'll be able to run "rake server:start" to start the server
instances, you'll probably want to call this from init.d or cron so that
it starts on boot. Thin will start listening to a range of ports, and
you'll just need to tell Apache or something else to proxy requests from
port 80 to these. I like "passenger" a lot, but installing it is more
invasive.
-igal