Subject | Re: [firebird-support] FB 2.5 and web application performance |
---|---|
Author | Alexandre Benson Smith |
Post date | 2010-12-08T23:15:39Z |
Em 8/12/2010 18:29, Jeff escreveu:
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.
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.
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.
see you !
> 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.First of all... I am not a web developer, just did some pretty small
>
> 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.
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.
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.
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.
see you !