[Gluster-devel] Interesting profile data on tests

[Pranith Kumar Karampuri]

On 01/02/2016 10:11 PM, Raghavendra Talur wrote:
>
>
> On Jan 2, 2016 8:18 PM, "Atin Mukherjee" <atin.mukherjee83 at gmail.com 
> <mailto:atin.mukherjee83 at gmail.com>> wrote:
> >
> > -Atin
> > Sent from one plus one
> > On Jan 2, 2016 4:41 PM, "Raghavendra Talur" <rtalur at redhat.com 
> <mailto:rtalur at redhat.com>> wrote:
> > >
> > >
> > >
> > > On Sat, Jan 2, 2016 at 12:03 PM, Atin Mukherjee 
> <atin.mukherjee83 at gmail.com <mailto: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 
> <mailto: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.
>
> This data is true for non clustered tests too. I am suspecting address 
> resolution.
> Rafi had suggested we use IP addresses instead of host names for HOST 
> variables
>

I have seen latency because of address resolution as well.

Pranith
>
> >
> > >
> > >>
> > >> >
> > >> > Regards,
> > >> > Vijay
> > >> >
> > >> > _______________________________________________
> > >> > Gluster-devel mailing list
> > >> > Gluster-devel at gluster.org <mailto:Gluster-devel at gluster.org>
> > >> > http://www.gluster.org/mailman/listinfo/gluster-devel
> > >
> > >
>
>
>
> _______________________________________________
> 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/20160104/d4ca0ba1/attachment-0001.html>