Mailing-List: contact dev-help@allura.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@allura.apache.org
Received-SPF: pass (athena.apache.org: domain of noreply@sourceforge.net
 designates 216.34.181.60 as permitted sender)
Content-Type: multipart/related;
 boundary="===============5870378827336858985=="
MIME-Version: 1.0
To: dev@allura.apache.org
From: "Igor Bondarenko" <jetmind@users.sf.net>
Reply-To: "[allura:tickets] " <7566@tickets.allura.p.re.sf.net>
Subject: [allura:tickets] #7566 Milestone admin page can be very slow
Message-ID: 
 </p/allura/tickets/7566/a6180a92751db73f192db079bbdd0e7c59da7fbe.tickets@allura.p.sourceforge.net>
In-Reply-To: <53c00f9524b0d97f2fc8ecc0.tickets@allura.p.sourceforge.net>
References: <53c00f9524b0d97f2fc8ecc0.tickets@allura.p.sourceforge.net>
Date: Fri, 08 Aug 2014 11:22:24 +0000

--===============5870378827336858985==
Content-Type: multipart/alternative;
 boundary="===============5486344993038175436=="
MIME-Version: 1.0

--===============5486344993038175436==
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


With current approach I see about 40% boost in overall page load on test environment so it's pretty fine now (generated 5000 tickets with a [script](https://sourceforge.net/p/allura/pastebin/53e4b2c2bcf63a4cade1ecf2) to see the difference)

At first I had a concern about skipping permissions check for tickets with `acl=[]`, since if there's no acl for a ticket, permission checking logic checks acl in a parent security context (app_config in this example), and I thought there would be problems with this. Experimentally, though, it seems like it doesn't affect milestones page.

Second concern is that there's no index on acl, so those queries might be not so fast. So, if we stick with this approach, maybe we should add index on acl and see if it affects those queries.

But, I think that removing permissions checks entirely for this method would be great, since we're presenting only counts here, not tickets. Currently it's used only in two places:

- milestones edit view (which requires that user has a 'configure' permission, so there's a good chance that user is admin and can see all the tickets anyway)
- milestone individual view (e.g. `/p/test/tickets/milestone/2.0/`) - I see 2 counts here (one from pagination widget and a second one from `milestone_count()` and they do not match if  you not logged in as admin (both on master and on al/7566)

Also, I don't see a problem with those values mismatch, 'cause the `milestone_count()` used to represent the progress, and I believe anyone should be able to see a real counts in milestone progress, even if they don't have permissions to see some of actual tickets.

I think we also need Dave's opinion on this :)


---

** [tickets:#7566] Milestone admin page can be very slow**

**Status:** code-review
**Milestone:** forge-aug-8
**Labels:** performance 
**Created:** Fri Jul 11, 2014 04:23 PM UTC by Dave Brondsema
**Last Updated:** Thu Aug 07, 2014 07:48 AM UTC
**Owner:** Alexander Luberg

https://sourceforge.net/p/allura/tickets/milestones in particular is getting really slow.  I suspect its due to queries for the "Progress" column for every milestone.  Perhaps those can be run in a single mongo query somehow, or parallelize with threads.  Or just skipped for closed milestones.


---

Sent from sourceforge.net because dev@allura.apache.org is subscribed to https://sourceforge.net/p/allura/tickets/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/allura/admin/tickets/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.
--===============5486344993038175436==
MIME-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<div class="markdown_content"><p>With current approach I see about 40% boost in overall page load on test environment so it's pretty fine now (generated 5000 tickets with a <a class="" href="https://sourceforge.net/p/allura/pastebin/53e4b2c2bcf63a4cade1ecf2">script</a> to see the difference)</p>
<p>At first I had a concern about skipping permissions check for tickets with <code>acl=[]</code>, since if there's no acl for a ticket, permission checking logic checks acl in a parent security context (app_config in this example), and I thought there would be problems with this. Experimentally, though, it seems like it doesn't affect milestones page.</p>
<p>Second concern is that there's no index on acl, so those queries might be not so fast. So, if we stick with this approach, maybe we should add index on acl and see if it affects those queries.</p>
<p>But, I think that removing permissions checks entirely for this method would be great, since we're presenting only counts here, not tickets. Currently it's used only in two places:</p>
<ul>
<li>milestones edit view (which requires that user has a 'configure' permission, so there's a good chance that user is admin and can see all the tickets anyway)</li>
<li>milestone individual view (e.g. <code>/p/test/tickets/milestone/2.0/</code>) - I see 2 counts here (one from pagination widget and a second one from <code>milestone_count()</code> and they do not match if  you not logged in as admin (both on master and on al/7566)</li>
</ul>
<p>Also, I don't see a problem with those values mismatch, 'cause the <code>milestone_count()</code> used to represent the progress, and I believe anyone should be able to see a real counts in milestone progress, even if they don't have permissions to see some of actual tickets.</p>
<p>I think we also need Dave's opinion on this :)</p>
<hr />
<p><strong> <a class="alink" href="http://sourceforge.net/p/allura/tickets/7566">[tickets:#7566]</a> Milestone admin page can be very slow</strong></p>
<p><strong>Status:</strong> code-review<br />
<strong>Milestone:</strong> forge-aug-8<br />
<strong>Labels:</strong> performance <br />
<strong>Created:</strong> Fri Jul 11, 2014 04:23 PM UTC by Dave Brondsema<br />
<strong>Last Updated:</strong> Thu Aug 07, 2014 07:48 AM UTC<br />
<strong>Owner:</strong> Alexander Luberg</p>
<p><a href="https://sourceforge.net/p/allura/tickets/milestones">https://sourceforge.net/p/allura/tickets/milestones</a> in particular is getting really slow.  I suspect its due to queries for the "Progress" column for every milestone.  Perhaps those can be run in a single mongo query somehow, or parallelize with threads.  Or just skipped for closed milestones.</p>
<hr />
<p>Sent from sourceforge.net because dev@allura.apache.org is subscribed to <a href="https://sourceforge.net/p/allura/tickets">https://sourceforge.net/p/allura/tickets/</a></p>
<p>To unsubscribe from further messages, a project admin can change settings at <a href="https://sourceforge.net/p/allura/admin/tickets/options.">https://sourceforge.net/p/allura/admin/tickets/options.</a>  Or, if this is a mailing list, you can unsubscribe from the mailing list.</p></div>
--===============5486344993038175436==--

--===============5870378827336858985==--