~zulcss/samba/server-dailies-3.4

<indexterm id="appb-idx-959725-2" class="startofrange"><primary>configuring Samba</primary><secondary>performance tuning</secondary></indexterm>This appendix discusses various ways of performance tuning and system sizing with Samba. <firstterm>Performance tuning</firstterm> is the art of finding bottlenecks and adjusting to eliminate them. <emphasis>Sizing</emphasis> is the practice of eliminating bottlenecks by spending money to avoid having them in the first place. Normally, you won't have to worry about either with Samba. On a completely untuned server, Samba will happily support a small community of users. However, on a properly tuned server, Samba will support at least twice as many users. This chapter is devoted to outlining various performance-tuning and sizing techniques that you can use if you want to stretch your Samba server to the limit.</para>

<title>A Simple Benchmark</title>

<para>

<indexterm id="appb-idx-959739-0"><primary>Samba</primary><secondary>performance tuning</secondary><tertiary>benchmark for</tertiary></indexterm>

<indexterm id="appb-idx-959739-1"><primary>performance tuning</primary><secondary>benchmark for</secondary></indexterm>

<indexterm id="appb-idx-959739-2"><primary>configuring Samba</primary><secondary>performance tuning</secondary><tertiary>benchmark for</tertiary></indexterm>How do you know if you're getting reasonable performance? A simple benchmark is to compare Samba with FTP. <link linkend="appb-73167">Table 2.1</link> shows the throughput, in kilobytes per second, of a pair of servers: a medium-size Sun SPARC Ultra and a small Linux Pentium server. Numbers are reported in kilobytes per second (KB/s).</para>

<title>Sample Benchmark Benchmarks </title>

<thead>

<row>

<entry colname="col1"><para>Command</para></entry>

<entry colname="col3"><para>Untuned Samba</para></entry>

<entry colname="col4"><para>Tuned Samba</para></entry>

</row>

</thead>

<tbody>

<row>

<entry colname="col1"><para>Sparc get</para></entry>

</row>

<row>

<entry colname="col1"><para>Sparc put</para></entry>

</row>

<row>

<entry colname="col1"><para>Pentium get</para></entry>

</row>

<row>

<entry colname="col1"><para>Pentium put</para></entry>

100

101

102

</row>

103

104

</tbody>

105

</tgroup>

106

</table>

107

108

109

<para>If you run the same tests on your server, you probably won't see the same numbers. However, you <emphasis>should</emphasis> see similar ratios of Samba to FTP, probably in the range of 68 to 80 percent. It's not a good idea to base <emphasis>all</emphasis> of Samba's throughput against FTP. The golden rule to remember is this: if Samba is much slower than FTP, it's time to tune it.</para>

110

111

112

<para>You might think that an equivalent test would be to compare Samba to NFS. In reality, however, it's much less useful to compare their speeds. Depending entirely on whose version of NFS you have and how well it's tuned, Samba can be slower or faster than NFS. We usually find that Samba is faster, but watch out; NFS uses a different algorithm from Samba, so tuning options that are optimal for NFS may be detrimental for Samba. If you run Samba on a well-tuned NFS server, Samba may perform rather badly.</para>

113

114

115

<para>A more popular benchmark is Ziff-Davis' <emphasis>NetBench,</emphasis> a simulation of many users on client machines running word processors and accessing data on the SMB server. It's not a prefect measure (each NetBench client does about ten times the work of a normal user on our site), but it is a fair comparison of similar servers. In tests performed by Jeremy Allison in November 1998, Samba 2.0 on a SGI multiprocessor outperformed NT Server 4.0 (Patch Level 2) on an equivalent high-end Compaq. This was confirmed and strengthened by a Sm@rt Reseller test of NT and Linux on identical hardware in February 1999.</para>

116

117

118

<para>In April 1999, the Mindcraft test lab released a report about a test showing that Samba on a four-processor Linux machine was significantly slower than native file serving on the same machine running Windows NT. While the original report was slammed by the Open Source community because it was commissioned by Microsoft and tuned the systems to favor Windows NT, a subsequent test was fairer and generally admitted to reveal some areas where Linux needed to improve its performance, especially on multiprocessors. Little was said about Samba itself. Samba is known to scale well on multiprocessors, and exceeds 440MB/s on a four-processor SGI O200, beating Mindcraft's 310MB/s.</para>

119

120

121

<para>Relative performance will probably change as NT and PC hardware get faster, of course, but Samba is improving as well. For example, Samba 1.9.18 was faster only with more than 35 clients. Samba 2.0, however, is faster regardless of the number of clients. In short, Samba is very competitive with the best networking software in the industry, and is only getting better.</para>

122

123

124

<para>As we went to press, Andrew Tridgell released the alpha-test version suite of benchmarking programs for Samba and SMB networks. Expect even more work on performance from the Samba team in the future.</para>

125

</sect1>

126

127

128

129

130

131

132

133

134

135

136

<title>Samba Tuning</title>

137

138

139

<para>

140

<indexterm id="appb-idx-959765-0"><primary>tuning</primary><see>performance tuning</see></indexterm>That being said, let's discuss how you can take an already fast networking package and make it even faster.</para>

141

142

143

144

<title>Benchmarking</title>

145

146

147

<para>

148

<indexterm id="appb-idx-959749-0"><primary>Samba</primary><secondary>performance tuning</secondary><tertiary>benchmark for</tertiary></indexterm>

149

<indexterm id="appb-idx-959749-1"><primary>performance tuning</primary><secondary>benchmark for</secondary></indexterm>

150

<indexterm id="appb-idx-959749-2"><primary>configuring Samba</primary><secondary>performance tuning</secondary><tertiary>benchmark for</tertiary></indexterm>Benchmarking is an arcane and somewhat black art, but the level of expertise needed for simple performance tuning is fairly low. Since the Samba server's goal in life is to transfer files, we will examine only throughput, not response time to particular events, under the benchmarking microscope. After all, it's relatively easy to measure file transfer speed, and Samba doesn't suffer too badly from response-time problems that would require more sophisticated techniques.</para>

151

152

153

<para>Our basic strategy for this work will be:</para>

154

155

156

157

158

<listitem><para>Find a reasonably-sized file to copy and a program that reports on copy speeds, such as <filename>smbclient</filename>.</para></listitem>

159

160

<listitem><para>Find a quiet (or typical) time to do the test.</para></listitem>

161

162

<listitem><para>Pre-run each test a few times to preload buffers.</para></listitem>

163

164

<listitem><para>Run tests several times and watch for unusual results.</para></listitem>

165

166

<listitem><para>Record each run in detail.</para></listitem>

167

168

<listitem><para>Compare the average of the valid runs to expected values.</para></listitem>

169

170

</itemizedlist>

171

172

<para>After establishing a baseline using this method, we can adjust a single parameter and do the measurements all over again. An empty table for your tests is provided at the end of this chapter.</para>

173

</sect2>

174

175

176

177

178

179

180

<title>Things to Tweak</title>

181

182

183

<para>There are literally thousands of Samba setting combinations that you can use in search of that perfect server. Those of us with lives outside of system administration, however, can narrow down the number of options to those listed in this section, which are the most likely to affect overall throughput. They are presented roughly in order of impact.</para>

184

185

186

187

<title>Log level</title>

188

189

190

<para>

191

<indexterm id="appb-idx-959753-0"><primary>log files/logging</primary><secondary>levels of</secondary><tertiary>tuning</tertiary></indexterm>This is an obvious one. Increasing the logging level (<literal>log</literal>

192

<indexterm id="appb-idx-960330-0"><primary>log level option</primary></indexterm>

193

<indexterm id="appb-idx-960330-1"><primary>debug level option</primary></indexterm> <literal>level</literal> or <literal>debug</literal> <literal>level</literal> configuration options) is a good way to debug a problem, unless you happen to be searching for a performance problem! As mentioned in <link linkend="ch04-21486">Chapter 4</link>, Samba produces a ton of debugging messages at level 3 and above, and writing them to disk or syslog is a slow operation. In our <filename>smbclient/ftp</filename> tests, raising the log level from 0 to 3 cut the untuned <literal>get</literal> <literal>speed</literal> from 645.3 to 622.2KB/s, or roughly 5 percent. Higher log levels were even worse.</para>

194

</sect3>

195

196

197

198

199

<title>Socket options</title>

200

201

202

<para>The next thing to look at are the <literal>socket</literal>

203

<indexterm id="appb-idx-960332-0"><primary>socket options configuration options</primary></indexterm> <literal>options</literal> configuration options. These are really host system tuning options, but they're set on a per-connection basis, and can be reset by Samba on the sockets it employs by adding <literal>socket</literal> <literal>options</literal> <literal>=</literal> <literal>option</literal> to the <literal>[global]</literal> section of your <filename>smb.conf </filename>file. Not all of these options are supported by all vendors; check your vendor's manual pages on <emphasis>setsockopt </emphasis>(1) or <emphasis>socket </emphasis>(5) for details.</para>

204

205

206

<para>The main options are:</para>

207

208

209

210

<varlistentry><term><literal>TCP_NODELAY</literal></term>

211

<listitem><para>Have the server send as many packets as necessary to keep delay low. This is used on telnet connections to give good response time, and is used—somewhat counter-intuitively—to get good speed even when doing small requests or when acknowledgments are delayed (as seems to occur with Microsoft TCP/IP). This is worth a 30-50 percent speedup by itself. Incidentally, in Samba 2.0.4, <literal>socket</literal> <literal>options</literal> <literal>=</literal> <literal>TCP_NODELAY</literal> became the default value for that option.</para></listitem>

212

</varlistentry>

213

214

215

<varlistentry><term><literal>IPTOS_LOWDELAY</literal></term>

216

<listitem><para>This is another option that trades off throughput for lower delay, but which affects routers and other systems, not the server. All the IPTOS options are new; they're not supported by all operating systems and routers. If they are supported, set <literal>IPTOS_LOWDELAY</literal> whenever you set <literal>TCP_NODELAY</literal>.</para></listitem>

217

</varlistentry>

218

219

220

<varlistentry><term><literal>SO_SNDBUF</literal> <literal>and</literal> <literal>SO_RCVBUF</literal></term>

221

<listitem><para>The send and receive buffers can often be the reset to a value higher than that of the operating system. This yields a marginal increase of speed (until it reaches a point of diminishing returns).</para></listitem>

222

</varlistentry>

223

224

225

<varlistentry><term><literal>SO_KEEPALIVE</literal></term>

226

<listitem><para>This initiates a periodic (four-hour) check to see if the client has disappeared. Expired connections are addressed somewhat better with Samba's <literal>keepalive</literal> and <literal>dead</literal> <literal>time</literal> options. All three eventually arrange to close dead connections, returning unused memory and process-table entries to the operating system.</para></listitem>

227

</varlistentry>

228

</variablelist>

229

230

231

<para>There are several other socket options you might look at, (e.g., <literal>SO_SNDLOWAT</literal>), but they vary in availability from vendor to vendor. You probably want to look at <citetitle>TCP/IP Illustrated</citetitle> if you're interested in exploring more of these options for performance tuning with Samba.</para>

232

</sect3>

233

234

235

236

237

<title>read raw and write raw</title>

238

239

240

<para>

241

<indexterm id="appb-idx-959754-0"><primary>read raw, tuning</primary></indexterm>

242

<indexterm id="appb-idx-959754-1"><primary>write raw, tuning</primary></indexterm>These are important performance configuration options; they enable Samba to use large reads and writes to the network, of up to 64KB in a single SMB request. They also require the largest SMB packet structures, <literal>SMBreadraw</literal> and <literal>SMBwriteraw</literal>, from which the options take their names. Note that this is not the same as a Unix <emphasis>raw read</emphasis>. This Unix term usually refers to reading disks without using the files system, quite a different sense from the one described here for Samba.</para>

243

244

245

<para>In the past, some client programs failed if you tried to use <literal>read</literal> <literal>raw</literal>. As far as we know, no client suffers from this problem any more. Read and write raw default to <literal>yes</literal>, and should be left on unless you find you have one of the buggy clients.</para>

246

</sect3>

247

248

249

250

251

<title>Opportunistic locking</title>

252

253

254

<para>

255

<indexterm id="appb-idx-959755-0"><primary>opportunistic locking</primary><secondary>tuning</secondary></indexterm>

256

<indexterm id="appb-idx-959755-1"><primary>locks/locking files</primary><secondary>opportunistic locking</secondary><tertiary>tuning of</tertiary></indexterm>Opportunistic locks, or <emphasis>oplocks</emphasis>, allow clients to cache files locally, improving performance on the order of 30 percent. This option is now enabled by default. For read-only files, the <literal>fake</literal> <literal>oplocks</literal> provides the same functionality without actually doing any caching. If you have files that cannot be cached, <emphasis>oplocks</emphasis> can be turned off.</para>

257

258

259

<para>Database files should never be cached, nor should any files that are updated both on the server and the client and whose changes must be immediately visible. For these files, the <literal>veto</literal> <literal>oplock</literal>

260

<indexterm id="appb-idx-960336-0"><primary>oplock files option</primary></indexterm> <literal>files</literal> option allows you to specify a list of individual files or a pattern containing wildcards to avoid caching. <emphasis>oplocks</emphasis> can be turned off on a share-by-share basis if you have large groups of files you don't want cached on clients. See <link linkend="SAMBA-CH-5">Chapter 5</link>, for more information on opportunistic locks.</para>

261

</sect3>

262

263

264

265

266

<title>IP packet size (MTU)</title>

267

268

269

<para>

270

<indexterm id="appb-idx-959756-0"><primary>IP packet size, tuning</primary></indexterm>Networks generally set a limit to the size of an individual transmission or packet This is called the Maximum Segment Size, or if the packet header size is included, the <indexterm id="appb-idx-959757-0"><primary>Maximum Transport Unit (MTU)</primary></indexterm>

271

<indexterm id="appb-idx-959757-1"><primary>MTU (Maximum Transport Unit)</primary></indexterm>Maximum Transport Unit (MTU). This MTU is not set by Samba, but Samba needs to use a <literal>max</literal> <literal>xmit</literal> (write size) bigger than the MTU, or throughput will be reduced. This is discussed in further detail in the following note. The MTU is normally preset to 1500 bytes on an Ethernet and 4098 bytes on FDDI. In general, having it too low cuts throughput, and having it too high causes a sudden performance dropoff due to fragmentation and retransmissions.</para>

272

273

274

275

<para>If you are communicating over a router, some systems will assume the router is a serial link (e.g., a T1) and set the MTU to more or less 536 bytes. Windows 95 makes this mistake, which causes nearby clients to perform well, but clients on the other side of the router to be noticeably slower. If the client makes the opposite error and uses a large MTU on a link which demands a small one, the packets will be broken up into fragments. This slows transfers slightly, and any networking errors will cause multiple fragments to be retransmitted, which slows Samba significantly. Fortunately, you can modify the Windows MTU size to prevent either error. To understand this in more detail, see "The Windows 95 Networking Frequently Asked Questions (FAQ)" at <systemitem role="url">http://www.stanford.edu/~llurch/win95netbugs/faq.html</systemitem>, which explains how to override the Windows MTU and Window Size.</para>

276

277

</tip>

278

</sect3>

279

280

281

282

283

<title>The TCP receive window</title>

284

285

286

<para>

287

<indexterm id="appb-idx-959758-0"><primary>TCP/IP networking protocol</primary><secondary>receive window, tuning</secondary></indexterm>TCP/IP works by breaking down data into small packets that can be transmitted from one machine to another. When each packet is transmitted, it contains a checksum that allows the receiver to check the packet data for potential errors in transmission. Theoretically, when a packet is received and verified, an acknowledgment packet should be sent back to the sender that essentially says, "Everything arrived intact: please continue."</para>

288

289

290

<para>In order to keep things moving, however, TCP accepts a range (window) of packets that allows a sender to keep transmitting without having to wait for an acknowledgment of every single packet. (It can then bundle a group of acknowledgments and transmit them back to the sender at the same time.) In other words, this receive window is the number of bytes that the sender can transmit before it has to stop and wait for a receiver's acknowledgment. Like the MTU, it is automatically set based on the type of connection. Having the window too small causes a lot of unnecessary waiting for acknowledgment messages. Various operating systems set moderate buffer sizes on a per-socket basis to keep one program from hogging all the memory.</para>

291

292

293

<para>The buffer sizes are assigned in bytes, such as <literal>SO_SNDBUF=8192</literal> in the <literal>socket</literal> <literal>options</literal> line. Thus, an example <literal>socket</literal> <literal>options</literal> configuration option is:</para>

294

295

296

<programlisting>socket options = SO_SNDBUF=8192</programlisting>

297

298

299

<para>Normally, one tries to set these socket options higher than the default: 4098 in SunOS 4.1.3 and SVR4, and 8192-16384 in AIX, Solaris, and BSD. 16384 has been suggested as a good starting point: in a non-Samba test mentioned in Stevens' book, it yielded a 40 percent improvement. You'll need to experiment, because performance will fall off again if you set the sizes too high. This is illustrated in <link linkend="appb-34738">Figure 2.1</link>, a test done on a particular Linux system.</para>

300

301

302

303

<title>SO_SNDBUF size and performance</title>

304

305

306

</figure>

307

308

<para>Setting the socket options <literal>O_SNDBUF</literal> and <literal>SO_RCVBUF</literal> to less than the default is inadvisable. Setting them higher improves performance, up to a network-specific limit. However, once you exceed that limit, performance will abruptly level off.</para>

309

</sect3>

310

311

312

313

314

<indexterm id="appb-idx-960371-0"><primary>max xmit option</primary></indexterm>

315

<title>

316

max xmit</title>

317

318

319

<para>

320

<indexterm id="appb-idx-960373-0"><primary>write size, tuning</primary></indexterm>In Samba, the option that is directly related with the MTU and window size is <literal>max</literal> <literal>xmit</literal>. This option sets the largest block of data Samba will try to write at any one time. It's sometimes known as the <firstterm>write size</firstterm>, although that is not the name of the Samba configuration option.</para>

321

322

323

<para>Because the percentage of each block required for overhead falls as the blocks get larger, max xmit is conventionally set as large as possible. It defaults to the protocol's upper limit, which is 64 kilobytes. The smallest value that doesn't cause significant slowdowns is 2048. If it is set low enough, it will limit the largest packet size that Samba will be able to negotiate. This can be used to simulate a small MTU if you need to test an unreliable network connection. However, such a test should not be used in production for reducing the effective MTU.</para>

324

</sect3>

325

326

327

328

329

330

331

332

<para>

333

<indexterm id="appb-idx-959760-0"><primary>read size, tuning</primary></indexterm>If <literal>max</literal> <literal>xmit</literal> is commonly called the write size, you'd expect <literal>read</literal> <literal>size</literal> to be the maximum amount of data that Samba would want to read from the client via the network. Actually, it's not. In fact, it's an option to trigger <firstterm>write ahead</firstterm>

334

<indexterm id="appb-idx-959764-0"><primary>write ahead, tuning</primary></indexterm>. This means that if Samba gets behind reading from the disk and writing to the network (or vice versa) by the specified amount, it will start overlapping network writes with disk reads (or vice versa).</para>

335

336

337

<para>The read size doesn't have a big performance effect on Unix, unless you set its value quite small. At that point, it causes a detectable slowdown. For this reason, it defaults to 2048 and can't be set lower than 1024.</para>

338

</sect3>

339

340

341

342

343

<title>read prediction </title>

344

345

346

<para>

347

<indexterm id="appb-idx-959766-0"><primary>read prediction, testing</primary></indexterm>Besides being counterintuitive, this option is also obsolete. It enables Samba to read ahead on files opened read only by the clients. The option is disabled in Samba 2.0 (and late 1.9) Because it interferes with opportunistic locking.</para>

348

</sect3>

349

</sect2>

350

351

352

353

354

355

356

<title>Other Samba Options</title>

357

358

359

<para>

360

<indexterm id="appb-idx-959775-0" class="startofrange"><primary>Samba</primary><secondary>performance tuning</secondary><tertiary>other options for</tertiary></indexterm>

361

<indexterm id="appb-idx-959775-1" class="startofrange"><primary>performance tuning</primary><secondary>other options for</secondary></indexterm>

362

<indexterm id="appb-idx-959775-2" class="startofrange"><primary>configuring Samba</primary><secondary>performance tuning</secondary><tertiary>other options for</tertiary></indexterm>The following Samba options will affect performance if they're set incorrectly, much like the debug level. They're mentioned here so you will know what to look out for:</para>

363

364

365

366

367

<indexterm id="appb-idx-960358-0"><primary>hidden files</primary><secondary>options for</secondary></indexterm><literal>hide files</literal></term>

368

<listitem><para>Providing a pattern to identify files hidden by the Windows client <literal>hide</literal> <literal>files</literal> will result in any file matching the pattern being passed to the client with the DOS hidden attribute set. It requires a pattern match per file when listing directories, and slows the server noticeably.</para></listitem>

369

</varlistentry>

370

371

372

<varlistentry><term><literal>lpq cache time</literal>

373

<indexterm id="appb-idx-960359-0"><primary>lpq cache time option</primary></indexterm></term>

374

<listitem><para>If your <literal>lpq</literal> (printer queue contents) command takes a long time to complete, you should increase <literal>lpq</literal> <literal>cache</literal> <literal>time</literal> to a value higher than the actual time required for <literal>lpq</literal> to execute, so as to keep Samba from starting a new query when one's already running. The default is 10 seconds, which is reasonable.</para></listitem>

375

</varlistentry>

376

377

378

<varlistentry><term><literal>strict locking</literal>

379

<indexterm id="appb-idx-960360-0"><primary>strict locking option</primary></indexterm></term>

380

<listitem><para>Setting the <literal>strict</literal> <literal>locking</literal> option causes Samba to check for locks on every access, not just when asked to by the client. The option is primarily a bug-avoidance feature, and can prevent ill-behaved DOS and Windows applications from corrupting shared files. However, it is slow and should typically be avoided.</para></listitem>

381

</varlistentry>

382

383

384

<varlistentry><term><literal>strict sync</literal>

385

<indexterm id="appb-idx-960361-0"><primary>strict sync option</primary></indexterm></term>

386

<listitem><para>Setting <literal>strict</literal> <literal>sync</literal> will cause Samba to write each packet to disk and wait for the write to complete whenever the client sets the sync bit in a packet. Windows 98 Explorer sets the bit in all packets transmitted, so if you turn this on, anyone with Windows 98 will think Samba servers are horribly slow.</para></listitem>

387

</varlistentry>

388

389

390

<varlistentry><term><literal>sync always</literal>

391

<indexterm id="appb-idx-960362-0"><primary>sync always option</primary></indexterm></term>

392

<listitem><para>Setting <literal>sync</literal> <literal>always</literal> causes Samba to flush every write to disk. This is good if your server crashes constantly, but the performance costs are immense. SMB servers normally use oplocks and automatic reconnection to avoid the ill effects of crashes, so setting this option is not normally necessary.</para></listitem>

393

</varlistentry>

394

395

396

397

<indexterm id="appb-idx-960363-0"><primary>wide links option</primary></indexterm><literal>wide links</literal></term>

398

<listitem><para>Turning off <literal>wide</literal> <literal>links</literal> prevents Samba from following symbolic links in one file share to files that are not in the share. It is turned on by default, since following links in Unix is not a security problem. Turning it off requires extra processing on every file open. If you do turn off wide links, be sure to turn on <literal>getwd</literal> <literal>cache</literal> to cache some of the required data.</para>

399

400

401

<para>There is also a <literal>follow</literal> <literal>symlinks</literal> option that can be turned off to prevent following any symbolic links at all. However, this option does not pose a performance problem.</para></listitem>

402

</varlistentry>

403

404

405

406

<indexterm id="appb-idx-960364-0"><primary>getwd cache option</primary></indexterm><literal>getwd cache</literal></term>

407

<listitem><para>This option caches the path to the current directory, avoiding long tree-walks to discover it. It's a nice performance improvement on a printer server or if you've turned off <literal>wide</literal> <literal>links</literal>.</para></listitem>

408

</varlistentry>

409

</variablelist>

410

</sect2>

411

412

413

414

415

416

417

<title>Our Recommendations </title>

418

419

420

<para>

421

<indexterm id="appb-idx-959782-0"><primary>performance tuning</primary><secondary>recommended enhancements</secondary></indexterm>Here's an <filename>smb.conf</filename> file that incorporates the recommended performance enhancements so far. Comments have been added on the right side.</para>

422

423

424

<programlisting>[global]

425

log level = 1 # Default is 0

426

socket options = TCP_NODELAY IPTOS_LOWDELAY

427

read raw = yes # Default

428

write raw = yes # Default

429

oplocks = yes # Default

430

max xmit = 65535 # Default

431

dead time = 15 # Default is 0

432

getwd cache = yes

433

lpq cache = 30

434

[okplace]

435

veto oplock files = this/that/theotherfile

436

[badplace]

437

oplocks = no</programlisting>

438

</sect2>

439

</sect1>

440

441

442

443

444

445

446

447

448

449

450

<title>Sizing Samba Servers</title>

451

452

453

<para>

454

<indexterm id="appb-idx-959783-0" class="startofrange"><primary>Samba server</primary><secondary>sizing</secondary></indexterm>

455

<indexterm id="appb-idx-959783-1" class="startofrange"><primary>sizing Samba servers</primary></indexterm>Sizing is a way to prevent bottlenecks before they occur. The preferred way to do this is to know how many requests per second or how many kilobytes per second the clients will need, and ensure that all the components of the server provide at least that many.</para>

456

457

458

459

<title>The Bottlenecks</title>

460

461

462

<para>

463

<indexterm id="appb-idx-959791-0" class="startofrange"><primary>bottlenecks</primary></indexterm>The <indexterm id="appb-idx-959799-0"><primary>bottlenecks</primary><secondary>types of</secondary></indexterm>three primary bottlenecks you should worry about are CPU, disk I/O, and the network. For most machines, CPUs are rarely a bottleneck. A single Sun SPARC 10 CPU can start (and complete) between 700 and 800 I/O operations a second, giving approximately 5,600 to 6,400KB/s of throughput when the data averages around 8KBs (a common buffer size). A single Intel Pentium 133 can do less only because of somewhat slower cache and bus interfaces, not due to lack of CPU power. Purpose-designed Pentium servers, like some Compaq servers, will be able to start 700 operations per CPUs, on up to four CPUs.</para>

464

465

466

<para>Too little memory, on the other hand, can easily be a bottleneck; each Samba process will use between 600 and 800KB on Intel Linux, and more on RISC CPUs. Having less will cause an increase in virtual memory paging and therefore a performance hit. On Solaris, where it has been measured, <emphasis>smbd</emphasis> will use 2.6 MB for program and shared libraries, plus 768KB for each connected client. <emphasis>nmbd</emphasis> occupies 2.1 MB, plus 496KB extra for its (single) auxiliary process.</para>

467

468

469

<para>Hard disks will always bottleneck at a specific number of I/O operations per second: for example, each 7200 RPM SCSI disk is capable of performing 70 operations per second, for a throughput of 560KB/s; a 4800 RPM disk will perform fewer than 50, for a throughput of 360KB/s. A single IDE disk will do still fewer. If the disks are independent, or striped together in a RAID 1 configuration, they will each peak out at 400 to 560KB/s and will scale linearly as you add more. Note that this is true only of RAID 1. RAID levels other than 1 (striping) add extra overhead.</para>

470

471

472

<para>Ethernets (and other networks) are obvious bottleneck: a 10 Mb/s (mega<emphasis>bits</emphasis>/second) Ethernet will handle around 1100KB/s (kilo<emphasis>bytes</emphasis>/s) using 1500-byte packets A 100 Mb/s Fast Ethernet will bottleneck below 65,000KB/s with the same packet size. FDDI, at 155 Mb/s will top out at approximately 6,250KB/s, but gives good service at even 100 percent load and transmits much larger packets (4KB).</para>

473

474

475

<para>ATM should be much better, but as of the writing of this book it was too new to live up to its potential; it seems to deliver around 7,125 Mb/s using 9KB packets.</para>

476

477

478

<para>Of course, there can be other bottlenecks: more than one IDE disk per controller is not good, as are more than three 3600 SCSI-I disks per slow/narrow controller, or more than three 7200 SCSI-II disks per SCSI-II fast/wide controller. RAID 5 is also slow, as it requires twice as many writes as independent disks or RAID 1.</para>

479

480

481

<para>After the second set of Ethernets and the second disk controller, start worrying about bus bandwidth, especially if you are using ISA/EISA buses.</para>

482

</sect2>

483

484

485

486

487

488

489

<title>Reducing Bottlenecks </title>

490

491

492

<para>

493

<indexterm id="appb-idx-959800-0" class="startofrange"><primary>bottlenecks</primary><secondary>reducing</secondary></indexterm>From the information above we can work out a model that will tell us the maximum capability of a given machine. The data is mostly taken from <indexterm id="appb-idx-959815-0"><primary>Wong, Brian</primary></indexterm>

494

<indexterm id="appb-idx-959815-1"><primary>resources for further information</primary><secondary>Solaris servers</secondary></indexterm>Brian Wong's <citetitle>Configuration and Capacity Planning for Solaris Servers</citetitle>,<citetitle>

495

496

497

498

<para>See Wong. Brian L, <emphasis>Configuration and Capacity Planning for Solaris Servers</emphasis>, Englewood Cliffs, NJ (Sun/Prentice-Hall), 1997, ISBN 0-13-349952-9.</para>

499

500

501

</footnote></citetitle> so there is a slight Sun bias to our examples.</para>

502

503

504

<para>A word of warning: this is not a complete model. Don't assume that this model will predict every bottleneck or even be within 10 percent in its estimates. A model to predict performance instead of one to warn you of bottlenecks would be much more complex and would contain rules like "not more than three disks per SCSI chain". (A good book on real models is Raj Jain's <citetitle>The Art of Computer Systems Performance Analysis</citetitle>.<footnote label="2" id="appb-pgfId-951230">

505

506

507

<para>See Jain, Raj, <emphasis>The Art of Computer Systems Performance Analysis</emphasis>, New York, NY (John Wiley and Sons), 1991, ISBN 0-47-150336-3.</para>

508

509

510

</footnote>) With that warning, we present the system in <link linkend="appb-98866">Figure 2.2</link>.</para>

511

512

513

514

<title>Data flow through a Samba server, with possible bottlenecks</title>

515

516

517

</figure>

518

519

<para>The flow of data should be obvious. For example, on a read, data flows from the disk, across the bus, through or past the CPU, and to the network interface card (NIC). It is then broken up into packets and sent across the network. Our strategy here is to follow the data through the system and see what bottlenecks will choke it off. Believe it or not, it's rather easy to make a set of tables that list the maximum performance of common disks, CPUs, and network cards on a system. So that's exactly what we're going to do.</para>

520

521

522

<para>Let's take a concrete example: a Linux Pentium 133 MHz machine with a single 7200 RPM data disk, a PCI bus, and a 10-Mb/s Ethernet card. This is a perfectly reasonable server. We start with <link linkend="appb-78077">Table 2.2</link>, which describes the hard drive—the first potential bottleneck in the system.</para>

523

524

525

526

<title>Disk Throughput </title>

527

528

529

530

531

532

<thead>

533

<row>

534

535

536

537

<entry colname="col2"><para>I/O Operations/second</para></entry>

538

539

<entry colname="col3"><para>KB/second</para></entry>

540

541

</row>

542

543

</thead>

544

545

<tbody>

546

<row>

547

548

549

550

551

552

553

554

</row>

555

556

<row>

557

558

559

560

561

562

563

564

</row>

565

566

<row>

567

568

569

570

571

572

573

574

</row>

575

576

</tbody>

577

</tgroup>

578

</table>

579

580

581

<para>Disk throughput is the number of kilobytes of data that a disk can transfer per second. It is computed from the number of 8KB I/O operations per second a disk can perform, which in turn is strongly influenced by disk RPM and bit density. In effect, the question is: how much data can pass below the drive heads in one second? With a single 7200 RPM disk, the example server will give us 70 I/O operations per second at roughly 560KB/s.</para>

582

583

584

<para>The second possible bottleneck is the CPU. The data doesn't actually flow through the CPU on any modern machines, so we have to compute throughput somewhat indirectly.</para>

585

586

587

<para>The CPU has to issue I/O requests and handle the interrupts coming back, then transfer the data across the bus to the network card. From much past experimentation, we know that the overhead that dominates the processing is consistently in the filesystem code, so we can ignore the other software being run. We compute the throughput by just multiplying the (measured) number of file I/O operations per second that a CPU can process by the same 8K average request size. This gives us the results shown in <link linkend="appb-42029">Table 2.3</link>.</para>

588

589

590

591

<title>CPU Throughput </title>

592

593

594

595

596

597

<thead>

598

<row>

599

600

601

602

<entry colname="col2"><para>I/O Operations/second</para></entry>

603

604

<entry colname="col3"><para>KB/second</para></entry>

605

606

</row>

607

608

</thead>

609

610

<tbody>

611

<row>

612

613

<entry colname="col1"><para>Intel Pentium 133</para></entry>

614

615

616

617

618

619

</row>

620

621

<row>

622

623

<entry colname="col1"><para>Dual Pentium 133</para></entry>

624

625

626

627

628

629

</row>

630

631

<row>

632

633

<entry colname="col1"><para>Sun SPARC II</para></entry>

634

635

636

637

638

639

</row>

640

641

<row>

642

643

<entry colname="col1"><para>Sun SPARC 10</para></entry>

644

645

646

647

648

649

</row>

650

651

<row>

652

653

<entry colname="col1"><para>Sun Ultra 200</para></entry>

654

655

656

657

658

</row>

659

660

</tbody>

661

</tgroup>

662

</table>

663

664

665

<para>Now we put the disk and the CPU together: in the Linux example, we have a single 7200 RPM disk, which can give us 560KB/s, and a CPU capable of starting 700 I/O operations, which could give us 5600KB/s. So far, as you would expect, our bottleneck is clearly going to be the hard disk.</para>

666

667

668

<para>The last potential bottleneck is the network. If the network speed is below 100 Mb/s, the bottleneck will be the network speed. After that, the design of the network card is more likely to slow us down. <link linkend="appb-67604">Table 2.4</link> shows us the average throughput of many types of data networks. Although network speed is conventionally measured in bits per second, <link linkend="appb-67604">Table 2.4</link> lists bytes per second to make comparison with the disk and CPU (<link linkend="appb-78077">Table 2.2</link> and <link linkend="appb-42029">Table 2.3</link>) easier.</para>

669

670

671

672

673

<title>Network Throughput </title>

674

675

676

677

678

<thead>

679

<row>

680

681

<entry colname="col1"><para>Network Type</para></entry>

682

683

<entry colname="col2"><para>KB/second</para></entry>

684

685

</row>

686

687

</thead>

688

689

<tbody>

690

<row>

691

692

693

694

695

696

</row>

697

698

<row>

699

700

701

702

703

704

</row>

705

706

<row>

707

708

<entry colname="col1"><para> Ethernet 10m</para></entry>

709

710

711

712

</row>

713

714

<row>

715

716

<entry colname="col1"><para> Token ring</para></entry>

717

718

719

720

</row>

721

722

<row>

723

724

725

726

727

728

</row>

729

730

<row>

731

732

<entry colname="col1"><para> Ethernet 100m</para></entry>

733

734

735

736

737

<para>These will increase. For example, Crays, Sun Ultras, and DEC/Compaq Alphas already have bettered these figures.</para>

738

739

740

</footnote></para></entry>

741

742

</row>

743

744

<row>

745

746

747

748

749

750

</row>

751

752

</tbody>

753

</tgroup>

754

</table>

755

756

757

<para>In the running example, we have a bottleneck at 560KB/s due to the disk. <link linkend="appb-67604">Table 2.4</link> shows us that a standard 10 megabit per second Ethernet (1,113KB/s) is far faster than the disk. Therefore, the hard disk is still the limiting factor. (This scenario, by the way, is very common.) Just by looking at the tables, we can predict that small servers won't have CPU problems, and that large ones with multiple CPUs will support striping and multiple Ethernets long before they start running out of CPU power. This, in fact, is exactly what happens.</para>

758

</sect2>

759

760

761

762

763

764

765

<title>Practical Examples</title>

766

767

768

<para>An example from <emphasis>Configuration and Capacity Planning for Solaris Servers</emphasis> (Wong) shows that a dual-processor SPARCstation 20/712 with four Ethernets and six 2.1 GB disks will spend all its time waiting for the disks to return some data. If it was loaded with disks (Brian Wong suggests as many as 34 of them), it would still be held below 1,200KB/s by the Ethernet cards. To get the performance the machine is capable of, we would need to configure multiple Ethernets, 100 Mbps Fast Ethernet, or 155 Mbps FDDI.</para>

769

770

771

<para>The progression you'd work through to get that conclusion looks something like <link linkend="appb-26613">Table 2.5</link>.</para>

772

773

774

775

<title>Tuning a Medium-Sized Server </title>

776

777

778

779

780

781

782

783

<thead>

784

<row>

785

786

<entry colname="col1"><para>Machine</para></entry>

787

788

<entry colname="col2"><para>Disk Throughput</para></entry>

789

790

<entry colname="col3"><para>CPU Throughput</para></entry>

791

792

<entry colname="col4"><para>Network Throughput</para></entry>

793

794

<entry colname="col5"><para>Actual Throughput</para></entry>

795

796

</row>

797

798

</thead>

799

800

<tbody>

801

<row>

802

803

<entry colname="col1"><para>Dual SPARC 10, 1 disk</para></entry>

804

805

806

807

808

809

810

811

812

813

</row>

814

815

<row>

816

817

<entry colname="col1"><para>Add 5 more disks</para></entry>

818

819

820

821

822

823

824

825

826

827

</row>

828

829

<row>

830

831

<entry colname="col1"><para>Add 3 more Ethernets</para></entry>

832

833

834

835

836

837

838

839

840

841

</row>

842

843

<row>

844

845

<entry colname="col1"><para>Change to using a 20-disk array</para></entry>

846

847

848

849

850

851

852

853

854

855

</row>

856

857

<row>

858

859

<entry colname="col1"><para>Use dual 100 Mbps ether</para></entry>

860

861

862

863

864

865

866

867

868

869

</row>

870

871

</tbody>

872

</tgroup>

873

</table>

874

875

876

<para>Initially, the bottleneck is the disk with only 560 MB/s of throughput available. Our solution is to add five more disks. This gives us more throughput on the disks than on the Ethernet, so then the Ethernet becomes the problem. Consequently, as we continue to expand, we go back and forth several times between these two. As you add disks, CPUs, and network cards, the bottleneck moves. Essentially, the strategy is to add more equipment to try to avoid each bottleneck until you reach your target performance, or (unfortunately) you either can't add any more or run out of money.</para>

877

878

879

<para>Our experience bears out this kind of calculation; a large SPARC 10 file server that one author maintained was quite capable of saturating an Ethernet plus about a third of an FDDI ring when using two processors. It did nearly as well with a single processor, albeit with a fast operating system and judicious over-optimization.</para>

880

881

882

<para>The same process applies to other brands of purpose-designed servers. We found the same rules applied to DECstation 2100s as to the newest Alphas or Compaqs, old MIPS 3350s and new SGI O2s. In general, a machine offering multi-CPU server configurations will have enough bus bandwidth and CPU power to reliably bottleneck on hard disk I/O when doing file service. As one would hope, considering the cost!</para>

883

</sect2>

884

885

886

887

888

889

890

<title>How Many Clients can Samba Handle?</title>

891

892

893

<para>Well, that depends entirely on how much data each user consumes. A small server with three SCSI-1 disks, which can serve about 960KB/s of data, will support between 36 and 80 clients in an ordinary office environment where they are typically loading, and saving equal-sized spreadsheets or word processing documents (36 clients × 2.3 transfers/second × 12k file 1 MB/s).</para>

894

895

896

<para>On the same server in a development environment with programmers running a fairly heavy edit-compile-test cycle, one can easily see requests for 1 MB/s, limiting the server to 25 or fewer clients. To take this a bit further, an imaging system whose clients each require 10 MB/s will perform poorly no matter how big a server is if they're all on a 10 MB/s Ethernet. And so on.</para>

897

898

899

<para>If you don't know how much data an average user consumes, you can size your Samba servers by patterning them after existing NFS, Netware, or LAN Manager servers. You should be especially careful that the new servers have as many disks and disk controllers as the ones you've copied. This technique is appropriately called "punt and hope."</para>

900

901

902

<para>If you know how many clients an existing server can support, you're in <emphasis>much</emphasis> better shape. You can analyze the server to see what its maximum capacity is and use that to estimate how much data they must be demanding. For example, if serving home directories to 30 PCs from a PC server with two IDE disks is just too slow, and 25 clients is about right, then you can safely assume you're bottlenecked on Ethernet I/O (approximately 375KB) rather than disk I/O (up to 640KB). If so, you can then conclude that the clients are demanding 15 (that is, 375/25)KB/s on average.</para>

903

904

905

<para>Supporting a new lab of 75 clients will mean you'll need 1,125KB/s, spread over multiple (preferably three) Ethernets, and a server with at least three 7200 RPM disks and a CPU capable of keeping up. These requirements can be met by a Pentium 133 or above with the bus architecture to drive them all at full speed (e.g., PCI).</para>

906

907

908

<para>A custom-built PC server or a multiprocessor-capable workstation like a Sun Sparc, a DEC/Compaq Alpha, an SGI, or the like, would scale up easier, as would a machine with fast Ethernet, plus a switching hub to drive the client machines on individual 10 MB/s Ethernets.</para>

909

910

911

912

<title>How to guess</title>

913

914

915

<para>If you have no idea at all what you need, the best thing is to try to guess based on someone else's experience. Each individual client machine can average from less than 1 I/O per second (normal PC or Mac used for sales/accounting) to as much as 4 (fast workstation using large applications). A fast workstation running a compiler can happily average 3-4 MB/s in data transfer requests, and an imaging system can demand even more.</para>

916

917

918

<para>Our recommendation? Spy on someone with a similar configuration and try to estimate their bandwidth requirements from their bottlenecks and the volume of the screams from their users. We also recommend Brian Wong's <citetitle>Configuration and Capacity Planning for Solaris Servers</citetitle>. While he uses Sun Solaris foremost in his examples, his bottlenecks are disks and network cards, which are common among all the major vendors. His tables for FTP servers also come very close to what we calculated for Samba servers, and make a good starting point.<indexterm id="appb-idx-959809-0" class="endofrange" startref="appb-idx-959800-0"/></para>

919

</sect3>

920

</sect2>

921

922

923

924

925

926

927

<title>Measurement Forms</title>

928

929

930

<para>

931

<indexterm id="appb-idx-959816-0"><primary>measurement forms</primary></indexterm><link linkend="appb-82208">Table 2.6</link> and <link linkend="appb-34846">Table 2.7</link> are empty tables that you can use for copying and recording data. The bottleneck calculation in the previous example can be done in a spreadsheet, or manually with <link linkend="appb-51003">Table 2.8</link>. If Samba is as good as or better than FTP, and if there aren't any individual test runs that are much different from the average, you have a well-configured system. If loopback isn't much faster than anything else, you have a problem with your TCP/IP software. If both FTP and Samba are slow, you probably have a problem with your networking: a faulty Ethernet card will produce this, as will accidentally setting an Ethernet card to half-duplex when it's not connected to a half-duplex hub. Remember that CPU and disk speeds are commonly measured in bytes, network speeds in bits.</para>

932

933

934

<para>We've included columns for both bytes and bits in the tables. In the last column, we compare results to 10 Mb/s because that's the speed of a traditional Ethernet.</para>

935

936

937

938

<title>Ethernet Interface to Same Host: FTP </title>

939

940

941

942

943

944

945

946

947

<thead>

948

<row>

949

950

951

952

<entry colname="col2"><para>Size in Bytes</para></entry>

953

954

955

956

<entry colname="col4"><para>Bytes/sec</para></entry>

957

958

959

960

961

962

</row>

963

964

</thead>

965

966

<tbody>

967

<row>

968

969

970

971

972

973

974

975

976

977

978

979

980

981

</row>

982

983

<row>

984

985

986

987

988

989

990

991

992

993

994

995

996

997

</row>

998

999

<row>

1000

1001

1002

1003

1004

1005

1006

1007

1008

1009

1010

1011

1012

1013

</row>

1014

1015

<row>

1016

1017

1018

1019

1020

1021

1022

1023

1024

1025

1026

1027

1028

1029

</row>

1030

1031

<row>

1032

1033

1034

1035

1036

1037

1038

1039

1040

1041

1042

1043

1044

1045

</row>

1046

1047

<row>

1048

1049

<entry colname="col1"><para>Average:</para></entry>

1050

1051

1052

1053

1054

1055

1056

1057

1058

1059

1060

1061

</row>

1062

1063

<row>

1064

1065

<entry colname="col1"><para>Deviation:</para></entry>

1066

1067

1068

1069

1070

1071

1072

1073

1074

1075

1076

1077

</row>

1078

1079

</tbody>

1080

</tgroup>

1081

</table>

1082

1083

1084

1085

<title>Ethernet Interface to Same Host: FTP </title>

1086

1087

1088

1089

1090

1091

1092

1093

1094

<thead>

1095

<row>

1096

1097

1098

1099

<entry colname="col2"><para>Size in Bytes</para></entry>

1100

1101

1102

1103

<entry colname="col4"><para>Bytes/sec</para></entry>

1104

1105

1106

1107

1108

1109

</row>

1110

1111

</thead>

1112

1113

<tbody>

1114

<row>

1115

1116

1117

1118

1119

1120

1121

1122

1123

1124

1125

1126

1127

1128

</row>

1129

1130

<row>

1131

1132

1133

1134

1135

1136

1137

1138

1139

1140

1141

1142

1143

1144

</row>

1145

1146

<row>

1147

1148

1149

1150

1151

1152

1153

1154

1155

1156

1157

1158

1159

1160

</row>

1161

1162

<row>

1163

1164

1165

1166

1167

1168

1169

1170

1171

1172

1173

1174

1175

1176

</row>

1177

1178

<row>

1179

1180

1181

1182

1183

1184

1185

1186

1187

1188

1189

1190

1191

1192

</row>

1193

1194

<row>

1195

1196

<entry colname="col1"><para>Average:</para></entry>

1197

1198

1199

1200

1201

1202

1203

1204

1205

1206

1207

1208

</row>

1209

1210

<row>

1211

1212

<entry colname="col1"><para>Deviation:</para></entry>

1213

1214

1215

1216

1217

1218

1219

1220

1221

1222

1223

1224

</row>

1225

1226

</tbody>

1227

</tgroup>

1228

</table>

1229

1230

1231

1232

<title>Bottleneck Calculation Table</title>

1233

1234

1235

1236

1237

1238

1239

1240

1241

1242

<thead>

1243

<row>

1244

1245

1246

1247

<entry colname="col2"><para>Throughput</para></entry>

1248

1249

<entry colname="col3"><para>of Disks</para></entry>

1250

1251

<entry colname="col4"><para>Disk Throughput</para></entry>

1252

1253

<entry colname="col5"><para>Number of Networks</para></entry>

1254

1255

<entry colname="col6"><para>Network Throughput</para></entry>

1256

1257

<entry colname="col7"><para>Total Throughput</para></entry>

1258

1259

</row>

1260

1261

</thead>

1262

1263

<tbody>

1264

<row>

1265

1266

1267

1268

1269

1270

1271

1272

1273

1274

1275

1276

1277

1278

1279

1280

</row>

1281

1282

<row>

1283

1284

1285

1286

1287

1288

1289

1290

1291

1292

1293

1294

1295

1296

1297

1298

</row>

1299

1300

<row>

1301

1302

1303

1304

1305

1306

1307

1308

1309

1310

1311

1312

1313

1314

1315

1316

</row>

1317

1318

<row>

1319

1320

1321

1322

1323

1324

1325

1326

1327

1328

1329

1330

1331

1332

1333

1334

</row>

1335

1336

<row>

1337

1338

1339

1340

1341

1342

1343

1344

1345

1346

1347

1348

1349

1350

1351

1352

</row>

1353

1354

<row>

1355

1356

1357

1358

1359

1360

1361

1362

1363

1364

1365

1366

1367

1368

1369

1370

</row>

1371

1372

<row>

1373

1374

1375

1376

1377

1378

1379

1380

1381

1382

1383

1384

1385

1386

1387

1388

</row>

1389

1390

</tbody>

1391

</tgroup>

1392

</table>

1393

1394

1395

<para>In <link linkend="appb-51003">Table 2.8</link>:</para>

1396

1397

1398

1399

1400

<listitem><para>CPU throughput = (KB/second from <link linkend="ch06-89804">Figure 6.5</link>) × (number of CPUs)</para></listitem>

1401

1402

<listitem><para>Disk throughput = (KB/second from <link linkend="ch06-48609">Figure 6.4</link>) × (number of disks)</para></listitem>

1403

1404

<listitem><para>Network throughput = (KB/second from <link linkend="ch06-71393">Figure 6.6</link>) × (number of networks)</para></listitem>

1405

1406

<listitem><para>Total throughput = min (Disk, CPU, and Network throughput)</para></listitem>

1407

1408

</itemizedlist>

1409

1410

<para>A typical test, in this case for an FTP <literal>get</literal>, would be entered as in <link linkend="appb-37370">Table 2.9</link></para>

1411

1412

1413

1414

<title>Ethernet Interface to Same Host: FTP </title>

1415

1416

1417

1418

1419

1420

1421

1422

1423

<thead>

1424

<row>

1425

1426

1427

1428

<entry colname="col2"><para>Size in Bytes</para></entry>

1429

1430

1431

1432

<entry colname="col4"><para>Bytes/sec</para></entry>

1433

1434

1435

1436

1437

1438

</row>

1439

1440

</thead>

1441

1442

<tbody>

1443

<row>

1444

1445

1446

1447

1448

1449

1450

1451

1452

1453

1454

1455

1456

1457

</row>

1458

1459

<row>

1460

1461

1462

1463

1464

1465

1466

1467

1468

1469

1470

1471

1472

1473

</row>

1474

1475

<row>

1476

1477

1478

1479

1480

1481

1482

1483

1484

1485

1486

1487

1488

1489

</row>

1490

1491

<row>

1492

1493

1494

1495

1496

1497

1498

1499

1500

1501

1502

1503

1504

1505

</row>

1506

1507

<row>

1508

1509

1510

1511

1512

1513

1514

1515

1516

1517

1518

1519

1520

1521

</row>

1522

1523

<row>

1524

1525

<entry colname="col1"><para>Average:</para></entry>

1526

1527

1528

1529

1530

1531

1532

1533

1534

1535

1536

1537

</row>

1538

1539

<row>

1540

1541

<entry colname="col1"><para>Deviation:</para></entry>

1542

1543

1544

1545

1546

1547

1548

1549

1550

1551

1552

1553

</row>

1554

1555

</tbody>

1556

</tgroup>

1557

</table>

1558

1559

1560

<para>The Sparc example we used earlier would look like <link linkend="SAMBA-AP-B-TBL-10">Table 2.10</link>.</para>

1561

1562

1563

1564

<title>Sparc 20 Example, Redux</title>

1565

1566

1567

1568

1569

1570

1571

1572

1573

1574

<thead>

1575

<row>

1576

1577

1578

1579

<entry colname="col2"><para>CPU Throughput</para></entry>

1580

1581

<entry colname="col3"><para>Number of Disks</para></entry>

1582

1583

<entry colname="col4"><para>Disk Throughput</para></entry>

1584

1585

<entry colname="col5"><para>Number of Networks</para></entry>

1586

1587

<entry colname="col6"><para>Network Throughput</para></entry>

1588

1589

<entry colname="col7"><para>Total Throughput</para></entry>

1590

1591

</row>

1592

1593

</thead>

1594

1595

<tbody>

1596

<row>

1597

1598

1599

1600

1601

1602

1603

1604

1605

1606

1607

1608

1609

1610

1611

1612

</row>

1613

1614

<row>

1615

1616

1617

1618

1619

1620

1621

1622

1623

1624

1625

1626

1627

1628

1629

1630

</row>

1631

1632

<row>

1633

1634

1635

1636

1637

1638

1639

1640

1641

1642

1643

1644

1645

1646

1647

1648

</row>

1649

1650

1651

<row>

1652

1653

1654

1655

1656

1657

1658

1659

1660

1661

1662

1663

1664

1665

1666

1667

</row>

1668

1669

1670

<row>

1671

1672

1673

1674

1675

1676

1677

1678

1679

1680

1681

1682

1683

1684

1685

1686

</row>

1687

1688

1689

</tbody>

1690

</tgroup>

1691

</table>

1692

</sect2>

1693

</sect1>

1694

1695

1696

1697

1698

1699

1700

1701

1702

</appendix>