From: William P. <wil...@ya...> - 2011-11-15 02:16:54
|
Yeah, I totally agree -- if it takes down dev, it will also take down production. It would be better to point it to a third deployment (e.g. perhaps http://treebase-stage.nescent.org/treebase-web/), or better yet, one that runs on a separate spare machine so that it won't take down any other services -- and meanwhile we try to figure out how to make the API more robust. As a stateless API, it ought not to be filling up memory faster than it can dispose of it (if that's what's happening), but perhaps the problem is something else (corrupt data?). bp On Nov 14, 2011, at 7:56 PM, Rutger Vos wrote: > Hey Carl, > > production isn't that much more ironclad to be honest. If a user is > doing some serious harvesting of dozens/hundreds of requests for > studies there's a good chance some of those are going to be ones that > will construct long running queries to re-constitute all the data in a > study. > > Until we have some caching strategy there's not really a good > recommendation to make for rate of calls: even relatively low rates > (several seconds apart, say) may be able to bring the server to its > knees. > > Rutger |