Subject Re: [firebird-support] Re: FB 2.5 and web application performance
Author Alexandre Benson Smith
Em 8/12/2010 22:35, Jeff escreveu:
> --- In, Alexandre Benson Smith<iblist@...> wrote:
>> First of all... I am not a web developer, just did some pretty small
>> tests on this subject, so I have no solid experience on this...
>> That said, I could say that I noticed a big speed improvement when using
>> persistent connections in PHP.
> Yes Alexandre, I agree that the speed improvements are huge. In my tests, the number of querries per second went way up yet the resource consumption (CPU usage) went way down!
> Important question, did you do your testing with FB 2.5? Please note that my testing was done with FB 2.1x. I have not installed 2.5 yet.

IIRC it's on 1.5 ! :)

>> I don't know your programing language, but I think it should provide
>> some similar mechanism as persistent connections on PHP, If a connection
>> is kept open you will not lose the cache.
> I am using C++ along with the IBPP library. There are some Firebird flags that you can set (readonly& readcommitted) that I found make your readonly connections as fast as possible.

I think that if you keep a dummy connection (as you already said) even
with no transaction open, you will keep the cache in memory.

>> Super Classic and Classic server has a cache per connection, so even if
>> you already have a connection the other that comes will spawn a new
>> process in classic or a new thread in Super Classic, but both will have
>> a new cache and memory allocation on connection, so it could be worse
>> from the "latency" to connect POV.
> I am reading the FB 2.5 release notes and it says "Superserver threads for each database are allotted evenly to available processors". My current server is a Quad core and I have CPU affinity set to one CPU, I think that I am going to upgrade to FB 2.5 so that I can set the CPU affinity for all 4 cores. I am guessing that Superserver is still my best option, especially since I am on a Windows server and can benefit from the shared cache.

But if your queries is to a single database they will be linked to a
single core...

Classic server is not the best option for WEB developer because of the
very short connection time, and the cost of the process start-up and
cache initializing, but if you will use CS set the cache size to the
default 75 pages and let the filesystem do the real caching...