TECHNOTE 1059: Open Transport Application Performance, P6

On Improving Open Transport Network Application Performance

Interacting with the File Manager
Since the design of many network server applications require interaction with the File Manager, it's important to understand how to get the most out of the File Manager.

Don't Blame the File Manager for Poor Application Design
Improper use of the File Manager will adversely affect network server performance. If the architecture of your server requires even moderate amounts of file access, you should review Technote FL16 - File Manager Performance and Caching. This Note details tactics you can apply in order to get the best performance from the File Manager. Pay close attention to the following issues:
Optimizing the size of your I/O requests
Aligning your I/O requests

Using the File System's Cache to your advantage
Using asynchronous read or writes that overlap with other non-File Manager operations.

Caching Open Files, Not Just Data
An excellent way to improve performance is to avoid opening frequently used files every time they are accessed. You can accomplish this by maintaining the most recent or commonly used files in an open state, tracked by a list or cache, and only closing files after the list is full or an extended period of inactivity has elapsed.
For example, a webserver would benefit by keeping the site's main index.html file open because it is hit everytime a new user accesses the server.
There are some tradeoffs, however, to keeping a large number of files open:
HFS has an architectual limit of 348 open files per disk.
Too many open files may cause other applications to fail.
Open files may be tricky to share because of synchronization issues.

Caching Pathnames and FSS structure
Keep table of commonly used pathnames and thier coresponding File System Specification (FSS).
Quick compare of strings and open file using FSpOpenDF.
Volume ID wont survive dismount - but you can use Alias Mgr to keep an Alias to the volume and update your FSS cache on the next remount.
Keeping default directory is slower than passing in pathname beacuse of HFS's search algorithm

The File System is NOT a Database
Don't use a seperate file for each mail / news entry, or web cache. Employ some sort of database code to minimize creating of too many files...
An Example of Processing a Packet
So far, I've provided you with a collection of hints and guidelines. Now I want to show you how you might use notifiers effectively to handle packet reception and processing.
We're going to set up a example scenario of processing a packet in the context of an HTTP server. Let's make the following assumptions:
You have open and bound your session endpoint.
AckSends are enabled.

You have also created a deferred task using OTCreateDeferredTask to handle network replies to be used later from File Manager ioCompletion proc.
Here's the scenario:
A HTTP GET-method packet is sent to your port.
Your notifier receives a T_DATA event.
Call into OTRcv to extract data from the stream head, copying the data into a buffer you allocated with the OTAllocMem function.
Return to step 2 until the OTRcv returns a kOTNoDataErr
After parsing your data, you determined that it was a GET-request and a file access is required to respond.
Your parser calls OTFreeMem to return the request buffer.
Your code calls PBHOpenDFAsync with a pointer to a ioCompletion routine chains to the rest of the required I/O.
The notifier returns and the main thread continues.
Some time later, the main task is interrupted to process the PBHOpenDFAsync completion routine, which allocates a block of memory via OTAllocMem for the HTTP response. PBReadAsync is used to access the data.
The PBReadAsync completes and its ioCompletion routine runs.
Since File Manager ioCompletion routines can sometimes be run at primary interrupt time, it is not safe to directly call Open Transport here. Instead, you should queue your network reply data to your sending task and schedule it to be run with OTScheduleInterruptTask. Then return from the ioCompletion routine.
The previously scheduled Deferred Task is run, which can now safely call OTSnd to transmit the HTTP GET-response.
Close the file with PBCloseAsync.
The OTSnd completes and the notifier is called with a T_MEMORYRELEASED event.
The Notifier calls OTFreeMem.

[Prev] p. 1 2 3 4 5 6 7 8 [Next]