Part of the scripting.com 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, dwiner@well.com

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)
		loop 
			if not (url contains '/') 
				adr = @adr^.[url]
				break
			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 system	Object db	fs/odb
417 ticks	220 ticks	1.89545455
472 ticks	144 ticks	3.27777778
459 ticks	103 ticks	4.45631068
389 ticks	75 ticks	5.18666667
358 ticks	68 ticks	5.26470588
293 ticks	69 ticks	4.24637681
363 ticks	66 ticks	5.5
334 ticks	66 ticks	5.06060606
509 ticks	72 ticks	7.06944444
485 ticks	69 ticks	7.02898551
403 ticks	65 ticks	6.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.

Conclusions

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!

Pointers

• Frontier users can download the serverSimulator suite and run their own tests. Install the suite in Frontier 4.0, change the value of serverSimulator.folder to point to a website you want to test, open serverSimulator.runTest and click on the Run button.

• I used http://www.scripting.com/root/root.html in my tests.

• The Frontier is Native page shows the result of an earlier benchmark comparing the native speed of Frontier against the speed of the 68K emulated AppleScript interpreter.

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