CIFS Load Generator source available ...
Esh, Andrew
AEsh at tricord.com
Thu Jun 27 09:03:05 GMT 2002
I ran into a compile problem on Linux Redhat 7.1. Here is a patch that fixes
it.
Index: include/config.h.in
===================================================================
RCS file: /cvsroot/cifs-load-gen/source/include/config.h.in,v
retrieving revision 1.1
diff -u -r1.1 config.h.in
--- include/config.h.in 27 Jun 2002 04:40:18 -0000 1.1
+++ include/config.h.in 27 Jun 2002 16:01:52 -0000
@@ -19,13 +19,13 @@
#undef HAVE_SYS_WAIT_H
/* Define if you have the <sys/ipc.h> header file. */
-#undef HAVE_SYS_IPC_H 1
+#undef HAVE_SYS_IPC_H
/* Define if you have the <sys/shm.h> header file. */
-#undef HAVE_SYS_SHM_H 1
+#undef HAVE_SYS_SHM_H
/* Define if you have the <sys/socket.h> header file. */
-#undef HAVE_SYS_SOCKET_H 1
+#undef HAVE_SYS_SOCKET_H
/* Define to `int' if <sys/types.h> doesn't define. */
#undef mode_t
and a cleanup:
Index: Makefile.in
===================================================================
RCS file: /cvsroot/cifs-load-gen/source/Makefile.in,v
retrieving revision 1.1
diff -u -r1.1 Makefile.in
--- Makefile.in 27 Jun 2002 00:41:53 -0000 1.1
+++ Makefile.in 27 Jun 2002 16:00:54 -0000
@@ -20,7 +20,6 @@
INSTALLCMD=/usr/bin/install -c
srcdir=.
-builddir=/usr10/home/rsharpe/snia_cifs_bm/source
SHELL=/bin/sh
# XXX: Perhaps this should be /bin/sh instead -- apparently autoconf
-----Original Message-----
From: Richard Sharpe [mailto:rsharpe at ns.aus.com]
Sent: Thursday, June 27, 2002 1:08 AM
To: samba-technical at lists.samba.org
Subject: CIFS Load Generator source available ...
CIFS Load Generator
Developed for SNIA CIFS Benchmarking Working Group
Richard Sharpe
Panasas, Inc & Samba Team
11-Jun-2002
INTRO
This is a short document on how to use the code and where it came from.
BACKGROUND
This code has been extracted from Samba's smbtorture utility.
It is now up on the samba.org site in CVS and can be checked out with:
cvs co cifs-load-gen
RUNNING IT
To run the code, simply execute ./bin/cifs_bm after having configured and
made the code.
./bin/cifs_bm -U<user%pass> -Wworkgroup -c <client-file> [-N clients] \
[-I<ip>] [-b >num>] //server-or-ip/share
NOTE. You need to know the max size of WriteX or ReadXs in the client file,
as cifs_bm defaults to 256*1024. Use a flag of '-b <num>' for the block size
you want. For example, '-b 1024' will give you a buffer of 1024*1024 bytes.
THE CLIENT FILE
The client file is essentially the same as smbtorture uses. There are a
number of them in the clients directory.
Each consists of a series of lines, each with either an operation to perform
on the server, or one of a number of special keywords.
The keywords are:
BM_SETUP: Provides a series of setup operations. Currently, the driver does
noting with this command, except set an internal variable called state to
BM_SETUP. No measurements are taken during this phase.
BM_WARMUP: Provides a series of warmup operations. Currently, the driver
does nothing with this command, except set an internal variable called state
to BM_WARMUP. No measurements are taken during this phase.
BM_MEASURE: Provides a series of operations that will be measured.
RECONNECT: Disconnect from the server and reconnect to it.
SYNC <n>: Wait for up to <n> seconds for the master to say go. It waits for
all the clients to SYNC.
There are about 14 commands that are implemented. Look at the collection of
.txt files to get an idea of what they are ...
Some of the bit fields are important. For example, on an:
NTCreateX <file> <flag1> <flag2> <FID>
command, <flag2> needs the 0x01 bit set if it is to ignore failures due to
files already existing.
An additional command is: Lock <file> etc ... Check the code for params for
now.
PROBLEMS
There are still many problems.
1. It would be nice if the child/client processes would synchronise each
phase with each other. A Sync command is now implemented.
2. FIND NEXT is not really implemented. This needs doing.
3. More operation types are needed. Lock is now implemented. However, see
below.
4. Some way to generate a load file would be nice.
5. There is no way to specifiy a schedule of users and passwords to use to
log onto the server.
6. NetBench specifies its driver file as a series of parts, each part
containing a series of commands. It then randomizes the order of the
parts. It would require a rewrite of cifs_bm to achieve this.
7. There is no way yet to spread the load over a series of interfaces.
8. There is no way to separate out connection to server, logging in and
connection to the share. They are all one event. Thus we cannot measure
the server's ability to handle logons (SessSetup&X), connections
(probing its ability to fork or create threads), and connecting to shares
(TCON etc). This calls for commands like: Tcon <share>, Tdis <share>,
etc.
9. The latency info needs to be kept in long longs, and the read and write
throughput needs to be cleaned up.
10. It would be nice to have an embedded programming language, like TCL or
...
11. It has been suggested by a guy from Sun that the current model of one
process per client might be affected by scheduler latencies. In addition
if we want to simulate really large numbers of clients, we might need to
move to a multi-threaded client.
Regards
-----
Richard Sharpe, rsharpe at ns.aus.com, rsharpe at samba.org,
sharpe at ethereal.com
-------------- next part --------------
HTML attachment scrubbed and removed
More information about the samba-technical
mailing list