[Gluster-devel] Interesting profile data on tests

[Atin Mukherjee]

-Atin
Sent from one plus one
On Jan 2, 2016 4:41 PM, "Raghavendra Talur" <rtalur at redhat.com> wrote:
>
>
>
> 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?
Did you observe this for clustered tests? I think apart from fsync() and
n/w latency the rest of the things should be pretty light wight and
shouldn't consume much 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/732f2d2e/attachment.html>