1001 good reasons to upgrade tom bascom greenfield technologies
Embed Size (px)
TRANSCRIPT
1001 Good Reasons to Upgrade
Tom Bascom
Greenfield Technologies
Introduction
Tom Bascom
Greenfield Technologies
http://www.greenfieldtech.com
Agenda
History of Progress Releases The Benchmarks Data Summary
Agenda
History of Progress Releases The Benchmarks Data Summary
Just How Old is Version 8?
Or 6 & 7 for that matter? V9 was released when? What else was current way back then?
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)
[email protected] 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
[email protected] 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 App Servers WebSpeed Fast Schema Change -zprofile
[email protected] 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
[email protected] 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!!!
History Bonus Slides
Moore’s Law Disk Performance
Moore’s LawIn 1965 Gordon Moore famously observed that transistor counts were doubling every two years and predicted that this would continue…
Moore’s Law
Coupled with increases in clock speeds raw compute power per dollar (or euro) raises very quickly…
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
8086 28
6
386
486
Pen
tiu
m
Pen
tiu
m 2
Pen
tiu
m 4
"MIP
S"
(In
tel)
Disk Performance Disk Performance is Complex!
Capacity Increases roughly 100% annually
Bandwidth Increases roughly 40% annually
Access (especially random access!) Increases roughly 8% annually
Disk Performance Non-DBA bias is towards Capacity
(beancounters...) The trade press occasionally pays attention
to Bandwidth. A DBA’s bias is Random Access.
Time to read whole 3.5’’ disk:
Year Size Sequentially Randomly
1990 100MB 4 minutes 1 hour
2000 8GB 12 minutes 46 hours
Hardware Performance Summary Amdahl’s Law! The potential for
performance improvement is limited by the amount of time that the improved component is being used.
Constant Workload: 10x faster CPU + 10% disk = 5x faster system. 50% of potential improvement is lost. 100x faster CPU + 10% disk = 10x faster
system. 90% of potential improvement is lost to disk IO.
Agenda
History of Progress Releases The Benchmarks Data Summary
The Benchmarks
ReadProbe 4glProbe Populate Workload Big Report Dump Load Index Rebuild DB Analysis
Maintenance
Test Platform
“Mid Market” Hardware Dell PowerEdge 6600
4x2Ghz Xeon w/HT 2GB RAM 6 disks
Windows Server 2003 Linux AS 2.1
The Database
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
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
Not Tested
SQL-92 Effects of After Imaging Client/Server Exotic Parameters
Feature Focus Variable Block Sizes
Introduced with v8 1k, 4k & 8k (2k not tested)
Rows Per Block Introduced with v9 32, 64, 256 (1 not tested)
Type 1 vs Type 2 Storage Areas Introduced with OE10 Type 1 = 1 block per cluster Type 2 = 8, 64 & 512 blocks per cluster
Database Configurations
Apples to apples comparisons Version 8, Version 9, OpenEdge 10
1k, 4k, 8k db Blocks 32, 64, & 256 Rows per Block 1, 8, 64 & 512 Blocks per Cluster
48 Comparisons in all
“Issues”
_ActRecord VST is broken in OE10.0a – making some data gathering difficult (but does not impact functionality.)Fixed in 10.0B
9.1d07+ contains many, but not all, OE10 enhancements – which occasionally blurs the distinction between v9 & OE10
Agenda
History of Progress Releases The Benchmarks Data Summary
ReadProbe
Measures the ultimate limit of record read performance under IDEAL conditions (NO disk IO).
You’ll never actually get performance this good.
But you should be able to get close.
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
-60.00%
-40.00%
-20.00%
0.00%
20.00%
40.00%
60.00%
vs 83 vs 91d vs91d07
ReadProbe -- Linux1st 8 Sessions
-60.00%
-40.00%
-20.00%
0.00%
20.00%
40.00%
60.00%
vs 83 vs 91d vs91d07
ReadProbe -- LinuxSessions 26-50
-60.00%
-40.00%
-20.00%
0.00%
20.00%
40.00%
60.00%
vs 83 vs 91d vs91d07
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 -- Windows
Single Session
-60.00%
-40.00%
-20.00%
0.00%
20.00%
40.00%
60.00%
vs 83 vs 91d vs91d07
ReadProbe -- Windows1st 8 Sessions
-60.00%
-40.00%
-20.00%
0.00%
20.00%
40.00%
60.00%
vs 83 vs 91d vs91d07
ReadProbe -- Windows
Sessions 26-50
-60.00%
-40.00%
-20.00%
0.00%
20.00%
40.00%
60.00%
vs 83 vs 91d vs91d07
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 like OE10 on Windows
– OE10 is about 5% faster. Linux is a tad faster than Windows (5 to 10%). Windows has improved a lot since v8.
4glProbe
Ordinary 4gl string manipulation functions Loop constructs
Measure the time required to complete a set of these operations.
4GL Operations
2GHz P4 Xeon 4GL Performance
0
10000
20000
30000
40000
50000
60000
8.3e 9.1a05 9.1d 9.1d07 10.0a
Populate
Randomly fills the database with a configurable number of records.
Target record count is configured per table. One or more simultaneous threads per table. Field data is randomized.
Populate -- Windows
0
1000
2000
3000
4000
5000
6000
7000
80001
,32
,1
1,6
4,1
1,2
56
,1
4,3
2,1
4,6
4,1
4,2
56
,1
8,3
2,1
8,6
4,1
8,2
56
,1
Populate -- Linux
0
1000
2000
3000
4000
5000
6000
7000
80001
,32
,1
1,6
4,1
1,2
56
,1
4,3
2,1
4,6
4,1
4,2
56
,1
8,3
2,1
8,6
4,1
8,2
56
,1
Results – Populate (Insert & Update)
V9 is a big improvement over v8 under Windows. Larger block sizes are A Good Thing with v8 and
Windows – v9 likes them too. More rows per block are A Good Thing – especially
with Windows. OpenEdge 10 is generally better than v8 or v9 – but
in the case of type 1 storage areas the performance gains vs v9 are minimal.
Windows has improved a lot from v8 to OpenEdge 10 (between 20% & 60%).
Workload
Starts X sessions Each session has a tunable target for
Creates, Reads, Updates and Deletes. Each session randomly fulfills that target
much as a “user” would. Time spent working is measured and logged.
Workload 25 -- Linux
0.0000
1.0000
2.0000
3.0000
4.00001
,32
,1
1,6
4,1
1,2
56
,1
4,3
2,1
4,6
4,1
4,2
56
,1
8,3
2,1
8,6
4,1
8,2
56
,1
Workload 100 -- Linux
0.0000
1.0000
2.0000
3.0000
4.00001
,32
,1
1,6
4,1
1,2
56
,1
4,3
2,1
4,6
4,1
4,2
56
,1
8,3
2,1
8,6
4,1
8,2
56
,1
Workload 25 -- Windows
0.0000
1.0000
2.0000
3.0000
4.00001
,32
,1
1,6
4,1
1,2
56
,1
4,3
2,1
4,6
4,1
4,2
56
,1
8,3
2,1
8,6
4,1
8,2
56
,1
Workload 100 -- Windows
0.0000
1.0000
2.0000
3.0000
4.00001
,32
,1
1,6
4,1
1,2
56
,1
4,3
2,1
4,6
4,1
4,2
56
,1
8,3
2,1
8,6
4,1
8,2
56
,1
Results – Workload Progress® version number is 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. Type 1 storage areas under OE10 aren’t as good as
Type 2 areas – but they’re (mostly) better than v9 (Type 1).
32 rows per block in a type 1 area is generally asking for trouble.
Type 2 areas are much better in OE10 than in Type 1. Scalability improves as you upgrade from 8 to 9 to
OpenEdge 10.
Big Report
Queries a whole bunch of records in multiple tables.
Big Report -- Linux
0
500
1000
1500
2000
25001
,32
,1
1,6
4,1
1,2
56
,1
4,3
2,1
4,6
4,1
4,2
56
,1
8,3
2,1
8,6
4,1
8,2
56
,1
Big Report -- Windows
0
500
1000
1500
2000
25001
,32
,1
1,6
4,1
1,2
56
,1
4,3
2,1
4,6
4,1
4,2
56
,1
8,3
2,1
8,6
4,1
8,2
56
,1
Results -- Reporting
Windows has improved a lot. Otherwise V9 is the slowest.
OpenEdge 10 Type 1 storage areas are somewhat 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 – planning and testing pay.
Maintenance
Binary Dump Binary Load Index Rebuild DB Analysis
Maintenance -- Linux
0
500
1000
1500
2000
2500
30001
,32
,1
1,6
4,1
1,2
56
,1
4,3
2,1
4,6
4,1
4,2
56
,1
8,3
2,1
8,6
4,1
8,2
56
,1
Maintenance -- Windows
0
500
1000
1500
2000
2500
30001
,32
,1
1,6
4,1
1,2
56
,1
4,3
2,1
4,6
4,1
4,2
56
,1
8,3
2,1
8,6
4,1
8,2
56
,1
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.
Agenda
History of Progress Releases The Benchmarks Data Summary
Upgrade - Myths MYTH: Upgrades require more resources. Truth: Upgrades make better use of your existing
resources.
MYTH: Newer releases are slower than older releases.
Truth: Upgrades perform better on identical hardware.
MYTH: You need to spend the same money for a new server as the old.
Truth: You can get much better performance for much less money.
Upgrade -- Con
Straight “convXY” upgrades may be harmful to performance (especially with 1k blocks).
Conversion with type 1 style areas shows little benefit over v9.
Conversion with type 1 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 type 2 areas can be very
beneficial. 4gl performance is getting a lot of attention.
The Case For UpgradingLinux
-20.00%
-10.00%
0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
60.00%
70.00%
Populate Work25 Work100 BigRpt Maint
8 -> 9
8 -> 10
9 -> 10
The Case For UpgradingWindows
-20.00%
-10.00%
0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
60.00%
70.00%
Populate Work25 Work100 BigRpt Maint
8 -> 9
8 -> 10
9 -> 10
Wrap-up
Never underestimate the impact of cheap hardware!
As a general rule the db is not your ultimate constraint.
The most advantage comes from leveraging new features.
There is a clear positive trend in the numbers!
Resources
PSDN Whitepaper
http://www.greenfieldtech.com/downloads
http://www.greenfieldtech.com/articles