[Gluster-devel] Interesting profile data on tests

[Raghavendra Talur]

On Sat, Jan 2, 2016 at 12:03 PM, Atin Mukherjee <atin.mukherjee83 at gmail.com>
wrote:

> -Atin
> Sent from one plus one
>
> On Jan 2, 2016 11:52 AM, "Vijay Bellur" <vbellur at redhat.com> wrote:
> >
> > On 12/30/2015 10:36 AM, Raghavendra Talur wrote:
> >>
> >> This is not comprehensive data but some interesting bits
> >>
> >> Average time taken for various commands in our .t files.
> >>
> >> * glusterd - 2 second
> >> * gluster vol start/stop - 3 second
> >> * gluster vol set/info(any basic gluster cli command) -1 second
> >> * gluster mount - 2 second
> >> * gluster add brick - 2 second
> >> * gluster remove brick - 5 second
> >> * gluster rebalance start 5 second
> >> * gluster tier attach/detach - 6 second
> >>
> >> The only other single command which takes 1+ second is sleep. Most of
> >> the other
> >> external commands we use in bash scripts are not that time taking.
> >>
> >>
> >> Hence,
> >>
> >> 1. Don't stop/delete a gluster volume in .t file unless it is part of
> >> your test. Let the cleanup function handle that.
> >> 2. Don't call gluster vol info at the start of the test if not required
> >> 3. Merge as many tests as possible to reduce glusterd starts/vol starts
> >> and mounts.
> >> 4. Use sleep only if it is absolutely required.
> >>
> >> You can use this bug
> https://bugzilla.redhat.com/show_bug.cgi?id=1294826
> >> to send patches to improve test times.
> >>
> >
> > Thank you! These are good set of steps that can help in reducing the
> overall time consumed for a regression test run. I also think the larger
> latencies observed in volume operations could be related to the the set of
> fsync()s involved in making configuration state durable in glusterd's
> store. It would be interesting to see if we can use a ramdisk for
> /var/lib/glusterd and check if the latencies would improve.
> That's a good suggestion. It'd definitely improve the latency.
>

Tried this.
I saw improvement of 1 second with commands which took over 4 second. May
be there is something else which is taking more time?


> >
> > Regards,
> > Vijay
> >
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160102/fda800fd/attachment.html>