On 08/29/2016 08:25 AM, Nigel Babu wrote:
On Mon, Aug 29, 2016 at 01:49:52PM +0200, Niels de Vos wrote:
On Mon, Aug 29, 2016 at 05:01:18PM +0530, Nigel Babu wrote:
Hello folks,
I've had chats with Manoj and Ambarish about performance testing and what we
can do upstream. Niels today solved half my problem by pointing out that we can
get physical nodes on CentOS CI. The general idea is to run iozone[1] and
smallfile[2] on a fixed frequency for master (to begin with).
Does this sound like a good idea? If so, read on.
For this to happens a few things need to happen:
* I'll need some help from a few people who can read the reports and coordinate
fixes. That is, someone needs to "own" performance for upstream.
* I need some help in generating the right reports so we can figure out if our
performance went up or down.
I volunteer for both of the above.
The provisioning in the CentOS CI does not allow us to select certain
systems (yet). So you would get different performance results, depending
on the hardware that the reservation request returns:
https://wiki.centos.org/QaWiki/PubHardware
Also, these physical machines do not have additional disks. The single
SSD that these systems have, is completely used by the installation, no
free space to partition to our liking, no additional disks available.
I welcome any additional testing that we can run regulary, but to call
it 'performance testing' might be a little pre-mature. At least the
performance results should be marked as 'unoptimized' or similar.
HTH,
Niels
The goal of this testing, to begin with, wouldn't be to get absolute numbers
but to try and catch decrease in performance, if that makes sense. In essence,
it's regression testing but for performance.
Thank you for raising the fact that it may be inconsistent, I'll talk to the
Centos CI folks and see what's the best way forward for us before we get here.
But let's work with the assumption that I'll sort out the infra side of things.
I had the same concern as Niels, but as long as we can sort out the
infar side of things (which we can in parallel to building this up), I
see that this would be valuable.
[1]: http://www.iozone.org/
[2]: https://github.com/bengland2/smallfile
--
nigelb
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
--
nigelb
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
