Hi all, In brainstorming here about how to organise the tools menu in our local Galaxy, we considered an automatically populated list of the user's frequently or recently used tools. Unlike a favourites system, this doesn't require explicit action from the user. That brought us to another thought - does Galaxy track how often different tools are used? Even if that hasn't been done till now, it should be possible to trawl the database of all non-purged histories and tally up usage counts. That information would be helpful for many decisions - including optimising the listing for easy of use, or making sure the most used tools all have excellent documentation. If this could also count the run time as well as run count, it would be particularly helpful for identifying where most of the server time is spent, so which tools which would most benefit from optimisation or different hardware upgrades. Do you already do this internally for the main public Galaxy interface? Thanks, Peter
Hi Peter, On Feb 3, 2011, at 10:55 AM, Peter Cock wrote:
Hi all,
In brainstorming here about how to organise the tools menu in our local Galaxy, we considered an automatically populated list of the user's frequently or recently used tools. Unlike a favourites system, this doesn't require explicit action from the user.
This is currently available in the Options menu of the tool panel ( Options -> Show recently used )
That brought us to another thought - does Galaxy track how often different tools are used? Even if that hasn't been done till now, it should be possible to trawl the database of all non-purged histories and tally up usage counts.
See the "Jobs per tool" report in the Galaxy reports.
That information would be helpful for many decisions - including optimising the listing for easy of use, or making sure the most used tools all have excellent documentation. If this could also count the run time as well as run count, it would be particularly helpful for identifying where most of the server time is spent, so which tools which would most benefit from optimisation or different hardware upgrades.
Currently run time is only available on a per tool per job basis, but the reports could be enhanced to show averages if this is needed.
Do you already do this internally for the main public Galaxy interface?
Thanks,
Peter _______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
On Thu, Feb 3, 2011 at 4:10 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
Hi Peter,
On Feb 3, 2011, at 10:55 AM, Peter Cock wrote:
Hi all,
In brainstorming here about how to organise the tools menu in our local Galaxy, we considered an automatically populated list of the user's frequently or recently used tools. Unlike a favourites system, this doesn't require explicit action from the user.
This is currently available in the Options menu of the tool panel ( Options -> Show recently used )
Oh yeah :)
That brought us to another thought - does Galaxy track how often different tools are used? Even if that hasn't been done till now, it should be possible to trawl the database of all non-purged histories and tally up usage counts.
See the "Jobs per tool" report in the Galaxy reports.
Where are these Galaxy reports? I don't see anything on the admin page. Thanks, Peter
They run under a separate Galaxy webapp which you configure using the reports_wsgi.ini in the Galaxy install directory ( copy reports_wsgi.ini.sample and make appropriate changes for your local app ). This is where you'll set a port, and connect to the same database your Galaxy instance uses. After setting the config, fire up the reports with: %sh run_reports.sh ... and direct your browser to the port you've set in the config. On Feb 3, 2011, at 11:32 AM, Peter Cock wrote:
On Thu, Feb 3, 2011 at 4:10 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
Hi Peter,
On Feb 3, 2011, at 10:55 AM, Peter Cock wrote:
Hi all,
In brainstorming here about how to organise the tools menu in our local Galaxy, we considered an automatically populated list of the user's frequently or recently used tools. Unlike a favourites system, this doesn't require explicit action from the user.
This is currently available in the Options menu of the tool panel ( Options -> Show recently used )
Oh yeah :)
That brought us to another thought - does Galaxy track how often different tools are used? Even if that hasn't been done till now, it should be possible to trawl the database of all non-purged histories and tally up usage counts.
See the "Jobs per tool" report in the Galaxy reports.
Where are these Galaxy reports? I don't see anything on the admin page.
Thanks,
Peter
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
On Thu, Feb 3, 2011 at 4:38 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
They run under a separate Galaxy webapp ...
Why? It seems to me it would be easier to have it under the admin pages of the main Galaxy webapp.
... which you configure using the reports_wsgi.ini in the Galaxy install directory ( copy reports_wsgi.ini.sample and make appropriate changes for your local app ). This is where you'll set a port, and connect to the same database your Galaxy instance uses.
After setting the config, fire up the reports with:
%sh run_reports.sh
... and direct your browser to the port you've set in the config.
That didn't work on my development machine, no output at all. Having eventually found this Dev briefing apparently SQLite isn't supported: https://bitbucket.org/galaxy/galaxy-central/wiki/Features/DevNewsBrief/2010_... Is there any more documentation on this somewhere on the wiki that I've missed? It isn't working immediately on our production machine either - some relevant errors in reports_webapp.log include: sqlalchemy.exc.ArgumentError: Invalid SQLite URL: sqlite://./database/universe.d?isolation_level=IMMEDIATE Why would it use that connection string when I've recorded database_connection = postgres://... in reports_wsgi.ini? [Errno 13] Permission denied: '/opt/galaxy-dist/database/compiled_templates/reports' Is that a folder? When is it meant to be created? Thanks again, Peter
On Feb 3, 2011, at 11:58 AM, Peter Cock wrote:
On Thu, Feb 3, 2011 at 4:38 PM, Greg Von Kuster <greg@bx.psu.edu> wrote:
They run under a separate Galaxy webapp ...
Why? It seems to me it would be easier to have it under the admin pages of the main Galaxy webapp.
Running as a separate web application provides much more flexibility in many areas ( e.g., separate thread pools, user authentication, application settings, etc, etc, etc ).
... which you configure using the reports_wsgi.ini in the Galaxy install directory ( copy reports_wsgi.ini.sample and make appropriate changes for your local app ). This is where you'll set a port, and connect to the same database your Galaxy instance uses.
After setting the config, fire up the reports with:
%sh run_reports.sh
... and direct your browser to the port you've set in the config.
That didn't work on my development machine, no output at all. Having eventually found this Dev briefing apparently SQLite isn't supported:
https://bitbucket.org/galaxy/galaxy-central/wiki/Features/DevNewsBrief/2010_...
Is there any more documentation on this somewhere on the wiki that I've missed? It isn't working immediately on our production machine either - some relevant errors in reports_webapp.log include:
sqlalchemy.exc.ArgumentError: Invalid SQLite URL: sqlite://./database/universe.d?isolation_level=IMMEDIATE
Why would it use that connection string when I've recorded database_connection = postgres://... in reports_wsgi.ini?
There must be a problem with your config setting. The reports server will use the value defined in the "database_connection" setting.
[Errno 13] Permission denied: '/opt/galaxy-dist/database/compiled_templates/reports'
Is that a folder? When is it meant to be created?
Yes, this is a folder that should get created when you start the reports server. The config setting is named "template_cache_path" - see line 32 of ~/lib/galaxy/webapps/reports/config.py.
Thanks again,
Peter
Greg Von Kuster Galaxy Development Team greg@bx.psu.edu
participants (2)
-
Greg Von Kuster -
Peter Cock