Greg Smith <greg@xxxxxxxxxxxxxxx> writes: > However, that doesn't actually solve any of the problems I was talking about > though, which is why I'm not even talking about that part. We need the glue > to pull out software releases, run whatever testing tool is appropriate, and > then save the run artifacts in some standardized form so they can be > referenced with associated build/configuration information to track down a > regression when it does show up. Building those boring bits are the real > issue here; load testing tools are easy to find because those are fun to > work on. Oh, ok. I missparsed the previous message. Tsung has a way to monitor OS level information, and I guess adding the build/configuration would be... as easy as adding it to pgbench :) > And as a general commentary on the vision here, tsung will never fit into > this anyway because "something that can run on the buildfarm machines with > the software they already have installed" is the primary target. I don't > see anything about tsung so interesting that it trumps that priority, even > though it is an interesting tool. I though we might talk about a performance farm which would be quite different, if only because to sustain a high enough client load you might need more than one injector machine targeting a given server at once. But if you target the buildfarm, introducing new dependencies does sound like a problem (that I can't evaluate the importance of). Regards, -- dim -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
