Що таке TPC
Що таке системи, побудовані з архітектури «клієнт/сервер»? У переважній більшості випадків, цими системами є системи обробки запитів до баз даних. Найчастіше перед організаціями, які бажають автоматизувати свою діяльність, виникає безліч питань. Одним із ключових питань є вирішення однієї, і вельми непростої проблеми – оптимального вибору платформи для майбутньої системи.
Зрозуміло, що відповідь на таке питання не можна приймати, орієнтуючись на розрізнені матеріали, що публікуються в пресі, запевнення виробників, думки колег чи власне суб'єктивне ставлення до певної платформи чи продукту. Ціною необачно прийнятого рішення можуть бути величезні фінансові витрати та втрачений час. Обґрунтування такого рішення потребує якоїсь точки відліку, тобто результатів тестування, підтверджених незалежними джерелами.
Аналогічні проблеми стоять перед фірмами-розробниками програмного забезпечення. Наскільки розроблена нашою фірмою програма краща за програму конкурентів? Чи, навпаки, у чому ми програємо конкурентам? Що потрібно зробити для того, щоб наша програма була кращою?
Існує досить багато фірм, які займаються публікацією тих чи інших тестів продуктивності апаратного та програмного забезпечення. На жаль, часто результати цих тестів викликають цілком обґрунтовану недовіру, особливо якщо наприкінці звіту написано "тестування проведене на замовлення такої компанії".
Очевидно, що перед необхідністю прийняття таких рішень (або обґрунтування своїх домагань) стояливиробники та замовники подібних систем на початку 80-х років, коли в промисловості почалася гонка, що триває досі. Початок цієї гонки пов'язують із початком автоматизації бізнес-процесів.
Природно, що трохи пом'якшити гостроту проблеми могли лише тести продуктивності систем, які на той момент перебували у зародковому стані. Починаючи з середини 80-х років, продавці комп'ютерних систем та баз даних почали проводити оцінку систем, що базується на системі тестів TP1 (TP – ймовірно, абревіатура Test of Performance).
Фірма IBM, в "надрах" якої була розроблена система тестів TP1, зробила цю систему загальнодоступною. Тести, включені до складу TP1, мали на меті визначити продуктивність систем, що займаються обробкою транзакцій, що виробляються банкоматами. Можливості цієї системи були дещо обмежені. Перевірявся лише пакетний режим проведення транзакцій, вплив на банкомат з боку користувача чи інших комп'ютерів мережі було виключено. Ця система тестів мала дві недоліки. По-перше, виняток із тестів зовнішніх впливів могло призвести до отримання невірних результатів. По-друге, умови проведення тестів не були визначені, що також не могло не вплинути на точність результатів. Зрештою, не існувало контролю над проведенням та інтерпретацією результатів тестування. Результатом стало те, що довіра до цієї системи була досить низькою. Ситуацію посилив ще й той факт, що найчастіше системи, продуктивність яких була неправильно оцінена завдяки неправильним тестам (тестам, проведеним у неправильних умовах), починали мати успіх на ринку. Звичайно, цей факт не міг не засмутити чесних виробників та торговців системами автоматизації.
По-перше, Грейзапропонував не обмежуватися оцінкою лише продуктивності системи, а й оцінювати загальну вартість експлуатації системи. Цю загальну вартість він запропонував розраховувати не лише як сукупну вартість апаратного та програмного забезпечення, а й враховувати вартість підтримки системи у працездатному стані протягом п'яти років. Досі при оцінці систем вартість її обслуговування не враховувалася.
По-друге, запропонований тест мав визначати продуктивність системи лише на рівні функціональних вимог. До цього моменту при тестуванні різних систем використовувалися лише порівняльні тести, тобто визначалося, як поведеться той чи інший тест на комп'ютері певної конфігурації, з певною операційною системою, з певними установками. Таке нововведення дозволило б визначати загальну продуктивність системи незалежно від використовуваного «заліза» та «софту».
По-третє, при оцінці продуктивності системи було запропоновано враховувати, окрім інших, і масштаб системи, а не лише швидкість обробки транзакцій. Зрозуміло, збільшення числа користувачів системи зменшує продуктивність кожного термінала. Крім того, збільшення розміру бази даних також призводить до зниження швидкості роботи. На загальну продуктивність системи можуть, наприклад, вплинути і розміри log-файлів. Раніше ці та їм подібні характеристики при оцінці продуктивності системи не враховувалися.
По-четверте, вперше було запропоновано запровадити обмеження щодо часу обробки транзакцій. Зокрема, у системі тестів «Дебет-кредит» 95% усіх транзакцій мали завершити протягом однієї секунди. Це пред'являло не так кількісні, скільки якісні вимоги до роботи системи. Тестована система повинна була працюватитак, щоб користувач (суб'єктивно, звичайно) не помічав затримок у її роботі. Досі таких обмежень не вводив ніхто.
У цій ситуації природним виходом було створення добрих тестів продуктивності, що видають достовірні результати. На результатах хороших тестів можна побудувати чесну конкуренцію. Однак будь-якому більш-менш пов'язаному з обчислювальною технікою людині очевидно, що результати тестів можуть бути трактовані неоднозначно. Тому, крім створення тестів, необхідно було забезпечити правильність тлумачення результатів тестів і запобігти будь-яким можливостям неправильної інтерпретації результатів. Як загальна ситуація зі спробами будь-якого ранжирування систем з їхньої продуктивності, так і необхідність створення «зв'язки» «тести/система інтерпретації результатів тестів» призвели до виникнення TPC – поради щодо продуктивності обробки транзакцій (Transaction Processing Performance Council).
TPC був створений для того, щоб спостерігати не лише за правильністю проведення тестів, а й за тим, як інтерпретуються результати цих тестів. Таким чином, основними завданнями TPC були:
розробка процедур інтерпретації результатів проведених тестів;
ведення спостереження за правильністю проведення тестів;
облік результатів проведених тестів.
вимога виконання 95% транзакцій протягом однієї секунди було замінено на вимогу виконання 90% транзакцій протягом двох секунд;
число емульованих терміналів було обмежено десятьма;
вартість терміналу включалася до загальної вартості системи;
системи могли працювати як у локальних (LAN), так і в глобальних (WAN) мережах (у статті Джима Грея йшлося лише про роботу у WAN);
вимоги в цілому до системи були жорсткішими такимчином, щоб за загальну продуктивність системи не можна було прийняти її продуктивність у «пікових» умовах;
щодо загальної вартості володіння вартості апаратних засобів і програмного забезпечення додавалася вартість обслуговування системи за п'ять років, а й за три роки.
Перший результат проходження TPC-А дорівнював 33 tpsA (транзакцій за секунду при проходженні тесту TPC-А) за вартістю транзакції 25500 доларів. Найкращий результат, отриманий під час проходження цієї серії тестів, становив 3692 tpsA за вартістю транзакції 4873 долари. Підвищення швидкості у 111 разів та зниження вартості у п'ять разів відбулося за рахунок:
неоптимальності перших версій тестів;
покращення якості та швидкості роботи «заліза» та «софту»;
виправлення помилок та видалення «вузьких місць» із програм, що вже пройшли тести;
виробники «грали» з тестами, дізнаючись один від одного про вимоги і «підганяючи» систему тільки для проходження тесту.
Як би там не було, але не можна не помітити, що багато в чому завдяки правильно побудованій системі тестування (тобто сукупності системи тестів і правил інтерпретації результатів тестів) системи обробки транзакцій зробили величезний крок вперед з точки зору продуктивності. Інакше кажучи, саме система тестування впливала підвищення якості.