Subject | Re: [IBO] AV when switching to another app |
---|---|
Author | Nando Dessena |
Post date | 2005-05-12T11:34:23Z |
Helen,
H> As to multiple threaded sessions in Embedded being "perfectly safe", I'd
H> certainly be interested to hear actual load-testing evidence of that,
H> instead of hyberbolic claims and hearsay.
it's actually the other way around: since fbembed is *documented* to
support multiple threads, as confirmed by Dmitry and other developers,
saying that it just does so is not a "hyperbolic claim". Saying it
doesn't perhaps is. But it's not a bad idea to produce some stats;
I'll see what I can do when I get the time.
H> All I've found so far, under lab
H> conditions, is that the server and the clients will crash under fairly
H> minor thread-load, i.e <10 threads performing trivial operations on my
H> workhorse Intranet server, a 455 MHz PII Celeron with 384Mb RAM. The same
H> and greater loads on the same gear under Classic or Superserver, connecting
H> via localhost, don't suffer from this problem. What's more, there is no
H> difference in performance, at least on this fairly low-spec setup.
You last sentence makes me think there has to be something
spectacularly wrong in the test setup. AFAIR fbembed performance is
2-5x that of fbserver (via localhost TCP/IP) and 2-5x that of Oracle
(again via localhost TCP/IP, both via oci and Oracle NET), depending
on load and type of activity. But that was quite some time ago. I'm
curious to repeat the tests with Fb2.
H> I continue to regard v.1.5 Embedded as somewhat experimental
...and a successful experiment that lasted several years. :-)
H> and, at best, a staging-point on the road to the more robust XNET
H> implementation that Dmitry planned all along.
they are two completely unrelated features. We will never be able to
use XNET and fbembed together, not even using fbembed as a client for
a full fbserver. Unless Dmitry changes his strategy about the
connection string syntax, that is, which he's not going to.
What they have in common is that they both are faster than localhost
TCP/IP, as is Classic under Linux (no XNET).
H> I don't think it is overly responsible of people
H> to make the kind of claims that Nando does regarding the Fb 1.5
H> implementation, without citing some numbers.
I just wish people grow the ability to refer to docs and try things
out instead of blindly following what is said in the lists, which
often applies to a very special case and cannot be generalized much.
Then everyone can tell on his own who is just reporting results of
tried work and who makes claims. I don't feel irresponsible for
telling people that this or that does work because I am doing it (and
I'm far from being a genius, so others should be able to do it as
well). Do you sometimes have a doubt that you're saying something
doesn't work in general when perhaps it's just that it doesn't work
for you?
Ciao
--
Nando Dessena
http://www.flamerobin.org
H> As to multiple threaded sessions in Embedded being "perfectly safe", I'd
H> certainly be interested to hear actual load-testing evidence of that,
H> instead of hyberbolic claims and hearsay.
it's actually the other way around: since fbembed is *documented* to
support multiple threads, as confirmed by Dmitry and other developers,
saying that it just does so is not a "hyperbolic claim". Saying it
doesn't perhaps is. But it's not a bad idea to produce some stats;
I'll see what I can do when I get the time.
H> All I've found so far, under lab
H> conditions, is that the server and the clients will crash under fairly
H> minor thread-load, i.e <10 threads performing trivial operations on my
H> workhorse Intranet server, a 455 MHz PII Celeron with 384Mb RAM. The same
H> and greater loads on the same gear under Classic or Superserver, connecting
H> via localhost, don't suffer from this problem. What's more, there is no
H> difference in performance, at least on this fairly low-spec setup.
You last sentence makes me think there has to be something
spectacularly wrong in the test setup. AFAIR fbembed performance is
2-5x that of fbserver (via localhost TCP/IP) and 2-5x that of Oracle
(again via localhost TCP/IP, both via oci and Oracle NET), depending
on load and type of activity. But that was quite some time ago. I'm
curious to repeat the tests with Fb2.
H> I continue to regard v.1.5 Embedded as somewhat experimental
...and a successful experiment that lasted several years. :-)
H> and, at best, a staging-point on the road to the more robust XNET
H> implementation that Dmitry planned all along.
they are two completely unrelated features. We will never be able to
use XNET and fbembed together, not even using fbembed as a client for
a full fbserver. Unless Dmitry changes his strategy about the
connection string syntax, that is, which he's not going to.
What they have in common is that they both are faster than localhost
TCP/IP, as is Classic under Linux (no XNET).
H> I don't think it is overly responsible of people
H> to make the kind of claims that Nando does regarding the Fb 1.5
H> implementation, without citing some numbers.
I just wish people grow the ability to refer to docs and try things
out instead of blindly following what is said in the lists, which
often applies to a very special case and cannot be generalized much.
Then everyone can tell on his own who is just reporting results of
tried work and who makes claims. I don't feel irresponsible for
telling people that this or that does work because I am doing it (and
I'm far from being a genius, so others should be able to do it as
well). Do you sometimes have a doubt that you're saying something
doesn't work in general when perhaps it's just that it doesn't work
for you?
Ciao
--
Nando Dessena
http://www.flamerobin.org