e1760: 1001 good reasons to upgrade progress exchange 2004 las vegas, nevada tom bascom greenfield...
Post on 27-Dec-2015
214 Views
Preview:
TRANSCRIPT
E1760: 1001 Good Reasons
to Upgrade
Progress Exchange 2004
Las Vegas, Nevada
Tom BascomGreenfield Technologiestom@greenfieldtech.comhttp://www.greenfieldtech.com
Just How Old Is Version 8?
Or 6 & 7 for that matter? V9 was released when? What else was current way back when?
V6 -- 1990
Fuzzy Checkpoints -spin PF Files
UNIX System V r4 RS 6000 Windows 3.0 MS Sales = $1B 10mhz 286 PS/1: $2000 NEC Laptop: $8500
16mhz 386sx2MB RAM42MB disk(color)
progress-list@thinc.com launched by Ethan Lish
V7 -- 1992 Jumpstart GUI -mmax Load ‘n Go!
OS/2 2.0 Windows 3.1 SLS Linux distribution 486DX2 25/50mhz 66mhz PowerPC HP 9000 725
50mhz PA RISC16mb RAM, 512MB disk $18k
Thinkpad 700c: $4,35025mhz 486sl4MB RAM120MB disk
progress-list@math.niu.edu taken over by Greg Higgins
Approximately 175 subscribers and 10-12 messages/month
V7.3 -- 1995 Persistent Procedures MS Consent Decree
Win95 Linux 1.0 (’94 actually) Pentium Pro 200mhz DEC Alpha 300mhz
Peg.com domain registeredApproximately 700 subscribers and 1000 messages/month
Something called “The Web” explodes onto the world…
V8 -- 1996
NT 4 1GB disks start to appear Linux 2.0
User-Defined Functions VSTs Variable Block Sizes AppServer™ WebSpeed® Fast Schema Change -zprofile
dba@peg.com created in May ‘98
V9 -- 1999 Pentium 3 announced Judge Jackson declares MS
is an abusive monopoly Windows 2000 released SCO & IBM start working on
“Monterey” Fujitsu Lifebook: $2,600
333mhz PII64MB RAM6.4GB disk
Storage Areas Publish and Subscribe Dynamic Queries XML SQL-92 Load ‘n Go actually works
dba@peg.com created in May ‘98
OpenEdge™ 10 -- 2004 The SCO Saga P4 Xeon @ 3.0ghz Dell Latitude: $2,500
Pentium M @ 1.2ghz640MB RAM40GB disk
Data Clusters ProDataSet SOAP
PEG has more than 3,000 messages/month and approximately 5,200 subscribers -- they’d all be here but they’ve got important work to do…
DateTime!!!
Test Platform
Windows Server 2003 Linux AS 2.1 “Mid Market” Hardware
Dell PowerEdge 6600 4x2Ghz Xeon w/HT 2GB RAM 6 disks
The Database
OpenEdge 10.0A (without Service Pack 1) Sports2000 schema Randomly generated data Mix of Table & Record sizes Some Scatter
Database AnalysisTable Records Size Min Max Mean FactorBenefits 5000 282.3K 42 73 57 2.5BillTo 200000 32.0M 76 258 167 2.6Bin 50000 2.3M 31 64 48 2.6Customer 100000 27.9M 173 409 292 2.6Department 20 1.0K 36 74 53 1.0Employee 5000 1.1M 153 333 236 3.0Family 15000 914.9K 36 89 62 2.9Feedback 100000 13.9M 72 220 145 3.0InventoryTrans 1000000 80.3M 56 115 84 2.2Invoice 1000000 52.0M 46 55 54 1.9Item 1000000 139.9M 83 210 146 2.1LocalDefault 1000 159.4K 101 230 163 3.2Order 1000000 168.3M 98 263 176 2.0OrderLine 1500000 94.5M 46 81 66 1.7POLine 8000000 505.6M 49 82 66 1.4PurchaseOrder 20000 920.0K 33 61 47 2.7RefCall 9997 917.8K 45 144 94 3.1Salesrep 300 25.3K 52 122 86 3.2ShipTo 500000 88.6M 89 286 185 2.4State 50 3.5K 44 102 70 1.0Supplier 5000 1.0M 121 293 210 3.1SupplierItemXref 1000000 22.8M 20 24 23 1.8TimeSheet 250000 29.7M 63 186 124 2.6Vacation 10000 244.0K 24 25 24 2.1Warehouse 100 16.0K 101 219 163 1.0Subtotals: 15771467 1.2G 20 409 83 2.0
Database Configurations
Monolithic Split Data & Indexes 1k, 4k, 8k db Blocks 32, 64, & 256 Rows per Block 1, 8, 64 & 512 Blocks per Cluster
Tuning Parameters
Mostly “Out of the Box” Try not to make this a disk performance test Basic Tuning
-B -i Simple File Placement
No Heroics
Populate -- LinuxPopulate
0
1000
2000
3000
4000
5000
6000
7000
8000
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47
Populate
ASA1 Storage Areas (1 block per cluster)
Populate -- WindowsPopulate
0
1000
2000
3000
4000
5000
6000
7000
8000
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47
Populate4k block
8k block
1k block
Results – Populate (Insert & Update)
V9 is a big improvement over v8. Larger block sizes are A Good Thing. More rows per block are A Good Thing. OpenEdge 10 is better than v8 or v9 – in the
case of an ASA1 storage area – the performance gains are minimal.
Windows has improved a lot from v8 to OpenEdge 10 (between 20% & 60%).
Workload -- LinuxWork Load
0.000
0.500
1.000
1.500
2.000
2.500
3.000
3.500
4.000
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47
Work25
Work100
8k block, 32rpb, 1bpc
Workload -- WindowsWorkload
0.000
0.500
1.000
1.500
2.000
2.500
3.000
3.500
4.000
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47
Work25
Work100
Results – Workload Progress® version number seems dominant.
V8 is best for very light workloads. V9 is worst in almost all cases. OpenEdge 10 does very well with heavier loads.
More rows per block are usually A Good Thing. ASA1 style storage areas under OE10 aren’t as good
as ASA2 areas – but they’re (mostly) better than v9. ASA2 areas are much better in OE10 than in ASA1.
Scalability improves as you upgrade from 8 to 9 to OpenEdge 10.
Big Report -- Linux BigRpt
0
100
200
300
400
500
600
700
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47
BigRpt
8k block, 32rpb, 1bpc
Big Report -- WindowsBigRpt
0
100
200
300
400
500
600
700
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47
BigRpt
Results -- Reporting
Windows has improved a lot. Otherwise V9 is the slowest.
OpenEdge 10 ASA1 style areas are performance challenged.
Large block, row & cluster sizes are A Good Thing.
It’s easy, and painful (a 30% swing), to shoot yourself in the foot with v9 & OpenEdge 10.
ReadProbe -- LinuxReadProbe -- Linux
0
20,000
40,000
60,000
80,000
100,000
120,000
140,000
160,000
180,000
200,000
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49
8.3E
9.1D
9.1D07
10.0A
ReadProbe -- LinuxSingle Session vs 8 vs 9.1d vs 9.1d07 128,442 8.3e 55,432 -56.84% 9.1d 75,496 -41.22% 36.20% 9.1d07 72,094 -43.87% 30.06% -4.51% 10.0a
1st 8 Sessions 131,376 8.3e 119,005 -9.42% 9.1d 139,656 6.30% 17.35% 9.1d07 126,858 -3.44% 6.60% -9.16% 10.0a
Sessions 26-50 122,253 8.3e 142,220 16.33% 9.1d 157,156 28.55% 10.50% 9.1d07 160,110 30.97% 12.58% 1.88% 10.0a
ReadProbe -- WindowsReadProbe -- Windows
0
20,000
40,000
60,000
80,000
100,000
120,000
140,000
160,000
180,000
200,000
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49
8.3E
9.1D
9.1D07
10.0A
ReadProbe -- WindowsSingle Session vs 8 vs 9.1d vs 9.1d07 80,468 8.3e 67,249 -16.43% 9.1d 66,570 -17.27% -1.01% 9.1d07 75,735 -5.88% 12.62% 13.77% 10.0a
1st 8 Sessions 114,641 8.3e 127,539 11.25% 9.1d 127,566 11.27% 0.02% 9.1d07 128,914 12.45% 1.08% 1.06% 10.0a
Sessions 26-50 104,820 8.3e 147,942 41.14% 9.1d 147,408 40.63% -0.36% 9.1d07 154,371 47.27% 4.35% 4.72% 10.0a
Results -- ReadProbe
v8 is very fast for a single session – which is important (high profile issues).
But v8 gets in trouble with contention quickly. v9 scales better than v8. 9.1d07 acts a lot like OpenEdge 10 on Linux. 9.1d & 9.1d07 act a lot alike on Windows. Linux is a tad faster than Windows (5 to
10%).
Maintenance -- LinuxMaintenance
0
200
400
600
800
1000
1200
1400
1600
1800
2000
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47
Dump
Load
IdxBuild
8k,32rpb, 1bpc4k,32rpb, 1bpc
1bpc
v8 v9 OE10
4k blocks1k blocks 8k blocks8k blocks
4k blocks1k blocks
Maintenance -- WindowsMaintenance
0
200
400
600
800
1000
1200
1400
1600
1800
2000
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47
Dump
Load
IdxBuild
Results -- Maintenance 1k db blocks are a bad idea. 8k blocks @ 32 rpb are a really bad idea. 4k and 8k are generally roughly similar in
performance. OpenEdge Binary Dump can be much faster (60 to
70%) than v8 or v9 if you use 64 or 512 blocks per data cluster.
OpenEdge 10 Binary Load does not like 1k db blocks or 8 block data clusters.
Index Rebuild isn’t much different from 9 to 10. Index Rebuild is about 40% faster from 8 to 10.
PROMON I/OProMon
0
5000000
10000000
15000000
20000000
25000000
30000000
35000000
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47
Dump LR
Dump OSR
Load LR
Load LW
Load OSR
Load OSW
Interesting Observations
Dumping an ASA1 database takes 2x the OS reads as an ASA2 database.
Loading an ASA2 database results in a large number of OS reads (and probably Log reads too) that an ASA1 db does not incur.
Loading an ASA2 database takes 2x the OS writes vs ASA1.
V9 ASA1 seems somewhat different from an OE10 ASA1.
4GL Operations
2GHz P4 Xeon
0
10000
20000
30000
40000
50000
60000
8.3e 9.1a05 9.1d 9.1d07 10.0a
4GL Performance
Upgrade -- Con
Straight “convXY” upgrades may be harmful to performance (especially with 1k blocks).
Conversion with ASA1 style areas shows little benefit over v9.
Conversion with ASA1 style areas may be a step backwards in some cases.
8.3 was very good and remains very good in its niche.
Upgrade -- Pro
Day-to-day Workload improvements. Maintenance Improvements. Conversion to larger block sizes and row per
block settings can be very beneficial. Conversion to ASA2 areas can be very
beneficial. 4gl performance is getting a lot of attention.
The Case For Upgrading
Populate Work25 Work100 BigRpt Dump Load IdxBuild DBA 4GL
Linux
8 -> 9 22.05% -19.93% 18.84% -14.99% 40.67% 34.21% 35.17% 34.62% 8%*
8 -> 10 25.19% -2.39% 40.69% 2.11% 59.78% 28.07% 38.52% 26.92% 36%
9 -> 10 4.03% 14.63% 26.92% 14.87% 32.20% -9.33% 5.17% -11.76% 31%
Windows
8 -> 9 17.02% 25.89% 48.72% 6.06% 48.21% 25.08% 41.19% 61.54% 34%
8 -> 10 41.43% 47.27% 68.21% 34.26% 69.58% 21.40% 42.29% 61.54% 59%
9 -> 10 29.41% 28.85% 38.01% 30.02% 41.27% -4.91% 1.87% 0.00% 38%
Resources
http://www.greenfieldtech.com/downloads
http://www.greenfieldtech.com/articles
top related