Part of the web server. San Francisco CA USA. 6/15/96.

Mac Web Server Performance Tests

Tests show that performance in Macintosh web servers could be improved with a change in storage system architecture.

by Dave Winer,

It's commonly believed in the Macintosh sysop community that the Macintosh file system contains one of the major limits of performance for Macs used to run web servers.

Sysops running Frontier report that serving text from the Frontier object database is appreciably faster than serving from the file system even though it includes the overhead of a roundtrip Apple Event between the server software and Frontier.

It can be hard to measure the performance issues in this area because you need to factor in the speed of the communication path, and the performance and multi-threading capabilities of the web server software.

I wanted to know, isolated from the issues of communication and server performance, how the performance of the Macintosh file system compared to the performance of the Frontier object database.

I constructed a test which measures the performance difference.

The test case

For the test I used a structured website, one with several levels of nested folders. I believe this structure favored the Mac file system, because its performance declines as the number of files in a folder increases.

The test is run by a script at suites.serverSimulator.runTest. You can download the test suite from the Pointers section at the bottom of this page.

For each test, we generated a random list of 100 URLs. For the Mac file system part of the test, we replace '/'s with ':'s, and then read the entire contents of the file. For the object db tests, we replace '/'s with '.'s and then read the entire contents of the object db cell.

Here's the main test loop for the Mac file system:

	local (origticks = clock.ticks ())
	for i = 1 to sizeof (testurls) 
		url = testurls [i]
		f = folder + string.replaceAll (url, "/", ":")
		toys.readWholeFile (f)
	op.insert ("File system: " + (clock.ticks () - origticks) + " ticks", right)

Here's the main test loop for the Frontier object database:

	local (origticks = clock.ticks ())
	for i = 1 to sizeof (testurls) 
		url = testurls [i]
		local (adr = adrsite, name)
			if not (url contains '/') 
				adr = @adr^.[url]
			name = string.nthfield (url, '/', 1)
			url = string.delete (url, 1, sizeof (name) + 1)
			adr = @adr^.[name]
		s = string (adr^)
	op.insert ("Object DB: " + (clock.ticks () - origticks) + " ticks", down)

As you can see, more script-implemented code is running for the Frontier test case, so the performance of the object database actually is better than the benchmarks show.

I ran the tests on a PowerMac 9500, running System 7.5.3. Frontier 4.0, the Finder and Microsoft Internet Explorer 2.0. File sharing is turned on. Several agent scripts were running. I assume the performance degradation affected both tests equally.

Test results

Here's a table listing the results.

File systemObject dbfs/odb
417 ticks220 ticks1.89545455
472 ticks144 ticks3.27777778
459 ticks103 ticks4.45631068
389 ticks75 ticks5.18666667
358 ticks68 ticks5.26470588
293 ticks69 ticks4.24637681
363 ticks66 ticks5.5
334 ticks66 ticks5.06060606
509 ticks72 ticks7.06944444
485 ticks69 ticks7.02898551
403 ticks65 ticks6.2

The first column reports the number of sixtieths of a second used in the file system test. The second column is the same set of URLs retrieved thru the object database. The third column is the ratio of the time used by the file system divided by the time used by the object database.


The object db is up to seven times faster at retrieving raw data in a form required by web servers.

I believe the increased performance is due to Frontier having no legacy code supporting multiple file system formats, and the fact that Frontier is a native application, not emulated 68000 code.

The performance ratio increased in Frontier's favor as more and more of the subtables had been loaded into memory. This result will be less favorable to Frontier when version 4.0.2 is released, where less data is cached in memory, but it should still stay in the 4-to-5 times range.

It's no small advantage that the Frontier object database can also store scripts, outlines, and connects with the sophisticated web content design tools in Frontier 4.0.

We shared the results of an early version of the test suite with the Frontier-talk list in late May and have been working on deploying this technology with Chuck Shotton, the lead developer of WebStar. We should have the resulting software available in the form of a WebStar plug-in real soon. Still digging!


This page was last built with Frontier on a Macintosh on Sat, Jun 15, 1996 at 5:14:20 PM. Thanks for checking it out! Dave