|
Home > Archive > Programming with dBASE > November 2006 > application becomes very slow
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
application becomes very slow
|
|
| Moses Hanna 2006-11-02, 5:12 am |
| Hi
I have an application
object files are on server
data is in a separate directory also on server
when the application is in use by one workstation, everything is alright
but as soon as a second user uses the application, it becomes very very slow
the table in the database are not so large ( the largest has around 11000
rows
May some gentleman tell me why it becomes very slow and how to overcome the
problem?
Thanks
Moses
| |
| Lysander 2006-11-02, 5:12 am |
| Moses Hanna schrieb:
> May some gentleman tell me why it becomes very slow and how to overcome the
> problem?
11000 is already big enough to cause problems, serious problems
even, if the table contains memofield(s) and is not properly indexed.
I have a table with about 25000 records now, properly indexed and
without any memofields in it. Unfortunately, this is still DBF
format - with FB format there wouldn't be a problem at all...
The corresponding form opens within 3 or 4 seconds as long as only
one user is using it, but takes about 1 minute as soon as the second
user needs it at the same time.
Did you already split your tables into logical pieces, where each
table represents a piece of information always queried in a bunch?
For example: customer informations. Usually, adress and billing-info
are never needed at the same instant, so you would put them into 2
different tables.
| |
| Moses Hanna 2006-11-02, 7:12 pm |
| if 11000 rows are considerable large file , what about the dbase table rows
are limited to 1 million rows,
what time it will take to open a table with one million rows, three days?. I
think there is something wrong in my application, I think it is not because
one table or more contains 11000 rows that make it like a turtle.
Any comments on that, please?
Moses
"Lysander" <nobody@nowhere.com> wrote in message
news:XLpCqem$GHA.1140@news-server...
> Moses Hanna schrieb:
>
>
> 11000 is already big enough to cause problems, serious problems even, if
> the table contains memofield(s) and is not properly indexed.
>
> I have a table with about 25000 records now, properly indexed and without
> any memofields in it. Unfortunately, this is still DBF format - with FB
> format there wouldn't be a problem at all...
> The corresponding form opens within 3 or 4 seconds as long as only one
> user is using it, but takes about 1 minute as soon as the second user
> needs it at the same time.
>
> Did you already split your tables into logical pieces, where each table
> represents a piece of information always queried in a bunch?
>
> For example: customer informations. Usually, adress and billing-info are
> never needed at the same instant, so you would put them into 2 different
> tables.
>
>
| |
| Jan Hoelterling 2006-11-02, 7:12 pm |
|
"Lysander" <nobody@nowhere.com> wrote in message
news:XLpCqem$GHA.1140@news-server...
> Moses Hanna schrieb:
> I have a table with about 25000 records now, properly indexed and without
> any memofields in it. Unfortunately, this is still DBF format - with FB
> format there wouldn't be a problem at all...
> The corresponding form opens within 3 or 4 seconds as long as only one
> user is using it, but takes about 1 minute as soon as the second user
> needs it at the same time.
Are you sure about this? Opening the form should not take this long, unless
you're doing extensive table operations at the same time.
Jan
| |
| Lysander 2006-11-02, 7:12 pm |
| Jan Hoelterling schrieb:
> "Lysander" <nobody@nowhere.com> wrote in message
> news:XLpCqem$GHA.1140@news-server...
>
> Are you sure about this? Opening the form should not take this long, unless
> you're doing extensive table operations at the same time.
In this form, I _am_ doing extensive table operations with the
tables needed in the form.
And in addition, I was not expressing myself correctly: the form
opens with the same speed in both cases. But it is not usable, just
because it's visible (good old MS-trick *g*).
After opening it creates a treeview based on those "extensive table
operations".
And THAT takes several seconds only with 1 user, and considerably
much longer as soon as a second user opens the same form.
| |
| Lysander 2006-11-02, 7:12 pm |
| Moses Hanna schrieb:
> if 11000 rows are considerable large file , what about the dbase table rows
> are limited to 1 million rows,
> what time it will take to open a table with one million rows, three days?. I
If you open that same table not properly indexed with 2 or more
users at the same time, then, yes, it could take an hour or such
depending on your network and hardware, ESPECIALLY if the table
contains memos.
I don't think, by the way, that there is a limit at 1M. Should be
higher, though I never tried. This is a technical limit only,
anyway. If it _is_ 1M, then it does not mean that it runs smooth and
lightning fast until 1M, and then just bombs out at 1M+1.
Of course it will be slower and slower with increasing size.
Maybe in your case indeed also some things are misconcepted with the
application, but if you could find out what it is and change it,
that would only decrease the delay, it would not make it vanish.
How's your table structure, and what happens when the form is opened?
| |
| Jan Hoelterling 2006-11-02, 7:12 pm |
|
"Lysander" <nobody@nowhere.com> wrote in message
news:rWygkxn$GHA.2124@news-server...
> Jan Hoelterling schrieb:
> After opening it creates a treeview based on those "extensive table
> operations".
> And THAT takes several seconds only with 1 user, and considerably much
> longer as soon as a second user opens the same form.
I see - that's not something I specifically tested. I'll need to do some
digging, though I don't use the treeview that often.
With FireBird, this problem goes away?
Jan
| |
| Rick Gearardo 2006-11-02, 7:12 pm |
| Are you using a real file server or a peer-to-peer network. I have much
larger files using Novell and there is no speed difference in the app from 1
user to 50 users. The only speed issues I run into is if there is heavy
network traffic (streaming video at multiple workstations or large amounts
of data being backed up to the server.).
I also may have multiple users accessing the files from different apps
simultaneously with no problem.
If you are doing extensive file ops when it opens the work is being done at
the client, not the server, unless you are using something like Firebird or
another client/server system.
Is your network using HUBs or switches? If HUBs, change them out. That will
greatly reduce network traffic.
Rick
"Moses Hanna" < mosesjhanna@optusnet
.com.au> wrote in message
news:mHc8HJm$GHA.1684@news-server...
> Hi
> I have an application
> object files are on server
> data is in a separate directory also on server
> when the application is in use by one workstation, everything is alright
> but as soon as a second user uses the application, it becomes very very
> slow
> the table in the database are not so large ( the largest has around 11000
> rows
> May some gentleman tell me why it becomes very slow and how to overcome
> the problem?
> Thanks
> Moses
>
| |
| Jan Hoelterling 2006-11-02, 7:12 pm |
| That's my experience, as well. It's more the network traffic than the
application...
Jan
| |
| Lysander 2006-11-02, 7:12 pm |
| Jan Hoelterling schrieb:
> I see - that's not something I specifically tested. I'll need to do some
> digging, though I don't use the treeview that often.
The reason is not the treeview, I do use treeviews a lot and they
can be building up fast as lightning.
The reason is indeed the complex processing needed to build the
details for every treeitem.
> With FireBird, this problem goes away?
Yes, definitely.
I have been changing already about 50% of my application to use
FB-tables instead of DBF. In some places I was just gaining more
security, and efficiency in administration while speed was the same.
In some places I was gaining spees by a factor 50; even 200 and more
in some extreme places. Be sure to see a demo on the conference in
Marienheide :)
Not only is the server much faster; the underlying locking concept
is much better and more efficient. If your server is fast enough,
you will not notice a difference in 2 users using a form or 20 or 100.
| |
| Jan Hoelterling 2006-11-02, 7:12 pm |
|
"Lysander" <nobody@nowhere.com> wrote in message
news:YVDuvFp$GHA.1684@news-server...
> Jan Hoelterling schrieb:
> In some places I was gaining spees by a factor 50; even 200 and more in
> some extreme places. Be sure to see a demo on the conference in
> Marienheide :)
Definitely ;-)
Jan
| |
| David Kerber 2006-11-02, 7:12 pm |
| In article <sn67j0n$GHA.2124@news-server>, nobody@nowhere.com says...
> Moses Hanna schrieb:
>
> If you open that same table not properly indexed with 2 or more
> users at the same time, then, yes, it could take an hour or such
> depending on your network and hardware, ESPECIALLY if the table
> contains memos.
>
> I don't think, by the way, that there is a limit at 1M. Should be
There isn't; the limit is 1 Billion (10 ^ 9), not 1 Million (10 ^ 6)
(though I seem to remember that in some places, what they call 1 Million
is actually to an American 1 Billion).
You run into other limits like the total .dbf file size limit of 2
Billion first anyway, and there are practical limits from the BDE that
hit even earlier than that.
....
--
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).
| |
| Lysander 2006-11-02, 7:12 pm |
| David Kerber schrieb:
> You run into other limits like the total .dbf file size limit of 2
> Billion first anyway, and there are practical limits from the BDE that
> hit even earlier than that.
That's what I wanted to point out.
| |
| Omar Mohammed 2006-11-03, 12:12 am |
| My 2 cents
Apart from the other suggestions, you may also want to look at an anti-
virus application slowing down the network (Norton on my machines make
my forms really slow - when configured properly, it's gone).
I have similar problems but the first 3 machines are OK (about 5 sec)
the 4th machine drops that to about 15 sec.
Just a thought
| |
| Moses Hanna 2006-11-03, 5:12 am |
| In actual fact is that my tables were previously used with 5.7 application
the 5.7 application is still been used together with the 2.6 application.
the 5.7 application never experienced any slowdown even with 5 users.
It is the same server, same tables and exactly same environment.
why the 2.6 application becomes turtle with 2 users and 5.7 remains
like rabbit with 5 users
Moses
"Omar Mohammed" <omarAT@progmatix.biz> wrote in message
news:MPG. 1fb4774441f132919896
a5@news.dbase.com...
> My 2 cents
> Apart from the other suggestions, you may also want to look at an anti-
> virus application slowing down the network (Norton on my machines make
> my forms really slow - when configured properly, it's gone).
> I have similar problems but the first 3 machines are OK (about 5 sec)
> the 4th machine drops that to about 15 sec.
>
> Just a thought
| |
| Lysander 2006-11-03, 5:12 am |
| Moses Hanna schrieb:
> It is the same server, same tables and exactly same environment.
> why the 2.6 application becomes turtle with 2 users and 5.7 remains
> like rabbit with 5 users
One Answer: BDE.
But it does not mean, that BDE is only bad. It was in fact a great
improvement at that time.
Can you do some more tests? Maybe there is something that you can do.
1.)
Do you experience the slowliness on EVERY station or just on 1 or 2.
Make a test in turn. Let first one station use it then another come
to also use it and vice versa.
2.)
Do you experience the slowliness also if ONLY BDE-applications are
using the tables, or only when tables are used in mixed mode.
3.)
You did not tell if you do have local virus-scanners.
The problem is definitely connected to locking and creating
temp-tables anywhere. AV-software has a big hand in that.
You must know that using FLAT tables like dBase and Paradox on file
servers is NOT recommended by MS anymore, and by the way also not in
LINUX systems. That's why producers of AV software keep following
the recommendations to mark that type of file transactions as
"suspicious"
|
|
|
|
|