Subject | Re: [firebird-support] Re: FB 2.5 and web application performance |
---|---|
Author | Alexandre Benson Smith |
Post date | 2010-12-09T01:22Z |
Em 8/12/2010 22:35, Jeff escreveu:
with no transaction open, you will keep the cache in memory.
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...
>IIRC it's on 1.5 ! :)
> --- In firebird-support@yahoogroups.com, 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.
>
>> I don't know your programing language, but I think it should provideI think that if you keep a dummy connection (as you already said) even
>> 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.
>
>
with no transaction open, you will keep the cache in memory.
>> Super Classic and Classic server has a cache per connection, so even ifBut if your queries is to a single database they will be linked to a
>> 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.
>
>
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...