Why is Netscape very slow for documents with many links ?

• Link history mechanism is active
• The history database becomes large (HISTORY.DB)
• A document with many links is displayed

• A HISTORY.DB with just 656 blocks
• A document with about 620 links
• Displaying this document causes about 2400 $READ RMS request ! This can easily be checked by

     $ set file HISTORY.DB;1 /stat
     $ moni rms /FILENAME=HISTORY.DB;1
  

  Note, that the 2400 $READ's are done each time the document is rendered, not just when its loaded first.
• The I/O request size is obviously determined by the RMS default multiblock count (See SET RMS/BLOCK).
• On systems which an RMS default block size of 35 or larger one gets abysmal performance. On a Alpha with LAVC access over Ethernet it takes 2 minutes to display this page. During this time the data rate is about 650 kb/sec, the total amount of data over the net is about 80 Mbyte !

It seems, that DEC is somehow aware of this. Their FAQ states "If its (HISTORY.DB) more than a couple of hundred blocks, it's probably the cause of slowing load time" and recomment to set the expiration time to 9 days.

Bottom line from this:

• The history mechanism is obviously implemented under the assumption of a perfectly working disk cache. Netscape seems to do very little useful caching of it's own.
• It's therefore important that the VMS virtual I/O cache works for this case. That implies that the default RMS multiblock count must be less than 35 (the cache cutoff).
• It is thus advisable to execute a

     $ set rms /blo=32
  

  before calling Netscape. Note, that the process specific RMS default parameter are not passed to a spawed subprocess !

Back to Netscape FAQ List