[rt-users] long page load times with many comments, was: is SELECT GET_LOCK normal?
On Thu, Dec 4, 2008 at 5:07 PM, Micah Gersten <[EMAIL PROTECTED]> wrote: > I had this problem about a month ago. Search the archives for: Apache > Session locking taking a while > You should see some info on a possible fix. Thanks, yes. Although, that seems like a hack of some kind. The select lock's go away when I changed 3006 to 1 in [1] but the page still takes almost 90 seconds to load. Switching from mod_perl to fastcgi didn't affect the load time, nor did switching mysql from the default my.cnf to huge.cnf. I'm using the default mpm-prefork settings but increasing them doesn't appear to decrease the load time. I feel like something in the process isn't threading enough and causing a bottleneck but I'm unsure as to what's left. Will keep digging. Bryan [1] /usr/share/perl5/Apache/Session/Lock/MySQL.pm ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] long page load times with many comments, was: is SELECT GET_LOCK normal?
Could you check if ShowMessageStanza from 3.8 repository [1] improves situation? See also comments below. On Fri, Dec 5, 2008 at 4:21 AM, Bryan McLellan <[EMAIL PROTECTED]> wrote: > On Thu, Dec 4, 2008 at 5:07 PM, Micah Gersten <[EMAIL PROTECTED]> wrote: >> I had this problem about a month ago. Search the archives for: Apache >> Session locking taking a while >> You should see some info on a possible fix. > > Thanks, yes. Although, that seems like a hack of some kind. The select > lock's go away when I changed 3006 to 1 in [1] but the page still > takes almost 90 seconds to load. It's certainly a hack that doesn't improve performance in any way. > Switching from mod_perl to fastcgi didn't affect the load time, nor MP and FCGI are pretty close in speed. > did switching mysql from the default my.cnf to huge.cnf. I'm using the default my.cnf is not an option for any DB based application. > default mpm-prefork settings but increasing them doesn't appear to > decrease the load time. I feel like something in the process isn't > threading enough and causing a bottleneck but I'm unsure as to what's > left. Will keep digging. Start from identifying where RT spends more time during the request. > > Bryan [1] http://svn.bestpractical.com/cgi-bin/index.cgi/bps/view/rt/3.8/trunk/share/html/Ticket/Elements/ShowMessageStanza -- Best regards, Ruslan. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] long page load times with many comments, was: is SELECT GET_LOCK normal?
On Thu, Dec 4, 2008 at 6:06 PM, Ruslan Zakirov <[EMAIL PROTECTED]> wrote: > Could you check if ShowMessageStanza from 3.8 repository [1] improves > situation? See also comments below. > [1] > http://svn.bestpractical.com/cgi-bin/index.cgi/bps/view/rt/3.8/trunk/share/html/Ticket/Elements/ShowMessageStanza Installed this and restarted. Didn't change the time to load. Pretty stable at just under 90 seconds for this ticket. > Start from identifying where RT spends more time during the request. Turned on 'debug' logging to a file. When loading this ticket I see many lines like this: [Mon Dec 8 23:37:12 2008] [debug]: We found a merged ticket.1721/1698 (/opt/rt3/bin/../lib/RT/Ticket_Overlay.pm:185) After the first line, it will pause for one second, then print three more of the exact messages at the same time with the same timestamp as the first. Four messages every second for the 90 seconds it took for the ticket to load. After seeing this I opened up a few dozen tickets and watched the debugging log. Every ticket without merges took under two seconds, most of them a fraction of a second (short ones). Tickets with merges took 50-110 seconds. Definitely looks like some sort of recursive loop to do with parsing ticket merges. Bryan ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] long page load times with many comments, was: is SELECT GET_LOCK normal?
http://rt3.fsck.com//Ticket/Display.html?id=12774 On Tue, Dec 9, 2008 at 2:50 AM, Bryan McLellan <[EMAIL PROTECTED]> wrote: > On Thu, Dec 4, 2008 at 6:06 PM, Ruslan Zakirov <[EMAIL PROTECTED]> wrote: >> Could you check if ShowMessageStanza from 3.8 repository [1] improves >> situation? See also comments below. > >> [1] >> http://svn.bestpractical.com/cgi-bin/index.cgi/bps/view/rt/3.8/trunk/share/html/Ticket/Elements/ShowMessageStanza > > Installed this and restarted. Didn't change the time to load. Pretty > stable at just under 90 seconds for this ticket. > >> Start from identifying where RT spends more time during the request. > > Turned on 'debug' logging to a file. When loading this ticket I see > many lines like this: > > [Mon Dec 8 23:37:12 2008] [debug]: We found a merged ticket.1721/1698 > (/opt/rt3/bin/../lib/RT/Ticket_Overlay.pm:185) > > After the first line, it will pause for one second, then print three > more of the exact messages at the same time with the same timestamp as > the first. Four messages every second for the 90 seconds it took for > the ticket to load. > > After seeing this I opened up a few dozen tickets and watched the > debugging log. Every ticket without merges took under two seconds, > most of them a fraction of a second (short ones). Tickets with merges > took 50-110 seconds. Definitely looks like some sort of recursive loop > to do with parsing ticket merges. > > Bryan > -- Best regards, Ruslan. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] long page load times with many comments, was: is SELECT GET_LOCK normal?
On Mon, Dec 8, 2008 at 5:14 PM, Ruslan Zakirov <[EMAIL PROTECTED]> wrote: > http://rt3.fsck.com//Ticket/Display.html?id=12774 Note that to read that, login as guest/guest. That's it, thanks. Added this to RT_SiteConfig.pm. Set($LogToSyslog, 'info'); Also linked in that bug is a debian bug [1]. They also discuss that installing the debian package 'libsys-syslog-perl' should resolve this issue. Maybe RT_Config.pm should ship with LogToSyslog set to info as a general measure rather than related to this bug? Bryan [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498692 ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com