> II 200 MHz server; 10 mbit network. I initially thought to bring back small numbers
>of keys. Another engineer convinced me to set the buffering to the max, and get the
>lot. So I did. It took less than 5 seconds to populate the whole thing (5000 x 40
>character names).
Can't do that. Can't predict whether the client software with the pick list will run
on a thin client (with a dozen other users hogging the poor app server) or a "fat"
client. Have to save ressources, can't use the hardware club to beat my problems to
death. Apart fro that,this is not about one list, it's a whole lot of them in our
system. Would need gigabytes of RAM just to cache them "in toto".
> I suggest you consider a faster underlying database. It is almost certainly the slow
>part of your system. But I agree this is a problem in health, and I expect to have to
>think a bit harder to deal properly with it in the future, especially the soundalike
>problem.
It is not the database. To find out more about the bottleneck, I tried a plain text
file with 65.000 lines of text, the "virtual server" just serving from these lines,
the server fully cached. Made some difference, but not enough.
Apart from that, a "dumb" repository for persistent objects will not hold for our
purposes. We need a secure data repository with multiple generation transactions,
_transparent_ and reproducible referential integrity, and it must be fully "queriable"
in some sort of an easy query language (and why not SQL). Fulfilling all these
constraints, Interbase is probably as fast as it can get next to Oracle (which we
can't use as not open source).
Horst
