Let me tell you the background details of the application

The application is developed in Deplphi 5 and we are connecting to the database through IBObjects (version 3.3). The FB Server is running on a Windows NT4.0 Server with all service packs installed. The protocol of the connection is TCP/IP and the application is running on Terminal Server on a metaframe architecture optimized with citrix.

The amount of clients connected is between 20-30 at the same time working from 9:00 am to 8:00 pm and they need to restart the IB server like 3 times a day because it turns to be very slow. After restarting it, everybody starts working ok again on the same operations they were doing.

I've been checking the OIT-OAT Discussion in this group, so the question about the way in which the server took the connections was related to see if there's a particular problem in working with applications running on terminal server sessions, because this low performance is not present in other customers that have the same application but in a normal client/server framework and up to 10-15 clients at the same time.

We know we have a transaction issue in here, but we'd like to know if there could be a problem with terminal server that could be making this problem bigger.

regards,

Luciano

----- Original Message -----
From: Helen Borrie
To: ib-support@yahoogroups.com
Sent: Tuesday, January 29, 2002 8:52 PM
Subject: Re: [ib-support] Working with IB from an application running several times in Terminal Server


At 01:22 PM 29-01-02 -0300, you wrote:
>Let me explain a very particular case:
>
>We have our application running on a terminal server and about 20-30 users
>connect to it to use the same EXE file.
>
>The IBServer (in another machine) receives connections only from the
>terminal server, but it turns to work very slow in a couple of hours after
>most of the users connect to the system. (the same application working
>without terminal server on other customers doesn't show that poor
>performance).
>
>We've been thinking about the way in which IB and FB (we've used both)
>identifies a session in memmory, because the server starts gaining memmory
>and never releases it until the last user closes the application.
>
>So... could it be possible that IB manages the session information with all
>the transactions information as it is only one user connected and working
>all day long??? Does anybody know how IB keep the info per session???

IB doesn't manage sessions, it manages connections. You can find out the user names associated with connections but nothing else.

Transactions are started and committed by the client application. The server doesn't know anything about ownership of transactions.

>does
>it identify it by host name and application name ?? (in that case it would
>be in trouble).

No.


>Any comments will be useful, thanks

Seeing the symptoms you describe, I would look first at the possiblility that you have many long-running transactions that never get committed, thus inhibiting garbage collection in the database.

You can query the database statistics using the command-line utility gstat. Look for big differences between the Oldest Interesting/Oldest active transactions and the Next Transaction. Documentation for gstat is in the OpGuide.pdf manual.

Another angle is the possibility that you have the database running on an XP server. Do you? in this case, you do have a known problem regarding this OS.

The database shouldn't slow down or behave as you describe, so the problem is in your application or your environment. If you post more information about how the client application works and the platform, development tools, etc., more people may be able to offer more advice.

regards,
Helen


All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org
_______________________________________________________


Yahoo! Groups Sponsor


------------------------------------------------------------------------



To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



[Non-text portions of this message have been removed]