Let me rephrase what I think you are saying:

1. You have an existing application that consists of a client piece and
a midware server piece.
2. The client piece talks to your midware server piece.
3. You want to use Firebird embedded as the backing store for the
midware server part of your application

U have measured less than 5% improvement in throughput on small
transactions by using embedded over superserver.

Embedded is superserver in a DLL, so it is not surprising that the
performance of the two models are similar. The sockets overhead is very
small, so there is not much difference between them in practical usage.

A transaction is not "per client", it is the smallest unit of work per
connection. When it does I/O, your midware will need to respond to
requests from the client by starting a transaction, performing the
queries (select, insert, update, delete), and committing the
transaction.

It will not require less resources than the superserver because, as
already stated, the embedded engine is the superserver in a DLL. You
will simply add the overheads of your process to the superserver
overheads. Lacking more concrete information, it is my judgement that
you are more likely to double the overheads and defeat the RDBMS buffer
pooling cache (make it use more resources and slow things down) than
improve things with this architecture.

With that said, there are other reasons for considering wrapping the
RDBMS in a midware server. For example, if you want to embed complex
business logic on the server that does not properly belong in the RDBMS
layer, or if you are running a web services type application, or you are
running a field-level security system, or you need to scale beyond what
the RDBMS native connection pool will allow (say you need to connect
50,000 concurrent users). However, your questions are concerned with
the resource usage of one of the most resource efficient pieces of the
equation, so it is not likely that any of these other considerations
apply.

On Mon, 2006-03-13 at 10:49 +0000, avner_liat wrote:
> Hi,
> I'm new to this database and trying to decide what will be the best
> usage of the database in my case.
> I have an exisiting client server architecture and I want to use the
> firebird in the server side only.
> I support in my server multiple clients which can update the database
> concurrently by sending application specific commands.
> This is why I want to open concurrent multiple database "transactions"
> and do for each client its work in a dedicated transaction.
> Since the only process which access the database is the server I was
> thinking of using the embedded option.
> My questions are:
> 1. Is using the embedded server option will give better performance
> (because no networking and round loops are involved)?
> 2. Will hosting the database in my process will require less resources
> than running the SuperServer?
> Are there any other issues I should consider?
> Thanks in advance,
> Avner
>
>
>
>
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>
>
> SPONSORED LINKS
> Technical support
> Computer technical
> support
> Compaq computer
> technical support
> Compaq technical
> support
> Hewlett packard
> technical support
> Microsoft technical
> support
>
>
> ______________________________________________________________________
> YAHOO! GROUPS LINKS
>
> 1. Visit your group "firebird-support" on the web.
>
> 2. To unsubscribe from this group, send an email to:
> firebird-support-unsubscribe@yahoogroups.com
>
> 3. Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service.
>
>
> ______________________________________________________________________
>