Editing NetWare (section)

== Performance ==
[[Image:Novell presentation folder back side with offices list 1994.jpg|thumb|right|upright=0.85|The success of NetWare as a product is what allowed Novell to have sales-related offices around the world, as the back side of this mid-1990s Novell presentation folder shows.]]
NetWare dominated the network operating system (NOS) market from the mid-1980s through the mid- to late-1990s due to its extremely high performance relative to other NOS technologies. Most benchmarks during this period demonstrated a 5:1 to 10:1 performance advantage over products from Microsoft, Banyan, and others. One noteworthy benchmark pitted NetWare 3.''x'' running [[Network File System (protocol)|NFS]] services over TCP/IP (not NetWare's native IPX protocol) against a dedicated Auspex NFS server and an SCO Unix server running NFS service. NetWare NFS outperformed both 'native' NFS systems and claimed a 2:1 performance advantage over SCO Unix NFS on the same hardware.{{Citation needed|date=July 2009}}

The reasons for NetWare's performance advantage are given below.

=== File service instead of disk service ===
When first developed, nearly all LAN storage was based on the disk server model. This meant that if a client computer wanted to read a particular block from a particular file it would have to issue the following requests across the relatively slow LAN:

# Read first block of directory
# Continue reading subsequent directory blocks until the directory block containing the information on the desired file was found, could be many directory blocks
# Read through multiple file entry blocks until the block containing the location of the desired file block was found, could be many directory blocks
# Read the desired data block
NetWare, since it was based on a file service model, interacted with the client at the file API level:
# Send file open request (if this hadn't already been done)
# Send a request for the desired data from the file
All of the work of searching the directory to figure out where the desired data was physically located on the disk was performed at high speed locally on the server.
By the mid-1980s, most NOS products had shifted from the disk service to the file service model. Today, the disk service model is making a comeback, see [[Storage area network|SAN]].

=== Aggressive caching ===
From the start, the NetWare design focused on servers with copious amounts of RAM. The entire file allocation table (FAT) was read into RAM when a volume was mounted, thereby requiring a minimum amount of RAM proportional to online disk space; adding a disk to a server would often require a RAM upgrade as well. Unlike most competing [[network operating system]]s prior to Windows NT, NetWare automatically used all otherwise unused RAM for caching active files, employing delayed write-backs to facilitate re-ordering of disk requests ([[Elevator algorithm|elevator seeks]]). An unexpected shutdown could therefore corrupt data, making an [[uninterruptible power supply]] practically a mandatory part of a server installation.

The default dirty cache delay time was fixed at 2.2 seconds in NetWare&nbsp;286 versions 2.''x''. Starting with NetWare&nbsp;386&nbsp;3.''x'', the dirty disk cache delay time and dirty directory cache delay time settings controlled the amount of time the server would cache changed ("dirty") data before saving (flushing) the data to a hard drive. The default setting of 3.3&nbsp;seconds could be decreased to 0.5&nbsp;seconds but not reduced to zero, while the maximum delay was 10&nbsp;seconds. The option to increase the cache delay to 10&nbsp;seconds provided a significant performance boost. Windows&nbsp;2000 and 2003 server do not allow adjustment to the cache delay time. Instead, they use an algorithm that adjusts cache delay.

=== Efficiency of NetWare Core Protocol (NCP) ===
Most network protocols in use at the time NetWare was developed didn't trust the network to deliver messages. A typical client file read would work something like this:

# Client sends read request to server
# Server acknowledges request
# Client acknowledges acknowledgement
# Server sends requested data to client
# Client acknowledges data
# Server acknowledges acknowledgement

In contrast, NCP was based on the idea that networks worked perfectly most of the time, so the reply to a request served as the acknowledgement. Here is an example of a client read request using this model:

# Client sends read request to server
# Server sends requested data to client

All requests contained a sequence number, so if the client didn't receive a response within an appropriate amount of time it would re-send the request with the same sequence number. If the server had already processed the request it would resend the cached response, if it had not yet had time to process the request it would only send a "positive acknowledgement". The bottom line to this 'trust the network' approach was a 2/3 reduction in network transactions and the associated latency.

=== Non-preemptive OS designed for network services ===
One of the raging debates of the 1990s was whether it was more appropriate for network file service to be performed by a software layer running on top of a general purpose operating system, or by a special purpose operating system. NetWare was a special purpose operating system, not a timesharing OS. It was written from the ground up as a platform for client-server processing services. Initially it focused on file and print services, but later demonstrated its flexibility by running database, email, web and other services as well. It also performed efficiently as a router, supporting IPX, TCP/IP, and Appletalk, though it never offered the flexibility of a 'hardware' router.

In 4.''x'' and earlier versions, NetWare did not support [[preemption (computing)|preemption]], [[virtual memory]],<ref name="IW_3"/> [[graphical user interface]]s, etc. Processes and services running under the NetWare OS were expected to be cooperative, that is to process a request and return control to the OS in a timely fashion. On the down side, this trust of application processes to manage themselves could lead to a misbehaving application bringing down the server.