L A AUSENCIA DE UNA JUSTICIA INDEPENDIENTE E IMPARCIAL

organization, faci lity, or resource into a set of labeled properties, each of which is stored as a string of characters. The major purpose of a name service is to enhance the logical organization of large net­ works by al lowing the names of network applica­ tions, systems, and other network-accessible objects to be independent of their physical location in the network.

VAX DNS is D igital's implementation of the Digital Network Architecture (DNA) naming service.' The service is impl emented as a c lient-server model in which the node running DNS acts as the server. Figure 4 shows. the relationship between two name servers·and a cl ient.

A client accesses DNS through a naming service module ca lled the clerk. The clerk communicates with as many name servers as necessary to find one that satisfies a request.

Each name stored in a name server refers to a single, unique network-accessible object . The trans­ action agent module on a name server performs DNS transactions requested by clerks. A typical DNS transaction requested by a clerk would be reading the attributes associated with an object. In this case, upon receiving the request from a clerk, the

CLIENT C L E R K TRANSACTION AGENT NAME SERVER 1 TRANSACTION AGENT NAME SERVER 2

Figure 4 Distributed Name Service transaction agent searches the name server clearing­ house for the attributes associated with the object, and sends the information tO the clerk.

The goals of the DNS performance evaluation were to characterize its behavior, identify the bottleneck, and find ways to improve DNS performance.

The performance metrics of DNS include

• Response time (latency) per DNS transaction requested by clerks

• Name server and clerk CPU time per DNS

transaction

• Name server capacity • Line utilization

We examined three aspects of the name server's performance:

• DNS performance in a local area network (LAN)

• DNS operations in a wide area network (WAN)

• Program counter (PC) histogram and Ethernet packet trace

DNS Performance in a Local Area Network The most commonly executed DNS transactions are read, add, and remove attributes of objects. Of these three, read transactions are used most frequently. In practice, an application program usually requests a specific attribute of an object (such as the DECnet node address of a particular DFS volume mounted on a DFS server) . During a read attribute operation, the clerk chooses the name server from the clerk cache, issues the request to that name server, and waits for the reply. On receiving a request, the name server searches the clearinghouse for the object and returns the attribute requested.

84

Clerk Operation The actual creation of the request packet and its transmission takes 31 ms; this is the overhead that will be experienced for all requests. However, when the clerk first receives a request from an application program, an additional 30 to 40 ms is involved in building the DNS context, initializing associated data structures, and choosing a name server from its cache.

Server Operation The clearinghouse is srored on disk and is accessed by means of Rl\15. RMS maintains its own cache, and the response time is 25 ms when the data is in the cache. Sometimes, however, the data may not be in the cache, and a disk access is neces­ sary. This step involves another 6 ms of CPU time and adds 42 ms (for an RA81 disk) or 62 ms (for an RD54 disk) to the response time.

The RMS cache hit and cache miss ratios are deter­ mined by the number of RMS buffers, the number of index buckets, and the number of data buckets. The number of data buckets is determined by the num­ ber of DNS objects in the clearinghouse, the size of each DNS object, and the bucket fill rate.' To reduce the number of disk 1/0 operations per DNS transac­

tion, we recommended that the number of Rl\15

buffers should be greater than the number of index

buckets. In that way Rl\15 can cache all the index

buckets in the RMS buffers. The cache hit ratio for data buckets is then

Cache-hit ratio

(Number of RMS buffers - number of index

Number of data buckets

The name server's average response time directly depends on the cache-hit ratio.

Communications Load The response times given above are for requests that use an existing logical link between the clerk and the server. However, log­ ical links may not necessari ly exist; and in the absence of a logical l ink, one must be created. This additional task affects the performance of DNS, both in terms of the response time and the CPU loads on the two systems. The establishment and disconnec­ tion of a logical l ink takes 88 ms and uses up 60 ms and 68 ms of CPU time , respectively, on the clerk and server. If a logical link had to be created for every request, the maximum throughput of DNS would drop from 33 to only 10 transactions per second.

The DECnet session overhead could be avoided by caching at least one logical link on the name server for every clerk. However, that operation depletes VMS system pool space, and the performance costs are prohibitive when the name server has to serve a large number of clerks. Another approach uses a datagram service for DNS operations within a local

Measurement and A nalysis Techniques for DEC net Products

area network. With this approach, however, issues such as authentication have to be resolved so that unauthorized access to the DNS clearinghouse can be prevented. The session layer (DECnet logical link) overhead is a major concern in most client-server implementations (such as file services, remote pro­ cedure calls, and name services) ; and for many client-server implementations that are LAN-based, a datagram-based service could provide better perfor­ mance than a connection-based service.

DNS Operations in a Wide Area Network If a clerk is trying to communicate with a name server that is not on the same LAN, the message that contains the DNS request is forwarded by routers to the name server. Both the router processing and data transmission add latency to the response time. Figure 5 shows a rypical configuration for this case .

A DECrouter 2000 introduces about 1 ms latency for every message it routes. The latency caused by the transmission on the low-speed line depends on the amount of data exchanged and the speed of the line . When the same read-attributes DNS transaction is performed over a WAN , we observed an extra latency of 50 ms at a line speed of 64 kilobits (Kb) per sec­ ond. The extra latency reduces to 16 ms as the line speed is increased to 256 Kb per second.

Program Counter Histogram and Ethernet Packet Trace

An Ethernet monitor was used to trace and time-stamp all the packets for a DNS transaction. VAX Software Performance MonitOr (SPM) generated a system-wide PC histogram on the name server. Figure 6 shows the Ethernet packet traces for a read-attributes trans­

action. The trace indicates that the response time of the name server is 24 .8 ms, excluding disk 1/0 and the establishment of DECnet session.

ETHERNET ETH E R N ET Figure 5 DECrouter 2000 SYNCH RONOUS COM M U N ICATION L I N E DECrouter 2000

DNS Operation over a Wide Area Network

Digital Tecl.mical]ourrud No. 9 june 1989

TIME DNS CLERK N A M E S E RVER

CONNECT IN ITIATE (92 BYTES) 0 00 MS

CONN ECT I N ITIATE ACK (64 BYTES) 5.30 MS DNS REQUEST ( 1 79 BYTES) 48.20 M S DNS R ESPONSE ( 1 84 BYTES) 73.03 MS (OTHER DNS TRANSACTIONS)

DISCON N ECT R EQUEST (64 BYTES) 3.87 M S

{

DISCONNECT CON FIRM (64 BYTES)

Figure 6 Message Trace for a DNS Operation

The server CPU times spent in each major module for read-attribute transactions are summarized in Figure 7. It was found that most of the name server time is spent in system modules (76 percent) . Only 24 percent of the CPU overhead is in the process space (PO and Pl space) .

DNS Server under Severe Load

On a rare occasion the name server may be besieged by requests, for example, after a power outage when several workstations reboot and try to execute a name service lookup simu ltaneously. Under such conditions the name server may not be able tO satisfy every request before the client times out. Each workstation then has the following options:

A. To try a few times and cease

B. To persistently retry until successful

C. To retry with backoff

This scenario was created with 460 client processes on 46 machines and a MicroVAX II name server. Using algorithm A , only a few clients managed to access the server due to intense congestion at the server. Algorithm B could cause severe thrashing if the network parameters are not set up carefully. The backoff a lgorithm efficiently eliminated the conges­ tion on the server by delaying the requests. Use of this algorithm thus resu lts in the best throughput and stil l completes the request from every client program .

25 (f) 20 w --' (l_ ::;;; < (f) lJ._ _{1 5} 0 f- z w 0 0: 1 0 w (l_ 5

RMS POOL PO/P1 SPACE

EXCEPTION WOR KING

EVENT FLAGS A N D ASTs

1/0 ROUTINE XODRIVER I N T E R R U PT OTH E R S S E T

MANAG E M ENT

R EAD ATTRIB UTES BY MODULE N A M E

Figure 7 Name Server CPU Usage for a Read-attribute Transaction