Tests show that performance in Macintosh web servers could be improved with a change in storage system architecture.by Dave Winer, firstname.lastname@example.org
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.
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.
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!
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.