Re: shared_buffers advice

Greg Smith <greg@2ndquadrant.com> 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