UTILIZING A TERAPLEX INTEGRATION CENTER: AN INTERVIEW WITH ALLEN PERRY
by Alan Beck, editor in chief

Interview with Allen Perry, owner of Coglin Mill

D S * : How did Coglin Mill come to utilize a Teraplex Center?

PERRY: Our software, Rodin, is an enterprise-wide data warehouse management product for medium- to large-scale customers, employed for building the core enterprise warehouse. We have been working with some of IBM's largest customers in the AS/400 arena who are now moving into extremely large data warehouse implementations. Although we don't yet have a terabyte-sized data warehouse, such warehouses are certainly being built; thus the AS/400 and Rodin are starting to be involved in these very large environments.

We were apprehensive about moving into such environments, not having tested our software nor IBM's hardware and software with respect to their limits and performance levels. We needed the Teraplex centers to prove that we could deliver solutions at that really high end.

D S * : How would you characterize your experience with the Center?

PERRY: We used the Rochester Center, where a network of five AS/400s was made available, both 12-way and 8-way architectures. There were about 5 terabytes of disk and 100 gigabytes of data tape. We could not have used hardware of that configuration and value anywhere else. The Teraplex team under Mike Caine's management helped us design the tests and insured correct interpretation of the results.

A lot of tuning and "turning-the-dials" went on to improve performance and optimize hardware and system-software utilization as well as our own software. We were able to improve on the fly to improve something like 20-fold -- much of that was in the hardware, the new E-series announcements, where they delivered a 5-fold performance improvement.

Both IBM and Coglin Mill were also able to stress-test much code that hadn't been tested in this environment before. As always happens when you do this -- and part of the reason you want to do it -- is to find any undocumented features that shouldn't be there. Both firms were able to do that. And both developments teams made sure that when we encountered problems they were usually fixed immediately. That's really unique -- to be within the heart of a development mode, run into a bug, and fix it almost instantly. The experience was incredible.

IBM did not charge us for this, but we picked up the costs of transporting personnel to the Center and reimbursing them for their services.

D S * : How long did the tests take? Did you complete all necessary tests?

PERRY: Tests were conducted in two series. Some were run in May and June on the "old" hardware, and we tested again in October and November to prove the changes we made were valid and also retest high-end performance on the new hardware. In all, we were in there virtually full-time for about three months. However, we've had continual access to the Center since March, and we are still able to use it today.

We did complete all tests we intended this time through. Although we made appropriate corrections to the code we were using, we still have to make these in the production version. That process has already begun, and we expect to put all that code in place during the first quarter of 1998. After that code is implemented, we will have a need to retest.

During the tests conducted this year, we concentrated primarily on the load performance of the warehouse. To that extent, we were able to conduct all the tests required to identify areas of needed work without much difficulty. However, there are still other areas we can improve. It's one thing to move data into a data warehouse as efficiently as possible and another to extract data from it, particularly with extensive end-user involvement. Our firstquarter tests in 1998 will focus on those areas.

D S * : As you scaled-up during the tests, did you encounter any surprising results?

PERRY: Probably the most surprising thing was the almost linear scalability of the AS/400 SMP and MPP technology. Most hardware and software architectures will taper-off the harder you thrash them, because they reach performance limits that create severe degradation: your common "hitting-thewall" problem. We didn't run into such problems. We were able to drive all of the CPUs in our tests; one test involved running 36 parallel CPUs to load a file into the warehouse, and all of them were at 100% utilization. Yet we achieved straight-line performance and load rates of 60 gigabytes per hour: this is normally unheard-of in the industry. We did this on three AS/400s, and we know we can linearly scale that to 32 AS/400s joined together. So it is possible to achieve ten times that performance in a straight-line performance curve: that means approaching 600 gigabytes per hour, which is a bit like loading the world in half an hour.

We also found some things wrong with our software and IBM's. We hit some limits on the number of rows you can actually put into a single database. We found many issues associated with deeper-down technologies. Having encountered these and arrived at a better understanding of how they work, we were able to adjust how we and the AS/400 were doing the work.

As you can understand, this is much like being in a sportscar with the accelerator floored. If you run long enough like that, something is going to break. So we were able to break some things in the operating system and discover some things that required additional work in our own software. This is one of the reasons you conduct such tests in the first place: to insure you do understand those limits and put things in place to minimize their impact today and eliminate them in the future.

For more information, including the full test results, see
http://www.coglinmill.com

---

Alan Beck is editor in chief of D S * and vice president of publications for Tabor Griffin Communications. Comments are always welcome and should be emailed to: alan@tgc.com