Update: Clarified and fixed typos.
Without more of an idea of what your script actually does, there's little to go on, save the ol' crystal ball method. Based on that, here's one idea out from left field.
AgentM alluded to this, but I thought I'd spell it out a bit more clearly. You might also take a look at the work your script is doing and, if possible, off-load as much as possible to other processes, especially if you're preparing the index before searching it.
For example, some search engines manually go through each file when invoked. This is not a great idea, unless you only have few documents. It bogs the system and wastes cycles repeating processes that don't need to be repeated. If your material highly dynamic (it changes often), that may be different (depending on the way you've implemented it), so I'll keep it simple and assume that it's mostly static...
In your case, you should be able to come up with an indexing script that creates a universal index to your HTML documents and your database tables. You can rebuild the index manually simply by running the script from the command-prompt or you can have it rebuilt automatically through a cron job (which is generally adviseable, for it means you don't have to remember to run the indexer after adding content).
Your CGI users then run a second script that searches the "meta-index" and prepares the hit list, if any, of matches using data stored in your meta-index.
In general, it's always adviseable to review your code for those elements that can be streamlined, however, that's not always possible. Even if you're working under a deadline, however, there's generally time to go back (after delivery) and tweak things later. In my experience, users generally want changes of some form and those give you the opportunity to clean things up a bit, if you're careful.
--f
|