|
|
| Author |
Message |
reboot3d
Joined: 14 Feb 2008 Posts: 15
|
|
| Back to top |
|
 |
gandalf Developer
Joined: 02 Dec 2004 Posts: 12295 Location: Muenster, Germany
|
Posted: Thu Feb 14, 2008 3:10 pm Post subject: |
|
|
Sure, please post
Reinhard
|
|
| Back to top |
|
 |
reboot3d
Joined: 14 Feb 2008 Posts: 15
|
Posted: Tue Feb 19, 2008 5:08 am Post subject: |
|
|
The file attached, is the diff I made from tree.php. It should be applied without problems to the tree.php in the Revision 0.8.7a.
I guess it isn't quit perfekt. There are other places, where this change could be made, i.e. at the user managment => graph permissions. And I think it would be nice to have a switch to change between the current behavior and the one implemented in this patch. Because it makes no sense if you have only a few graphs.
Hope it helps.
Andreas
Edit: Removed Patch.
Last edited by reboot3d on Mon Mar 03, 2008 10:32 am; edited 1 time in total |
|
| Back to top |
|
 |
reboot3d
Joined: 14 Feb 2008 Posts: 15
|
Posted: Tue Feb 19, 2008 11:19 am Post subject: |
|
|
I applied the changes I mentioned above and put them into the main tree from the svn repository.
I guess, the labels could be renamed to something more intuitive. Please check it out and leave some comments.
Changes are visible at:
Settings->Other Defaults->Split Graph Selection
User Managment->Graph Permissions->Graph Permissions (By Graph)
Graph Trees-> Edit Tree Items ->Tree Item Value
Thanks !
Andreas
Edit: Removed Patch
Last edited by reboot3d on Mon Mar 03, 2008 10:36 am; edited 3 times in total |
|
| Back to top |
|
 |
reboot3d
Joined: 14 Feb 2008 Posts: 15
|
Posted: Wed Feb 20, 2008 5:06 am Post subject: bug |
|
|
I've already found a bug in my changes.
In tree.php line 159 instead of
| Code: |
}elseif( $db_type == TREE_ITEM_TYPE_GRAPH){
|
it should be :
| Code: |
}elseif( isset($db_type) && $db_type == TREE_ITEM_TYPE_GRAPH){
|
|
|
| Back to top |
|
 |
reboot3d
Joined: 14 Feb 2008 Posts: 15
|
Posted: Mon Mar 03, 2008 10:45 am Post subject: |
|
|
Update. I changed my working version to cacti-0.8.7b and applied all changes again.
The diff attached below is made against the 'vanilla' cacti-0.8.7b release. I think this is more useful than diff against the main tree.
I'm still waiting for some comments or replies. Anything from "nice idea!" to "who needs this crap?" is welcome. I intend to make a "feature request" and supply my patch to the developers. But not without any response about the usability.
Greetings
Andreas
| Description: |
| This time I checked for bugs before I submitted this *g* |
|
 Download |
| Filename: |
diff_cacti-0.8.7b.patch |
| Filesize: |
6.48 KB |
| Downloaded: |
105 Time(s) |
|
|
| Back to top |
|
 |
gandalf Developer
Joined: 02 Dec 2004 Posts: 12295 Location: Muenster, Germany
|
Posted: Wed Mar 05, 2008 8:11 am Post subject: |
|
|
Are you aware of the fact, taht it is possible to add single or multiple graphs to trees from Graph Management? Just (multi-)select the graphs and place it on a tree.
That's why I see no ultimate need for this. It's a different approach, so it's fine. If you see additional use, please comment
Reinhard
|
|
| Back to top |
|
 |
reboot3d
Joined: 14 Feb 2008 Posts: 15
|
Posted: Thu Mar 06, 2008 11:13 am Post subject: |
|
|
Hey!
Yes I'm aware of that. In fact, it saved me a lot of time using the multiple graph placement. (BIG thanks for that ) And I'm aware this is not useful for everyone. But I have to monitor a lot of graphs and as I read, other had even more graphs to cope with.
I have a tree hierarchy like "VLAN -> Switch -> Port". (Please dont ask why this decision was made.) Moving every single graph to the port level, would have been taken lots of time, so I moved a bunch of graphs to the switch level and single graphs to the port level afterwards. This means I had to move nearly every single graph to the correct location.
Now consider N to be the total number of graphs and M the number of hosts to deal with. Ok, now let N(m) the number of graphs taken from host m.
If you have every single graph to move, you will have N database-queries with N results at every query. This means you have to transfer nearly N*N results with the current approach. But with my approach, you'll get N*2*(M+max(N(m))) as an upper limit. I guess usually N*N is nearly equal to N*2*(M+max(N(m))). But consider, the current approach is growing quadratic but my approach grows only linear or logarithmic (I guess the latter).
This means there is a number, where N*N is significant larger than N*2*(M+max(N(m))). This could save some people a lot of time, especially if you have to change the trees on a regular base.
In my case there are N=7500, M=25, max(N(m))=800. It saved me lots of time. I think it's worth considering.
Have a nice day!
Andreas
|
|
| Back to top |
|
 |
reboot3d
Joined: 14 Feb 2008 Posts: 15
|
Posted: Thu Mar 06, 2008 11:34 am Post subject: |
|
|
Even if you dont have to move every graph, with one request there is N significant larger than 2*(M+max(N(m))). I mean in my case it is.
(Two times, because if you load the site the first time, you might get not the host you want and you have to reload the site with the correct host.)
Hmm, I guess, if you wait 4 or 5 seconds for a load to complete and got a few thousand graphs ahead, you start thinking what could't be impoved.
|
|
| Back to top |
|
 |
TheWitness Developer
Joined: 14 May 2002 Posts: 9697 Location: MI, USA
|
Posted: Thu Mar 06, 2008 10:12 pm Post subject: |
|
|
Gandolf,
If you thinks this warrants a change, make sure the user commit's patch to the bug database.
TheWitness
|
|
| Back to top |
|
 |
gandalf Developer
Joined: 02 Dec 2004 Posts: 12295 Location: Muenster, Germany
|
Posted: Fri Mar 07, 2008 10:48 am Post subject: |
|
|
| TheWitness wrote: | Gandolf,
If you thinks this warrants a change, make sure the user commit's patch to the bug database.
TheWitness | That's aimed at you reboot3d
Reinhard
|
|
| Back to top |
|
 |
reboot3d
Joined: 14 Feb 2008 Posts: 15
|
|
| Back to top |
|
 |
|