Monitoring, redux

David Collier-Brown davecb at
Tue Mar 7 14:35:08 GMT 2000

   Once upon a time, in a message I can't find any more, we discussed
performance measurements, and I suggested latency and throughput
for read and write might be worthwhile, but shouldn't go to the
usual logs...

  I just had to do an implementation of the Computer Measurement
Application Response Measurement API, the "ARM".  This is a facility
for logging performance data, and the calls look like:

	appl_id = arm_init("", "*", 0,0,0);
	tran_id_1 = arm_getid(appl_id, "e2e_read",
		"end-to-end read operation",0,0,0);
	tran_id_2 = arm_getid(appl_id, "disk_read",
		"local disk read operation",0,0,0);

	<get file read request>
	t1 = arm_start(tran_id_1,0,0,0);   
	<look up and open file>
	t2 = arm_start(tran_id_2,0,0,0);
	<read file into buffer>
	<send file to client>
	<get ack back>

  More information lives at,
and there is a downloadable software development kit.

  My implementation is a trivial one: it logs start and end times
in nanoseconds to a text file, which is postprocessed via an awk
script to produce messages like:

init 0 = "Samba file i/o stats" "" 
getid 1 = 0 "e2e_read" "end-to-end read operation" 0
getid 2 = 0 "disk_read" "local disk read operation" 0 
"local disk read operation" (2) = 0.997259 sec
"end-to-end read operation" (1) = 7.000101 sec
end 0

	This was actually from a dummy test using
	sleep(1) and sleep(6), logging via fprintf.

	If the team think it's a good idea, I can 
	do a samba-specific version for insertion
	via --with-arm. I don't recommend it be part of
	the default, at least initially, and compiling
	it in and out keeps it from causing performance

David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | //
Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb at

More information about the samba-technical mailing list