| Subject | Re: [ib-support] IB Server is SLOW!!!!!!!!!!!! |
|---|---|
| Author | Jason Chapman (JAC2) |
| Post date | 2002-03-08T14:51:55Z |
plug
4 years ago i was asked to look at a site that had 40 users and the DB
crashing every couple of hours, finding a client took 5 minutes (and that
was typing in the customer reference). They had written the application
internally.
I went to do 3 days consultancy to get to the bottom of the problem. I
wrote some probe code that looked at DB interaction and found that they were
using TTables and opening lots of them at the start of the application. 2 x
1.5 million row tables were being opened for a starter. IB was killing
itself with sort files etc etc and just grinding to a halt.
I spent 2 weeks re-writing a small part of the application still using the
BDE, but to be more efficient, it then took <1 second to find a client.
After a complete system re-write the performance was excellent, nunber of
users was huge and everyone was happy.
I must have done this dozens on times for IB, SQL server etc, selecting the
bigest bang for buck improvement and showing whata bit of well crafted code
will do.
Funnily enough I have recently left that company and intend going back to
trouble shooting / QAing peoples systems etc.
IB/FB is probably doing a pretty good job of coping with a poorly written
application, that said, there are times when the server makes some strange
choices on query optimisation that kill perf.
Unfortunately, it isn't normally as easy as replace TTables for Tqueries and
everything will be OK, it normally takes a little more digging.
You say 600 forms, I would start by putting in some kind of Inherited audit
to give usage stats to show where to start looking. Packet sniffing to see
what SQL is issued at the server and by whome. Oh and of course, employ me
to QA the application / DB structures.
/plug
JAC.
"GreatDayDan" <greatdaydan@...> wrote in message
news:20020307145547.96609.qmail@......
4 years ago i was asked to look at a site that had 40 users and the DB
crashing every couple of hours, finding a client took 5 minutes (and that
was typing in the customer reference). They had written the application
internally.
I went to do 3 days consultancy to get to the bottom of the problem. I
wrote some probe code that looked at DB interaction and found that they were
using TTables and opening lots of them at the start of the application. 2 x
1.5 million row tables were being opened for a starter. IB was killing
itself with sort files etc etc and just grinding to a halt.
I spent 2 weeks re-writing a small part of the application still using the
BDE, but to be more efficient, it then took <1 second to find a client.
After a complete system re-write the performance was excellent, nunber of
users was huge and everyone was happy.
I must have done this dozens on times for IB, SQL server etc, selecting the
bigest bang for buck improvement and showing whata bit of well crafted code
will do.
Funnily enough I have recently left that company and intend going back to
trouble shooting / QAing peoples systems etc.
IB/FB is probably doing a pretty good job of coping with a poorly written
application, that said, there are times when the server makes some strange
choices on query optimisation that kill perf.
Unfortunately, it isn't normally as easy as replace TTables for Tqueries and
everything will be OK, it normally takes a little more digging.
You say 600 forms, I would start by putting in some kind of Inherited audit
to give usage stats to show where to start looking. Packet sniffing to see
what SQL is issued at the server and by whome. Oh and of course, employ me
to QA the application / DB structures.
/plug
JAC.
"GreatDayDan" <greatdaydan@...> wrote in message
news:20020307145547.96609.qmail@......
> Good Morning!
>
> Thanks for the info. I have kicked all users out
> and set the bufferes to 10,000. I did not set the
> affinity with IBConfig.
>
> I also set back to 1 for the processor priority.
>
> I'll see what kind of difference this makes.
>
> I have been working on indexes.