1. 1001 Good Reasons to Upgrade Tom Bascom Greenfield Technologies

2. Introduction Tom Bascom Greenfield Technologies http://www.greenfieldtech.com tom@greenfieldtech

3. Agenda History of Progress Releases The Benchmarks Data Summary

4. Agenda History of Progress Releases The Benchmarks Data Summary

5. Just How Old is Version 8? Or 6 & 7 for that matter? V9 was released when? What else was current way back then?

6. 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 386sx 2MB RAM 42MB disk (color) progress-list@thinc.comprogress-list@thinc.com launched by Ethan Lish

7. 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 RISC 16mb RAM, 512MB disk $18k Thinkpad 700c: $4,350 25mhz 486sl 4MB RAM 120MB disk progress-list@math.niu.eduprogress-list@math.niu.edu taken over by Greg Higgins Approximately 175 subscribers and 10-12 messages/month

8. V7.3 -- 1995 Persistent Procedures MS Consent Decree Win95 Linux 1.0 (94 actually) Pentium Pro 200mhz DEC Alpha 300mhz Peg.com domain registered Approximately 700 subscribers and 1000 messages/month Something called The Web explodes onto the world…

9. 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 dba@peg.comdba@peg.com created in May 98

10. 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 PII 64MB RAM 6.4GB disk Storage Areas Publish and Subscribe Dynamic Queries XML SQL-92 Load n Go actually works dba@peg.comdba@peg.com created in May 98

11. OpenEdge 10 -- 2004 The SCO Saga P4 Xeon @ 3.0ghz Dell Latitude: $2,500 Pentium M @ 1.2ghz 640MB RAM 40GB disk Data Clusters ProDataSet SOAP PEG has more than 3,000 messages/month and approximately 5,200 subscribers -- theyd all be here but theyve got important work to do… DateTime!!!

12. History Bonus Slides Moores Law Disk Performance

13. Moores Law In 1965 Gordon Moore famously observed that transistor counts were doubling every two years and predicted that this would continue…

14. Moores Law Coupled with increases in clock speeds raw compute power per dollar (or euro) raises very quickly…

15. Disk Performance Disk Performance is Complex! Capacity Increases roughly 100% annually Bandwidth Increases roughly 40% annually Access (especially random access!) Increases roughly 8% annually

16. Disk Performance Non-DBA bias is towards Capacity (beancounters...) The trade press occasionally pays attention to Bandwidth. A DBAs bias is Random Access. Time to read whole 3.5 disk: Year Size SequentiallyRandomly 1990 100MB 4 minutes 1 hour 2000 8GB 12 minutes 46 hours

17. Hardware Performance Summary Amdahls 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.

18. Agenda History of Progress Releases The Benchmarks Data Summary

19. The Benchmarks ReadProbe 4glProbe Populate Workload Big Report Dump Load Index Rebuild DB Analysis Maintenance

20. Test Platform Mid Market Hardware Dell PowerEdge 6600 4x2Ghz Xeon w/HT 2GB RAM 6 disks Windows Server 2003 Linux AS 2.1

21. The Database Sports2000 schema Randomly generated data Mix of Table & Record sizes Some Scatter

22. Database Analysis Table Records Size Min Max Mean Factor Benefits 5000 282.3K 42 73 57 2.5 BillTo 200000 32.0M 76 258 167 2.6 Bin 50000 2.3M 31 64 48 2.6 Customer 100000 27.9M 173 409 292 2.6 Department 20 1.0K 36 74 53 1.0 Employee 5000 1.1M 153 333 236 3.0 Family 15000 914.9K 36 89 62 2.9 Feedback 100000 13.9M 72 220 145 3.0 InventoryTrans 1000000 80.3M 56 115 84 2.2 Invoice 1000000 52.0M 46 55 54 1.9 Item 1000000 139.9M 83 210 146 2.1 LocalDefault 1000 159.4K 101 230 163 3.2 Order 1000000 168.3M 98 263 176 2.0 OrderLine 1500000 94.5M 46 81 66 1.7 POLine 8000000 505.6M 49 82 66 1.4 PurchaseOrder 20000 920.0K 33 61 47 2.7 RefCall 9997 917.8K 45 144 94 3.1 Salesrep 300 25.3K 52 122 86 3.2 ShipTo 500000 88.6M 89 286 185 2.4 State 50 3.5K 44 102 70 1.0 Supplier 5000 1.0M 121 293 210 3.1 SupplierItemXref 1000000 22.8M 20 24 23 1.8 TimeSheet 250000 29.7M 63 186 124 2.6 Vacation 10000 244.0K 24 25 24 2.1 Warehouse 100 16.0K 101 219 163 1.0 Subtotals: 15771467 1.2G 20 409 83 2.0

23. 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

24. Not Tested SQL-92 Effects of After Imaging Client/Server Exotic Parameters

25. 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

26. 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

27. 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

28. Agenda History of Progress Releases The Benchmarks Data Summary

29. ReadProbe Measures the ultimate limit of record read performance under IDEAL conditions (NO disk IO). Youll never actually get performance this good. But you should be able to get close.

30. ReadProbe -- Linux

34. ReadProbe -- Windows

38. 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.

39. 4glProbe Ordinary 4gl string manipulation functions Loop constructs Measure the time required to complete a set of these operations.

40. 4GL Operations 2GHz P4 Xeon

41. 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.

42. Populate -- Windows

43. Populate -- Linux

44. 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%).

45. 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.

46. Workload 25 -- Linux

47. Workload 100 -- Linux

48. Workload 25 -- Windows

49. Workload 100 -- Windows

50. 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 arent as good as Type 2 areas – but theyre (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.

51. Big Report Queries a whole bunch of records in multiple tables.

52. Big Report -- Linux

53. Big Report -- Windows

54. 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. Its easy, and painful (a 30% swing), to shoot yourself in the foot with v9 & OpenEdge 10 – planning and testing pay.

55. Maintenance Binary Dump Binary Load Index Rebuild DB Analysis

56. Maintenance -- Linux

57. Maintenance -- Windows

58. 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 isnt much different from 9 to 10. Index Rebuild is about 40% faster from 8 to 10.

59. Agenda History of Progress Releases The Benchmarks Data Summary

60. 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.

61. 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.

62. 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.

63. The Case For Upgrading

65. 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!

66. ? Any Questions Tom Bascom Greenfield Technologies tom@greenfieldtech.com http://www.greenfieldtech.com

67. Resources PSDN Whitepaper http://www.greenfieldtech.com/downloads http://www.greenfieldtech.com/articles