My CGI is slow, but I don't think it's my fault.

[jimt]

For some reason, my website has gotten progressively slower over the last few months. I don't think I've changed anything to yield these results.

Here's what I know - the scripts run lightning fast hosted on my local machine. Now, while I love my powerbook dearly, it is, admittedly, not exactly state of the art. Yes, yes, I know that I'm the only one hitting the webserver and I don't need to worry about network latency. I was sure to bring down a fresh database from the live site to be sure to compare identical data. Still. I ran it through Devel::DProf, and got this:

Total Elapsed Time = 2.282964 Seconds
  User+System Time = 1.392964 Seconds

Not too shabby. I can live with that. So then I ran the same thing through Devel::DProf on the hosted site:

Total Elapsed Time = 18.89348 Seconds
  User+System Time = 0.793482 Seconds

Eek. Behold the disastrous slowdown. And now I'm stumped. If my User+System Time were high, then no sweat - slog through the code, find slow things, optimize 'em away. Fun stuff. But this? This is external, and out of my control. Right?

So basically, I'm ruling out network problems, database issues, and generally anything in my script and seem to be at a point of blaming my host. FWIW, it's 1&1. So their hardware should be absolutely massive. But what could this be indicative of? Some sort of throttling? Restrictions? Essentially, before I begrudgingly begin the long, annoying path of switching hosts, I want to know if there's something - anything else I could/should be looking at to spare me the pain.

[perrin]

It probably just means the database on your host is very slow. How about showing us the rest of that DProf output, sorted by wall time? Then it would be obvious where the time was going.

[jimt]

And Perrin gets the gold star. Right on both counts.

Re-profiling with dprofpp -r (d'oh. There's an option which I'll need to remember) yielded:

Total Elapsed Time = 22.28669 Seconds
         Real Time = 22.28669 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c  Name
 59.2   13.20 13.200    314   0.0420 0.0420  DBI::db::ping

Basically, every time it tried to grab a cached database handle, it would ping it first to make sure it was still valid. Useful in persistent environments (mod_perl, etc.) or long running scripts, but not so much on a website that's all CGI and nothing survives long. I figured I could take the risk of having the database handle vanish in that time, so I shut off the constant re-pinging.

Next profile dropped the total run time down to 5.45 seconds, with 83% of my time spent executing queries. Much more reasonable. And I'm sure I can get that runtime down even farther with some judicious indexing.

Thanks!

[hangon]

Hosting companies try to put as many sites as they can on each box. You may be seeing the effect of increasing traffic to the server where your site is hosted, due to adding more sites and/or existing sites drawing more traffic. One thing you can try is asking them to move your account to a different server.

[rhesa]

It doesn't necessarily need to be the host (a sleep 18 in your code would give similar timing), but it does sound like a system issue.

Have you checked how busy that machine is? Check some of these commands:

uptime
free
ulimit
df -H
ps aux

You get the idea.

If those aren't the issue, is connecting to the database a problem? Opening sockets? What else does your code do that interacts with the OS?

[thezip]

You may want to write and install a *very* simple program that recreates/demonstrates the problem, but removes all of the complexity of the main CGI application...

[kyle]

Some sort of throttling? Restrictions?

Have you asked them?