Ruslan,<div><br></div><div>I guess what I was getting at is I don't think the SQL queries are the problem here.  The sum (by using your perl code) was 0.324813 seconds, much less than 4 seconds.</div><div><br></div><div>
I'm still trying different Apache settings, Postgresql settings, etc., but here's a different way to explain the issue:</div><div><br></div><div>I can click on Home, then click on a ticket, then Home, then a ticket, etc., for as long as I want and it is very fast (page load time is about 0.2-0.3 seconds).</div>
<div><br></div><div>If I wait for about 5 seconds, I can continue this without any change.</div><div><br></div><div>If I wait for even 10 seconds, or 30 seconds, or anything longer, when I click on either Home or a ticket, the page takes about 2-4 seconds to load. This will happen for both the Home page and a ticket Display page the first time they are each displayed, and after that they are very fast again.  This is why it seems to me it has to be an Apache or Mason cache/timeout issue.  It's almost like it's compiling or building something again, which is why I originally was drawn to the Javascript minifier suggestion.</div>
<div><br></div><div>I really appreciate your advice on this.</div><div><br></div><div>-Nate</div><div><br><div class="gmail_quote">On Wed, May 30, 2012 at 3:49 PM, Ruslan Zakirov <span dir="ltr"><<a href="mailto:ruz@bestpractical.com" target="_blank">ruz@bestpractical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, May 30, 2012 at 10:15 PM, Nathan Baker <<a href="mailto:bakern@gmail.com">bakern@gmail.com</a>> wrote:<br>

> Ruslan,<br>
><br>
</div><div class="im">> I wasn't aware that sessions had to be cleared, but now that you mentioned<br>
> it I looked and there were almost 10k sessions in our table.  I cleared that<br>
> out and it does not seem to be slow in that section anymore.  I've also<br>
> added that command to crontab to run daily.<br>
><br>
> It seems much better after doing that, I don't see any pages taking over 3-4<br>
> seconds to load anymore.  I do still see some taking about 2-3 seconds to<br>
> load.  That is more usable, although I would like to get it better if<br>
> possible.  I turned on logging of SQL statements in RT only for now, I'm not<br>
> as familiar with Postgresql as I am with MySQL, but I could look into<br>
> logging in there if necessary.<br>
><br>
> We only have about 5 staff using the RT web interface.  The longest queries<br>
> I see are still fairly quick I think, but here are a couple examples of the<br>
> longer ones for Display.html:<br>
><br>
> [Wed May 30 17:52:44 2012] [debug]: SQL(0.136027s): SELECT  * FROM Groups<br>
> WHERE LOWER(Domain) = LOWER(?) AND LOWER(Type) = LOWER(?);  [ bound values:<br>
> 'SystemInternal' 'Privileged' ]<br>
> (/usr/share/request-tracker4/lib/RT/Interface/Web.pm:1115)<br>
<br>
</div>This one is sort of "known issue". We have code paths where LOWER is<br>
used and is not used, but indexes for Pg on Groups table don't account<br>
this. Proper way would be to collect as many queries as possible that<br>
select or join Groups table, do analysis and come up with set of<br>
indexes for the table. I would love to take a look at such log.<br>
<br>
For this particular query index on LOWER(Domain) would be enough or<br>
(LOWER(Domain), LOWER(Type)) pair.<br>
<div class="im"><br>
> [Wed May 30 17:49:20 2012] [debug]: SQL(0.387888s): SELECT DISTINCT main.*<br>
> FROM Users main JOIN Principals Principals_1  ON ( Principals_1.id = <a href="http://main.id" target="_blank">main.id</a><br>
> ) JOIN CachedGroupMembers CachedGroupMembers_2  ON (<br>
> CachedGroupMembers_2.MemberId = Principals_1.id )  WHERE<br>
> (Principals_1.Disabled = '0') AND (CachedGroupMembers_2.GroupId = '25472')<br>
> AND (CachedGroupMembers_2.Disabled = '0') AND<br>
> (LOWER(Principals_1.PrincipalType) = 'user')  ORDER BY main.Name ASC ;<br>
> (/usr/share/request-tracker4/lib/RT/Interface/Web.pm:1115)<br>
<br>
</div>Hard to tell anything without EXPLAIN ANALYZE... This query selects<br>
users who are not disabled and recursive members of a group. Select<br>
from Groups by id to see how important this query is.<br>
<div class="im"><br>
> Here is an example summary of a page load (with SQL logging on and Mason<br>
> profiling off) for Display.html:<br>
> 48 Queries<br>
> 4.1 Seconds page load<br>
> Longest query:<br>
> [Wed May 30 17:56:19 2012] [debug]: SQL(0.118095s): SELECT  * FROM Groups<br>
> WHERE LOWER(Domain) = LOWER(?) AND LOWER(Type) = LOWER(?);  [ bound values:<br>
> 'SystemInternal' 'Unprivileged' ]<br>
> (/usr/share/request-tracker4/lib/RT/Interface/Web.pm:1115)<br>
><br>
> All other queries < 0.1 seconds, most are < 0.01 seconds<br>
<br>
</div>Use the following command to calculate how much time all 48 queries took:<br>
<br>
cat part.of.rt.log | perl -ne '$res += (/SQL\(([0-9.]+s)\)/)[0] || 0;<br>
END { print "$res\n"}'<br>
<br>
Question is how close the sum to 4 seconds.<br>
<br>
> Thanks,<br>
<div class="HOEnZb"><div class="h5">> Nate<br>
<br>
--<br>
Best regards, Ruslan.<br>
</div></div></blockquote></div><br></div>