showdependencygraph.cgi should limit the number of nodes

RESOLVED DUPLICATE of bug 102622

Status

()

Bugzilla
Bugzilla-General
RESOLVED DUPLICATE of bug 102622
15 years ago
13 years ago

People

(Reporter: myk, Unassigned)

Tracking

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

15 years ago
showdependencygraph.cgi lets you graph as many nodes as you want, which is
bringing mothra performance to its knees now that Dave has installed a local
webdot.  We should be able to limit the number of nodes it displays.
(Reporter)

Comment 1

15 years ago
Created attachment 114839 [details] [diff] [review]
work in progress

Here's a likely solution: have a configurable limit and generate as much of the
graph as possible.
(Reporter)

Comment 2

15 years ago
The work in progress is running on landfill with a limit of 10 links:

http://landfill.bugzilla.org/bz193947/showdependencygraph.cgi?doall=on

Comment on attachment 114839 [details] [diff] [review]
work in progress

>Index: showdependencygraph.cgi

>-# Connect to the shadow database if this installation is using one to improve
>-# performance.
>-Bugzilla->switch_to_shadow_db();
>-

Is there a specific reason we don't want to use the shadow DB?

>@@ -120,10 +124,13 @@
> 
>             AddLink($blocked, $dependson);
>         }
>-    }
>-
>-    foreach my $k (keys(%baselist)) {
>-        $seen{$k} = 1;
>+        # Mark this bug as seen in case it has no dependencies
>+        # (and thus wasn't marked as seen by the above AddLink call).
>+        $seen{$id} = 1;
>+
>+        # Stop processing more bugs if we've reached the link limit.
>+        last if (Param('dependencygraphmaxlinks')
>+                 && $link_count > Param('dependencygraphmaxlinks'));

To keep the wording consistent on the output page, this should probably
be >= instead of >

>Index: template/en/default/bug/dependency-graph.html.tmpl

>+[% IF max_links AND link_count > max_links %]

>= instead of >

>+    Note: Due to limited resources, the server wasn't able to generate 
>+    a complete graph.  Instead, it generated a graph of the first
>+    [% max_links %] nodes.

We have PRE_CHOMP on, so you need [%+ in front of max_links or you wind up with
no space between "first" and the number.


Otherwise this looks pretty good.
Attachment #114839 - Flags: review-
and I forgot to say also, on the output template, it should probably say "links"
instead of "nodes", and it might not hurt to clarify that links refers to "the
arrows between bugs".
(Reporter)

Comment 5

15 years ago
Comment on attachment 114839 [details] [diff] [review]
work in progress

This patch seems to have caused an infinite loop that filled my Apache
error_log with 2GB of data:

[Tue Feb 18 16:27:42 2003] [error] [client 127.0.0.1] [Tue Feb 18 16:27:42
2003] showdependencygraph2.cgi: Use of uninitialized value in concatenation (.)
or string at /var/www/html/bztip/showdependencygraph2.cgi line 62.

I need to look at it and figure out what the problem is, or maybe it's to do
with bug 194125.  Anyway, in the meantime don't use this patch.
Attachment #114839 - Attachment is obsolete: true
We should probably fix this before 2.18 ships...  any chance of resurrecting
this patch, Myk?
Target Milestone: --- → Bugzilla 2.18
Myk: is this a dupe of bug 102622?
(Reporter)

Comment 8

14 years ago
No, although they are related.  Bug 102622 is about limiting the depth,
presumably for usability, while this bug is about limiting the total number of
nodes regardless of depth, so that we don't overwhelm the graph generator.
(Reporter)

Comment 9

14 years ago
Hmm, actually now that I take a closer look at bug 102622 this might be a dupe,
although the solution proposed in this bug is a simpler one.

Comment 10

14 years ago
They are both really RFEs, despite the severity and that bug 102622 blocks bug
164085.  They describe different features, even if they have similar motives. 
As such, I suppose they should be kept separate.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20

Comment 11

13 years ago
This bug has not been touched by its owner in over six months, even though it is
targeted to 2.20, for which the freeze is 10 days away. Unsetting the target
milestone, on the assumption that nobody is actually working on it or has any
plans to soon.

If you are the owner, and you plan to work on the bug, please give it a real
target milestone. If you are the owner, and you do *not* plan to work on it,
please reassign it to nobody@bugzilla.org or a .bugs component owner. If you are
*anybody*, and you get this comment, and *you* plan to work on the bug, please
reassign it to yourself if you have the ability.
Target Milestone: Bugzilla 2.20 → ---
Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.
Assignee: justdave → general
QA Contact: mattyt-bugzilla → default-qa

Comment 13

13 years ago

*** This bug has been marked as a duplicate of 102622 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.