We have a large ERP database with about 1200 tables (counting meta-tables). Opening an active connection in PDSOE to this database is painfully slow. Not sure why, but whatever this PDSOE needs to retrieve from the database just trickles over the network in a *tiny* little stream of data with no real CPU activity on either side. (or maybe just one core on the database side).
I've discovered that there are "DB structure filters" where I can use wildcards (eg tables prefixed with gen*,prd*) and this helps a bit. But I'm constantly having to edit the silly filters whenever I move from one programming work item to another. Unless I'm filtering out 90 % of the tables then things get really slow.
Something ain't right... Is there a configuration issue in PDSOE or on my workstation or on the DB server? Also, why is resource utilization so low? The only thing I can think of is that perhaps this stuff is limited to using one core on the OE database side, as it gathers together the schema. I'm wondering if the developers who create these tools don't have multi-core CPU's like I do...
The version I use every day is 11.6.1. (Windows PDSOE 32 bit.) I also have another 11.6.3 , 64 bit machine (a workgroup server) which we just hotfixed this past week to 11.6.3.XXX ... but the PDSOE on there is broken at the moment (I must have missed a step in the hotfix readme instructions).
Should I compare the performance of connecting to a database on these two versions? (Assuming I can make PDSOE work again after the hotfix.)
Thanks, David
PS.
Ideally the job of connecting to a database would just bring back the list of table names, and that would be sufficient to show the list in the db structure view. You could incrementally grab the schema of individual tables as needed (on demand). If that part is performance-intensive (and single-threaded as well), then there is no need to pull in the *entire* database schema. For any given project, I will only need to examine 10-20 of the tables at a time.
OK, I was able to get my PDSOE 11.6.3.010 (64 bit) working again. I suspect that I did something stupid when unpacking your hotfix and following all the instructions. Applying your Progress hotfixes seems like an error-prone process. It seems like there is some room for improvement. (I expect you get a good number of additional support calls from misapplied hotfixes.)
Anyway , the difference is noticeable. The benefits only seem to present themselves when connecting the 11.6.3 version of PDSOE to an 11.6.3 database. If I connect to an older database (11.3) it still run slow. Its good to know that this stuff is at least on your radar...
This is a reason for me to upgrade to 11.6.3. I wonder if I missed it in the release notes because I probably would have upgraded earlier.
Thanks for the tip!
My previous testing of this involved 11.6.3 PDSOE connecting to a *local* 11.6.3 database using a jdbc driver that specified the host and port number. That test demonstrated reasonably fast performance, only because it was connecting locally.
When I upgraded a remote workstation to PDSOE v.11.6.3 (from 11.6.1) and repeated the test (connect from a remote PDSOE to the OE database) it was slow as before. Based on that testing, I do not believe there have been any significant performance improvements in database navigation from PDSOE 11.6.3 after all.
I ran wireshark to examine the activity across the network and there appear to be about 70,000 packets exchanged when expanding the list of tables in the remote database schema. (Although this exchange is done with a bandwidth of only 1 Mbps) There is little resource utilization on either side (no CPU, disk, etc). Given that a connection to a *local* database was so much faster in PDSOE, I'm assuming that the navigation of databases didn't account for *remote* connections. The intent was probably for a developer to connect to the developer license of the OE database that is installed locally along with PDSOE.