Jeremy, I have some data that might be useful here.
I had run some numbers against cloudfiles-us couple of weeks ago. We have a tool developed in-house at Maginatics to test blobstore performance. Essentially, the tool creates multiple threads that put a configured # of blobs in a given container. The tool uses the jclouds BlobStore APIs. All the blobs are written to a single container. Starting from 40K blobs, I went upto 2.8M blobs. You can see the results here. http://databin.pudo.org/t/b09dba The container was cleared after each run. So every run started off with an empty container. I ran with the default java config options. HTH. -Shri P.S. We are looking into open-sourcing the blobstore benchmarking tool. Hopefully, it will be out soon. On Wed, Jul 3, 2013 at 10:11 AM, Jeremy Daggett <[email protected]>wrote: > jclouds-devs, > > gmail auto-completed my last message to the old list, so let's try this > again... > > I have a situation where I want to test Swift container limits (>10k > objects) via a live test. This would be more of the category of "stress" > test, but do we really have that notion in jclouds? > > I don't believe that this is the kind of test case that would be run with > every single execution of the live tests, so I am not clear on which > direction to go. > > What have others done in the past for test cases that might be *very* long > running, and only run every so often? Has this been solved in the past? > > I believe that I could add a TestNG group in the @Test annotation like this > on the actual method: > > @Test(groups = {"live", "stress"} ) > public voide testContainerLimits() { > ... > } > > Then I can just specify the groups I want to run, and away we go! > > WDYT? Any insight is appreciated, thanks! > > /jd >
