Date: Tue, 10 May 2005 12:55:09 -0700 From: Benjamin Krueger <benjamin@seattlefenix.net> To: Petri Helenius <pete@he.iki.fi> Cc: performance@freebsd.org Subject: Re: Regression testing (was Re: Performance issue) Message-ID: <20050510195508.GR86767@strawberry.seattlefenix.net> In-Reply-To: <428110D2.8070004@he.iki.fi> References: <200505101518.j4AFImSv071163@gate.bitblocks.com> <428110D2.8070004@he.iki.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
* Petri Helenius (pete@he.iki.fi) [050510 12:52]: > > This sounds somewhat similar to Solaris dtrace stuff? > > Pete This sounds more like a QA/Feedback process. dtrace isn't just a conglomeration of the usual performance metrics. It's closer to a total revamp of how you perform said metrics at the system level. > Bakul Shah wrote: > > >This thread makes me wonder if there is value in runing > >performance tests on a regular basis. This would give an > >early warning of any peformance loss and can be a useful > >forensic tool (one can pinpoint when some performance curve > >changed discontinuously even though at the time of change it > >may be too small to be noticed). Over a period of time > >one can gain a view of how the performance evolves. > > > >This would not be a single metric but a set of low and high > >level measures: such as syscall overhead, interrupt overhead, > >specific h/w devices, disk and fs performance for various > >filesystems and file sizes, networking data and pkt > >throughput, routing performance, VM, other subsystems, effect > >of SMP, various threading libraries, scaling with number of > >users/programs/cpus/memory, typical applications under normal > >and stressed loads, compile time for the system and kernel > >etc. etc. etc. > > > >The setup would allow for easy addition of new benchmarks > >(the only way anything like this can be bootstrapped). Of > >course, one would need to record disk/processor/memory speed > >and capacities + kernel config options, system build tools > >and their options to interpret the results as best as > >possible. For the results to be useful the setup has to > >remain as stable as possible for a long time. > > > >[While I am dreaming...] A follow on project would be to > >create visualization tools -- mainly graphing and comparing > >graphs. It would be neat if one can click on a performance > >graph to zoom in or see commits made during some selected > >period. > > > >Such a detailed look, combined with profiling can help people > >focus on specific hotspots & feel good about any improvements > >they are making. This can be a great way to rope in new > >people;-) > >_______________________________________________ > >freebsd-performance@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-performance > >To unsubscribe, send any mail to > >"freebsd-performance-unsubscribe@freebsd.org" > > > > > > > > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org" -- -- Benjamin Krueger SysAdmin, CarDomain Network 92 Toyota Turbo MR2 78 Datsun B-210 91 freakin Geo Prizm
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050510195508.GR86767>