I did some testing about 2 years ago and noticed that Superserver under Windows suffered a latency problem caused by the way typical web applications continuously connect then disconnect to the database for each http request. Not only is each connection process expensive, but buffering is lost after each disconnect. I was told by Milan Babuskov that he did not experience this problem under Linux. At the time, I had been using a busy older single core CPU and the latency was noticeable.

I overcame this issue pretty easily. Instead of opening/closing db connections for each http request, I created a small pool of readonly / readcommitted transactions that are continuously reused for various read only queries required by my web applications throughout the day. These connections are only closed once every 24 hours by the web application. This is not to be used for operations that modify data since garbage collection occurs.

By reading the FB 2.5 Superclassic characteristics, I am guessing that libfbembeded (local connections) could be just as or even more efficient since it does not perform a connect operation. I'd be interested in knowing if cache is lost after closing.

Oh, before implementing my pool solution mentioned above, I used to open a dummy connection that did nothing. What that would do is ensure that cache was not lost but did not help with the connect latency.

I realize that upgrading to FB 2.5 would be a good thing since I currently have my cpu affinity set to one core under FB 2.1.3. I am sure that I am going to have to do my own testing, but would really like to know if FB 2.5 has functionality available that would be especially useful for people who use FB for their web applications especially in regard to connect latency and caching. Eliminating the use of database pools would simplify things for me.

Thank you.