Network / Multiuser very slow!

[MikeC]

Re: Network / Multiuser very slow!

Hi Jarek,
I won't have much time today to play with this but here is your sample back with modifications --you will see the queries are taken out of the loop so that they only are done one time ....I cannot tell if they are needed without your actual database and script, but you should be able to see if it still does what you require. On my network (v8 I might add but should be similar results), this increased the speed significantly....hope you can do it this way.




Edit: Oh yeah, I also received the same error as you but this was happening even prior to any modifications by me.

Regarding the indices---I changed the two you had for each table to "All" and then Alpha recreated them both as it needed them as they were apparently. So in the end there are 4 indices and not 2.

[Janet Park]

Re: Network / Multiuser very slow!

You might also try setting up a ram disk. It works great to accelerate processing of disk intensive operations. I use ramdisk plus with a 1 gb ram drive to do address corrections on multi-million record databases. You can try it for free http://www.superspeed.com/desktop/ramdisk.phpt's only $49/pc for a desktop license. I got over a 100 times improvement in throughput for my address correction software just by moving data from hard disk to a ramdrive.

Worth a try. It all depends on where the bottleneck is.

[Bob Arbuthnot]

Re: Network / Multiuser very slow!

I'm intrigued by the Ramdisk products that Janet references in the previous post. Does anyone else have any experience with these products? Is there a down side to creating a virtual disk in system memory or RAMDISK and using it to run a data base program?

Just curious and more than a little intrigued.

ba

[csda1]

Re: Network / Multiuser very slow!

Hi Bob,

I had discussed this topic on the message board some years ago. The ramdisks I tried actually ran slower than current high speed hard drives, which I attributed this to the software drivers of the ramdisk vs the hard drives (which has been highly optimized by Microsoft), plus have onboard caches on the drives.

You could probably speed up some aspects of the data, but dictionaries seem to make no difference. I'd also be careful of crashes that take the data with it. But if someone can make a valid case for it, it's worth revisiting.

[Bob Arbuthnot]

Re: Network / Multiuser very slow!

Hi Ira,

Thanks for the input.

I'd also be careful of crashes that take the data with it.

The concept that the date was not continually written to the hard drive bothered me. Since there's apparently no speed gain I'll forget about it!

ba

[JarekZ]

Re: Network / Multiuser very slow!

Hello everyone.

I will try to explain what is really my purpose of posting that message.

Attached screen shot representing the situation. You can see there that the main table defines packages that contains some parts. In the middle table qty of parts is defined.
In the previous application that I had posted I have omitted the package table, but still my aim was to sum the cost of every package. To do that i have to for every package id in the pack_part table add the result of multiplying the part_qty and the part_price (that is in the parts table).
In the previous application I have shown 3 different approaches (that I know and use) how to achieve that - different types of queries and loops. This application is showing the time used to perform calculation for every package.
The problem is that when you run this simple application on two networked computers simultaneously the time increases rapidly for the second computer.

Mike - you have modify the application and gained lots of time, however by deleting the queries in loop there is no calculation performed and the loops are basically doing nothing.

Janet - thanks for the 'ram disk' idea. I don't know if the hardware is the factor here - when I run multiple instances of alpha application on one computer everything works fine + the table file is just few kB so it can not be problem with reading it - computer reads the file and writes it to the RAM for processing anyways (or am I wrong?)

Ira

I ran some tests on my A5V8 systems and saw similar times that you saw. (...)
However, it seems that by some process step I can't identify, at points the table seemed to go back to the faster speed after editing the script. So there might be a bug here, but I've yet to identify the cause.

Could you find out what have you done there to speed things up?


I was playing with the function TOTAL() - that is designed (according to manual) to be used only in reports (but the calculated fields are using it also) and I have been able to get the proper mathematical results and the speed problem was eliminated. This function however has limits and it's not straightforward in use.

Can somebody explain me why filtering the table (using any method i know) by two computers at the same time takes so long?

[Tom Cone Jr]

Re: Network / Multiuser very slow!

Jarek,

Can't answer your question.

Your design will lead to trouble if a part price changes after the package transaction is completed. If you don't store the actual part price in the transaction you won't ever be able to reproduce the invoice later on if (and when) a pricing change occurs.

A better design, in my opinion, is to drop the parts table from the set. Use it as a lookup source for new fields you add to the Pack_part table. Include a new calc field in the pack_part table to compute the extended price for each part. Post the extended totals for each part to a new field in the Package table. This approach does the calculating when each part is added to the package. The effect is to substantially reduce the processing that you're doing now when you crank out an invoice. Do it while the user is entering records, not when the user is waiting on the invoice to be printed.

[JarekZ]

Re: Network / Multiuser very slow!

Tom,

The posted app. is just an example.

In my real application I do have the prices stored in the package. When producing Invoice users do not have to wait because the total for the package is stored in the table. Once in a while however, we need to update the prices of the package because parts prices have changed. Then some user that have permission to do so is recalculating every single package, or just generating a report showing what packages has changed and how. This is when the problem arises. I have not notice that it takes a lot of time because on my computer - that is kinda server right now - it is always fast. But when other user wants to generate the report and my computer has the database opened all the calculations take more than it should.

Somebody else noticed that kind of behavior?

[Tom Cone Jr]

Re: Network / Multiuser very slow!

Jarek, I won't be responding again. Twice now you've posted samples and then later on say that they aren't like the "real application". I feel like I've wasted my time. Bye.

[JarekZ]

Re: Network / Multiuser very slow!

Jarek, I won't be responding again. Twice now you've posted samples and then later on say that they aren't like the "real application". I feel like I've wasted my time. Bye.

Tom,

I really appreciate your time and i know you have done some good things here on this board, but do you really want me to publish my whole application here just to show one particular example???

I have posted simple example of the application clearly showing what is wrong. I have asked why does it takes long to count it when two computers use the same application - I didn't ask why I have to count that and how to design my application so I will not have to count that!

I have been posting real questions.

I am sorry but you were not trying to help me with my problem. You didn't tell my why the counting process takes so long - you told me that this is not good idea to count it every time I am doing invoice - did i ever mention about any invoice here???
In my firs post I have said that i can not blame the hardware (because if alpha require more than what i have i can simply stop trying to use it!) but still people are sending solutions how to speed up the hardware!

I have asked one question, you have replied to another and now you are upset because you wasted your time trying to help me with something that i have not asked to....

I am a simple not very educated guy, i like simple questions and simple answers.
I have posted an example - if you want to help please download it, check if it behaves like i said and share with me your opinion.

If this is still not clear enough then I am really sorry for wasting everybody's time!

[aferraro]

Re: Network / Multiuser very slow!

It could also be a problem of Control Panel configuration settings on the "Master" computer.
Check within System \ System Properties \ Advanced the Performance Options specifically the Processor Scheduling and Memory Usage - unfortunately you might have to play with them since the machine is being used both as a PC and a Server, if it was a server the Processor Scheduling could be changed to Background Scheduling which would give "outside" users longer slices of time to execute their programs...

[MikeC]

Re: Network / Multiuser very slow!

Jarek,
Unless we have the same EXACT scenario as you it is all guesswork...as I and now Tom Cone have told you---and is why my first "guess" has been my last as there is no way to know how you are doing things.

It is not necessary to submit your entire database...or even part of it really so long as what you do submit as a sample ACCURATELY depicts your database. Actual data can be taken out so long as there is enough to show the problem and/or solutions properly.

I could not determine if the queries could be placed outside the loop because your sample obviously is out of the context of your actual database. Given your sample at the time, my modification was a viable solution. Given what Tom had as a sample, what he wrote also was a good solution or method to achieve your goal. You now have two or three solutions to problems you have submitted via your samples. The only reason these solutions cannot be used is due to your not ensuring your samples are actually depicting your database correctly.

It is a lot of work to submit good samples....but it is either that or get solutions/fixes that many times are incorrect or just won't work for your scenario. Besides the fact that it can frustrate the very people who spend the time to help.