Network Optimization

[DORaymond]

I have a large app converted from A5V4.5 to A5V10.5. I am still wrestling with poor performance and complaints from our workstation users. By accident I had one workstation running the app non-optimized, and it seems to run much better than optimized.

Can anyone guess why this would be?

If I were to run all the workstations non-network optimized would I run into additional unforeseen trouble?

[Stan Mathews]

Re: Network Optimization

The benefit to network optimization is that the support files for each table and set are copied to the workstation. The dbf files containing the data remain on the server. Since the support files are local to the workstation layouts should load faster.

[DORaymond]

Re: Network Optimization

Stan - Yes and in principle that is how it works - In V4.5 the network performance was terrible without optimization. Now with V10.5 I am seeing a significant slowdown in every part of the application and am finding that a non-optimized workstation is running faster. Could there be an issue in how Alpha V10x uses the "dummy" shadowed database locally and then has to go out and find the real database on the server?

[Al Buchholz]

Re: Network Optimization

Stan - Yes and in principle that is how it works - In V4.5 the network performance was terrible without optimization. Now with V10.5 I am seeing a significant slowdown in every part of the application and am finding that a non-optimized workstation is running faster. Could there be an issue in how Alpha V10x uses the "dummy" shadowed database locally and then has to go out and find the real database on the server?

Probably not.

It's more likely to be code that should be changed to newer v10 code or an index that worked before is now gone or subtly works differently.

It's always important to triage a problem to find the cause of the issue. Then the problem can be eliminated.

debug(1) and message boxes can go a long way in the triage.

[DORaymond]

Re: Network Optimization

Most forms do not have any code, but they all have embedded browses. I think instead of debug(1) it is probably more like recreate from scratch.

If I were to erase all the .cdx files associated with the app, then compact, would Alpha recreate them all from new?

[Stan Mathews]

Re: Network Optimization

No. The cdx files are what you have created plus what Alpha adds as necessary for set linkages, etc.

[DORaymond]

Re: Network Optimization

Thanks Stan.

I was thinking of how to easily address "an index that worked before is now gone ". Compact should put the indexes back into shape, but I was thinking that physically deleting them and then having them rebuilt might be different? I suppose if I were to try this on a copy of the production app, Alpha would put back the indexes it needs to operate and I would have to rebuild the rest (?).

[Al Buchholz]

Re: Network Optimization

It's always important to triage a problem to find the cause of the issue. Then the problem can be eliminated.

[JohnZaleski]

Re: Network Optimization

I would disable any virus software you are running and test it again. Regardless of your
design, there's no way an optimized app should run slower than a non optimized app.
Test this on a single specific task before and after disabling both optimized and non optimized.

[DORaymond]

Re: Network Optimization

John - We run AVG enterprise edition and it is set to not touch any of the Alpha files or data. I will disable it completly to be sure it is not having an effect.

Thanks.

[CALocklin]

Re: Network Optimization

<snip>I was thinking of how to easily address "an index that worked before is now gone ".</snip>

The only issue here is the word "easily". What some think is easy may be seen as hard to others. It all depends on what you're used to.

If an index is gone, there is no way for Alpha to rebuild it by itself. The only way is for you as the developer to save the index definitions in some way so you can rebuild them.

Some people just keep an original copy of the .cdx file. When an index "goes missing" they copy the original to the database and then rebuild the indexes so they match the current data. The "copy and update" can be done manually or via scripting.

I prefer to build a script that deletes the existing .cdx file(s) and rebuilds them from scratch. Alpha now has functions that will get the index definitions for you and you can work with that info to build the script.

In case you don't want to do it yourself ...
Long before Alpha created the routine to get the index definitions, I created a Create_Index_Rbld_Auto() function that retrieves the current index definitions from Alpha and builds a function in your database called Index_rebuild_auto(). Then the developer just adds a button on the Utilities menu with the 'very complicated' xbasic script of "Index_rebuild_auto()" and the user clicks that button whenever the indexes need to be rebuilt. There are also other arguments for the function so you can automatically rebuild selected indexes (perhaps before doing something critical like building invoices) or to hide the "select which indexes to rebuild" prompt, etc. I sell the addin for $19 here. The addin itself only goes on the developer's computer so the developer can run the Create_index_rbld_auto() function (typically from the Interactive Window) once the proper indexes have been created. The resulting Index_rebuild_auto() function that the user calls to rebuild the indexes will be put in the Code tab. If indexes are added, deleted, or modified during updates or bug fixes, simply re-run the Create_index_rbld_auto() function again and the old Index_rebuild_auto() function will be replaced with a new one that contains the new index definitions.

[DORaymond]

Re: Network Optimization

Cal,

Do you think deleting and then rebuilding the index files is a better method than just compacting the database?

[CALocklin]

Re: Network Optimization

Depends on what you're trying to do.

Compacting the database will "rebuild" indexes the same way that Alpha's internal "update indexes" routine does. It updates existing indexes only - it doesn't rebuild missing indexes.

Compacting also packs deleted records and "compacts" the data dictionary files.

I don't personally like running the Database Compact routine but only because I seldom need to do all three things at once. If you don't have an alternative, use the Database Compact. When I need to compact the data dictionaries (which should be done fairly often during development), I prefer to use the "Compact Dictionaries" routine that is in my AIMS Grab Bag because ALL it does is compact the data dictionaries and that is VERY fast relative to the time it takes to rebuild all the indexes when doing a full "Database Compact". You can build a similar routine using Dictionary.Update() or Table.compact(<dd_name>). (Or my AIMS Grab Bag is another $19 addin.)
NOTE - the "!Note" in the Help file under Table.Compact() is incomplete. It says nothing about the fact that the "Database Compact" routine also rebuilds indexes and removes (packs) deleted records. The Dictionary.Update() and Table.Compact() functions ONLY compact the data dictionaries - they have no effect on indexes or deleted data records.

[DORaymond]

Re: Network Optimization

Thanks for your response.

Is there a time when you would want to physically delete the index and then rebuild it back as you have discussed (like with the function you built)?

[CALocklin]

Re: Network Optimization

Thanks for your response.

Is there a time when you would want to physically delete the index and then rebuild it back as you have discussed (like with the function you built)?

Whenever an index "disappears".

I also use it whenever indexes seem to get corrupted. In that case you could just use the "update indexes" routine but (a) my routine works just as fast so I feel it's easier to just tell users to click the same "Rebuild Indexes" button and (b) when the indexes seem to be corrupted, how can you be sure all the original index definitions are still there?