Closed AlexanderPico closed 8 years ago
Thanks for reporting, but I'm not sure how to reproduce. I just fetched a network for 1000 cancer proteins, which took about 12 seconds, and that time was including the client-side layout of the network. Also, one of the main points of developing the App is to serve the users for whom the limitation of about 500 proteins on the STRING website is a problem.
Interesting. I wonder if it's a network latency issue, or even a Gladstone/UCSF-specific issues. I'll test from another UCSF building and from home later.
Thanks! I just did an even more extreme test, fetching a STRING network of 2000 nodes and 68227 edges. After about 30 seconds all data had been fetched from the server and Cytoscape was busy doing layout. Something funny must be going on if you're experiencing problems with low-hundreds of proteins.
"Funny" things have been known to happen on this campus... Thanks for the independent tests! I hope I'm the exception and it's not just that you are super close to the server.
Sitting close to the server obviously helps. But I just fired up a VPN connection to the US and again fetched the 1000 cancer proteins network. It took longer, but still less than 20 seconds.
I think that settles it. I'll close the bug here and continue local tests to fix our "funny" network :)
Thanks!
Somewhere between a query size of 100 and 600, we start to get a "null" error from stringApp. I'm assuming it's due to a long query and the server or parsing task is taking too long. A recommended max and clearer dialog with user would help. Otherwise it just looks broken and many users might not try with smaller lists or reason that they need to go to the site online if they are working with longer lists.