WebApollo stress testing.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

WebApollo stress testing.

Henry
Hi all,

We would like to demonstrate our instance of WebApollo 2.0 to a large group (~60 people or so).

As an informal stress test we had ~30 users follow two links to two different organisms on the same WebApollo instance:

*The links went to the publicly available jbrowse URL (<site name>/<aliased webapollo name>/jbrowse/index.html?organism....).

*Almost all tracks were selected for each organism in the URL( ~20 tracks per organism).

*There was a mixture of track types (data from VCFs, BAMs, GFF3s).

Unfortunately, WebApollo failed to load in a reasonable amount of time.

Has anyone had this many users on their instance before?
Is this many concurrent users feasible?

Thanks for your help,

Henry




This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.

Reply | Threaded
Open this post in threaded view
|

Re: WebApollo stress testing.

nathandunn

Thanks for the report. 

We’ve definitely done some stress testing, mostly with 4-6 users doing several write operations per minute over 24 hours (https://github.com/GMOD/Apollo/issues/137). 

However, I don’t think we’ve done this with a large number of tracks with a large number of users.  We do trainings with about 5 people per instance regularly using Web Apollo 2, but ideally it should be able to scale, so its definitely something easy to fix (knock on wood).

A couple of questions:

1 - Have you noticed any different in performance relative to tracks / users? 
2 - Are you seeing anything in the logs?
3 - What are you using for the backend (PostgreSQL, H2, MySQL, etc.)?

I’ll try to re-create this stress test and see what I find.   Worst-case, it may be something specific with your data that we can tune for. 

Nathan Dunn, PhD
Berkeley Bioinformatics Open-source Projects (BBOP)
Genomics Division, Lawrence Berkeley National Laboratory
[hidden email]


On Oct 7, 2015, at 12:33 PM, Nathan Henry <[hidden email]> wrote:

Hi all,

We would like to demonstrate our instance of WebApollo 2.0 to a large group (~60 people or so).

As an informal stress test we had ~30 users follow two links to two different organisms on the same WebApollo instance:

*The links went to the publicly available jbrowse URL (<site name>/<aliased webapollo name>/jbrowse/index.html?organism....).

*Almost all tracks were selected for each organism in the URL( ~20 tracks per organism).

*There was a mixture of track types (data from VCFs, BAMs, GFF3s).

Unfortunately, WebApollo failed to load in a reasonable amount of time.

Has anyone had this many users on their instance before?
Is this many concurrent users feasible?

Thanks for your help,

Henry



This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.






This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.

Reply | Threaded
Open this post in threaded view
|

Re: WebApollo stress testing.

Henry
Thanks for the response.

In answer to your questions:

1-In general the more tracks selected for viewing means slower performance. When one track is loaded everything runs smoothly, when many tracks are loaded, things slow down and movement in the browser seems "jumpy" when moving along a  scaffold. All users are not logged-in/anonymous users.

2-Nothing strange in the logs

3-Our database is a postgres database.

We think it might have something to do with the fact that we performed the stress testing with laptops over a wireless connection. We performed a similar test - this time in a computer lab with Ethernet connections - and WebApollo loaded very quickly.

Thanks again,

Henry

On Wed, Oct 7, 2015 at 3:46 PM, Nathan Dunn <[hidden email]> wrote:

Thanks for the report. 

We’ve definitely done some stress testing, mostly with 4-6 users doing several write operations per minute over 24 hours (https://github.com/GMOD/Apollo/issues/137). 

However, I don’t think we’ve done this with a large number of tracks with a large number of users.  We do trainings with about 5 people per instance regularly using Web Apollo 2, but ideally it should be able to scale, so its definitely something easy to fix (knock on wood).

A couple of questions:

1 - Have you noticed any different in performance relative to tracks / users? 
2 - Are you seeing anything in the logs?
3 - What are you using for the backend (PostgreSQL, H2, MySQL, etc.)?

I’ll try to re-create this stress test and see what I find.   Worst-case, it may be something specific with your data that we can tune for. 

Nathan Dunn, PhD
Berkeley Bioinformatics Open-source Projects (BBOP)
Genomics Division, Lawrence Berkeley National Laboratory
[hidden email]


On Oct 7, 2015, at 12:33 PM, Nathan Henry <[hidden email]> wrote:

Hi all,

We would like to demonstrate our instance of WebApollo 2.0 to a large group (~60 people or so).

As an informal stress test we had ~30 users follow two links to two different organisms on the same WebApollo instance:

*The links went to the publicly available jbrowse URL (<site name>/<aliased webapollo name>/jbrowse/index.html?organism....).

*Almost all tracks were selected for each organism in the URL( ~20 tracks per organism).

*There was a mixture of track types (data from VCFs, BAMs, GFF3s).

Unfortunately, WebApollo failed to load in a reasonable amount of time.

Has anyone had this many users on their instance before?
Is this many concurrent users feasible?

Thanks for your help,

Henry



This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.






This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.







This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.

Reply | Threaded
Open this post in threaded view
|

Re: WebApollo stress testing.

Colin
Glad there are at least some improvements in the testing :)

The speed of Apollo2 in the "JBrowse only mode" should be approximately the same as if you ran JBrowse by itself, so hopefully that is going ok.

Also, there are a couple features that are coming in WA 2.0.1 that might help with the problems of slow scrolling. We have made the ability to (a) use CanvasFeatures for some basic operations (we added a right click menu so that annotations can be created from them), and that is good since CanvasFeatures are much faster than htmlfeatures for the webbrowser, and it making scrolling around less jumpy and (b) added the ability to use tracks loaded with --compress from the jbrowse command line, which could cut down on bandwidth if your gff files are very large.


-Colin

On Thu, Oct 15, 2015 at 2:43 PM, Nathan Henry <[hidden email]> wrote:
Thanks for the response.

In answer to your questions:

1-In general the more tracks selected for viewing means slower performance. When one track is loaded everything runs smoothly, when many tracks are loaded, things slow down and movement in the browser seems "jumpy" when moving along a  scaffold. All users are not logged-in/anonymous users.

2-Nothing strange in the logs

3-Our database is a postgres database.

We think it might have something to do with the fact that we performed the stress testing with laptops over a wireless connection. We performed a similar test - this time in a computer lab with Ethernet connections - and WebApollo loaded very quickly.

Thanks again,

Henry

On Wed, Oct 7, 2015 at 3:46 PM, Nathan Dunn <[hidden email]> wrote:

Thanks for the report. 

We’ve definitely done some stress testing, mostly with 4-6 users doing several write operations per minute over 24 hours (https://github.com/GMOD/Apollo/issues/137). 

However, I don’t think we’ve done this with a large number of tracks with a large number of users.  We do trainings with about 5 people per instance regularly using Web Apollo 2, but ideally it should be able to scale, so its definitely something easy to fix (knock on wood).

A couple of questions:

1 - Have you noticed any different in performance relative to tracks / users? 
2 - Are you seeing anything in the logs?
3 - What are you using for the backend (PostgreSQL, H2, MySQL, etc.)?

I’ll try to re-create this stress test and see what I find.   Worst-case, it may be something specific with your data that we can tune for. 

Nathan Dunn, PhD
Berkeley Bioinformatics Open-source Projects (BBOP)
Genomics Division, Lawrence Berkeley National Laboratory
[hidden email]


On Oct 7, 2015, at 12:33 PM, Nathan Henry <[hidden email]> wrote:

Hi all,

We would like to demonstrate our instance of WebApollo 2.0 to a large group (~60 people or so).

As an informal stress test we had ~30 users follow two links to two different organisms on the same WebApollo instance:

*The links went to the publicly available jbrowse URL (<site name>/<aliased webapollo name>/jbrowse/index.html?organism....).

*Almost all tracks were selected for each organism in the URL( ~20 tracks per organism).

*There was a mixture of track types (data from VCFs, BAMs, GFF3s).

Unfortunately, WebApollo failed to load in a reasonable amount of time.

Has anyone had this many users on their instance before?
Is this many concurrent users feasible?

Thanks for your help,

Henry



This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.






This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.







This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.







This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.

Reply | Threaded
Open this post in threaded view
|

Re: WebApollo stress testing.

nathandunn
In reply to this post by Henry
Moni has done similar testing during her training and rooms full of wireless vs wired users makes a big difference.  

Nathan

On Oct 15, 2015, at 12:43 PM, Nathan Henry <[hidden email]> wrote:

Thanks for the response.

In answer to your questions:

1-In general the more tracks selected for viewing means slower performance. When one track is loaded everything runs smoothly, when many tracks are loaded, things slow down and movement in the browser seems "jumpy" when moving along a  scaffold. All users are not logged-in/anonymous users.

2-Nothing strange in the logs

3-Our database is a postgres database.

We think it might have something to do with the fact that we performed the stress testing with laptops over a wireless connection. We performed a similar test - this time in a computer lab with Ethernet connections - and WebApollo loaded very quickly.

Thanks again,

Henry

On Wed, Oct 7, 2015 at 3:46 PM, Nathan Dunn <[hidden email]> wrote:

Thanks for the report. 

We’ve definitely done some stress testing, mostly with 4-6 users doing several write operations per minute over 24 hours (https://github.com/GMOD/Apollo/issues/137). 

However, I don’t think we’ve done this with a large number of tracks with a large number of users.  We do trainings with about 5 people per instance regularly using Web Apollo 2, but ideally it should be able to scale, so its definitely something easy to fix (knock on wood).

A couple of questions:

1 - Have you noticed any different in performance relative to tracks / users? 
2 - Are you seeing anything in the logs?
3 - What are you using for the backend (PostgreSQL, H2, MySQL, etc.)?

I’ll try to re-create this stress test and see what I find.   Worst-case, it may be something specific with your data that we can tune for. 

Nathan Dunn, PhD
Berkeley Bioinformatics Open-source Projects (BBOP)
Genomics Division, Lawrence Berkeley National Laboratory
[hidden email]


On Oct 7, 2015, at 12:33 PM, Nathan Henry <[hidden email]> wrote:

Hi all,

We would like to demonstrate our instance of WebApollo 2.0 to a large group (~60 people or so).

As an informal stress test we had ~30 users follow two links to two different organisms on the same WebApollo instance:

*The links went to the publicly available jbrowse URL (<site name>/<aliased webapollo name>/jbrowse/index.html?organism....).

*Almost all tracks were selected for each organism in the URL( ~20 tracks per organism).

*There was a mixture of track types (data from VCFs, BAMs, GFF3s).

Unfortunately, WebApollo failed to load in a reasonable amount of time.

Has anyone had this many users on their instance before?
Is this many concurrent users feasible?

Thanks for your help,

Henry



This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.






This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.






This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.





This list is for the Apollo Annotation Editing Tool. Info at http://genomearchitect.org/
If you wish to unsubscribe from the Apollo List: 1. From the address with which you subscribed to the list, send a message to [hidden email] | 2. In the subject line of your email type: unsubscribe apollo | 3. Leave the message body blank.