Added April 2022
Here are some tips to help you maximize A-Shell performance in a Windows environment:
| • | If your network is large, containing many PC's and applications unrelated to A-Shell, try to reduce traffic hitting the A-Shell server by putting it on it's own subnet, if possible. |
| • | File sharing is quite efficient for read-only and text files, but not so much for record-oriented files, since each record-level access may require querying many other PCs to see if they have an updated version of the record. To minimize that problem, if practical, open files only when you are actively using them, as opposed to opening all the files at the start of the program and closing them all at the end. |
| • | Applications that implement file locking using XLOCK or FLOCK, rather than READL (i.e. LOKSER protocol), may run faster using the 'C' version of A-Shell. |
| • | Using a domain (with all users signed into it) results in more efficient and secure LAN performance than informal P2P networks. |
| • | For files that don't need to be shared—print files, sort files, etc.—it's much faster to put them on each client PC then on the shared server. Typically this is done by defining a DEVICE, e.g. WRK0:, that points to a directory on the C: drive, i.e. each client PC's C: drive, rather than on the server, and then use that device for the appropriate class of files. |
| • | If the LAN access becomes too slow, or especially if some clients connect over a WAN, telnet (ATE/ATSD) connections will be much faster than P2P connections. The standard P2P model offers the best CPU and screen I/O performance, but the worst disk I/O, which is usually the bottleneck. ATE/ATSD connections offer the reverse set of trade-offs. |
