Two solutions to the problem are:
A simple way to tell is to run ``vmstat 5'' in one window, and after a couple of lines of output issue a query from another window. This will print a line of measurements about the virtual memory status of your machine every 5 seconds. In particular, look at the ``pi'' and ``po'' columns. If the numbers suddenly jump into the 500-1,000 range after you issue the query, you are paging a lot.
Note that paging problems are accentuated by running simultaneous memory-intensive or disk I/O-intensive programs on your machine. For example, we have performance problems on our demonstration machine (harvest.cs.colorado.edu) because we run over a dozen Brokers there. If several users issue queries to different Brokers at once, quite a bit of paging results, and performance degrades noticeably. Simultaneous queries to a single Broker should not cause a paging problem, because the Broker processes the queries sequentially.
It is best to run Brokers on an otherwise mostly unused machine with at least 64 MB of RAM (or more, if the above ``vmstat'' experiment indicates you are paging alot).
One other performance enhancer is to run an httpd-accelerator (see Section 6.3) on your Broker machine, to intercept queries headed for your Broker. While it will not cache the results of queries, it will reduce load on the machine because it provides a very efficient means of returning results in the case of concurrent queries. Without the accelerator the results are sent back by a BrokerQuery.pl UNIX process per query, and inefficiently time sliced by the UNIX kernel. With an accelerator the BrokerQuery.pl processes exit quickly, and let the accelerator send the results back to the concurrent users. The accelerator will also reduce load for (non-query) retrievals of data from your httpd server.