On 01/02/2016 10:11 PM, Raghavendra
Talur wrote:
On Jan 2, 2016 8:18 PM, "Atin Mukherjee" <atin.mukherjee83@xxxxxxxxx>
wrote:
>
> -Atin
> Sent from one plus one
> On Jan 2, 2016 4:41 PM, "Raghavendra Talur" <rtalur@xxxxxxxxxx>
wrote:
> >
> >
> >
> > On Sat, Jan 2, 2016 at 12:03 PM, Atin Mukherjee <atin.mukherjee83@xxxxxxxxx>
wrote:
> >>
> >> -Atin
> >> Sent from one plus one
> >>
> >>
> >> On Jan 2, 2016 11:52 AM, "Vijay Bellur" <vbellur@xxxxxxxxxx>
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@xxxxxxxxxxx
> >> > http://www.gluster.org/mailman/listinfo/gluster-devel
> >
> >
_______________________________________________
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
