On Jan 3, 2016 9:23 AM, Pranith Kumar Karampuri Wrote:
>
>
> 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.
> > >> >>
Adding some more points here:
* Every time we start a new test case we source files (basically Run them in same bash)
at the beginning, say include.rc, nfs.rc, etc. which also ingest execution time,
its better to include (In fact run) them only once when our aim is to run all
* Don't call cleanup twice in single test case (Again, I mean in bulk mode)
* There are 40+ testcases that can run parallel, i.e. they really don't require
glusterd running but currently we run all tests sequentially, have a look at
'posixonly.t'
I have sent a mail prior to this regarding improvements, if some body had miss that
I am attaching it above again please find the same.
Thanks,
- prasanna
> > >> >> 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
Attachment:
Improved_Test_Plan.png
Description: PNG image
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
