[rt-users] mod_perl vs fastcgi, which performs best, which is more scalable?
Jesse Vincent
jesse at bestpractical.com
Wed Jun 16 01:00:15 EDT 2004
On Tue, Jun 15, 2004 at 09:53:57PM -0700, Derek Suzuki wrote:
> I posted the details back when it happened, but nobody seemed to have any ideas. I assumed that there was something odd about our configuration that triggered the problem. MySQL was more or less idle and completely responsive at all times. Off the top of my head, the perl process seemed to be doing some sort of rapid polling that didn't produce any results. Typically we would see perl lock up for about 30-120 seconds 10-20 times per day. This was with five active administrators and about 100 tickets per day.
> I would guess that having multiple backend processes doesn't actually prevent the hangups, but it does allow other people to keep working without any visible problems.
>
That _sounds_ like users were asking for pages while still rendering
others. The user session handler puts a lock on the session while
a page is being generated to stop other processes from clobbering that
session. The symptom of a second process polling for a lock to be
released would look much like what you're seeing. But you'd want to use
a tool like "mytop" to see if there were actually mysql processes
spinning on locks.
>
> -----Original Message-----
> From: Jesse Vincent [mailto:jesse at bestpractical.com]
> Sent: Tue 6/15/2004 9:46 PM
> To: Derek Suzuki
> Cc: Charles Jones; rt-users at lists.bestpractical.com
> Subject: Re: [rt-users] mod_perl vs fastcgi, which performs best, which is more scalable?
>
>
>
>
> On Tue, Jun 15, 2004 at 09:43:57PM -0700, Derek Suzuki wrote:
> > I've been running on FastCGI since 3.0.7. Starting from 3.0.9 we have seen some horrendous performance problems (CPU pegging and effectively hanging the application for upwards of a minute) even on modern hardware with minimal workloads. We were able to work around them by pre-starting multiple server processes (the perl process is actually what seems to hang), and performance has been pretty good since then.
>
> Was the perl process waiting on anything? Was there a blocking database
> query? Did you attempt any sort of debugging of the actual problem?
>
> Thanks,
> Jesse
>
>
>
--
More information about the rt-users
mailing list