Неудачно разработанные приложения

Оценить
(0 голоса)

Воздействие неудачно разработанного приложения на производительность может быть поистине удивительным. В крайних случаях производительность может значительно ухудшиться.

Однажды на сайте одного из клиентов для испытания нового приложения под нагрузкой использовался эмулятор дистанционного терминала. При небольшом количестве пользователей система "вела себя" как обычно, но стоило лишь увеличиться нагрузке, как время отклика резко возросло, а производительность замедлилась до полного останова.

В конечном счете удалось обнаружить причину этой проблемы после того, как было зафиксировано большое количество системных вызовов fork. Приложение протоколировало каждую транзакцию БД; в журнале фиксировались временная метка и номер терминала (tty), с которого подключался пользователь.

Разработчик, который составил функцию протоколирования транзакций, знал только один способ идентификации имени терминала: программа tty операционной системы UNIX. Таким образом в рамках своей программы, написанной на языке программирования С, этот разработчик использовал функцию system(3C) для того, чтобы выполнить программу tty и перенаправить ее вывод во временный файл. После этого он открывал этот файл, считывал строку tty и закрывал файл. В конце он удалял временный файл, для чего еще раз использовалась функция system, и применял программу rm, поскольку этот разработчик не знал другого лучшего способа для удаления файла по инициативе программы на языке С (например. unlink(2)).

Следовательно, каждая транзакция БД требовала двух вызовов функций system, что приводило каждый раз к затратным операциям fork и ехес(2). Объем программы составлял приблизительно 60 строк.

Мы заменяли эти 60 строк программного кода двумя строками, воспользовавшись функцией ttyname (ЗС) и устранив тем самым оба вызова функции system. Как только приложение было перекомпилировано и развернуто, система стала нормально вести себя под нагрузкой.

Этот пример иллюстрирует потенциальные возможности неудачно написанных приложений, способных поставить вашу систему на колени. Из него также становится очевидным значение испытания приложений "под нагрузкой" перед их передачей в эксплуатацию. Если речь идет о разработке своих собственных приложений, настоятельно рекомендуется использовать эмулятор дистанционного терминала или браузера. чтобы проверять эти приложения на всех стадиях разработки и гарантировать, что необходимый уровень производительности достигнут. Web-сайт настоящей книги содержит Hands-Off Remote Terminal Emulator - автоматический эмулятор дистанционного терминала.

К сожалению, в действительности дело обстоит так, что в то время как функциональные возможности прикладных программ тестируются разработчиками, произво-

дительность приложений часто остается непроверенной даже для некоторых важных пакетов прикладных программ. В результате проблемы производительности иногда обнаруживаются только тогда, когда приложение уже внедрено.

Плохо написанные операторы SQL представляют собой другую потенциальную "черную дыру" с точки зрения производительности. Иногда можно видеть, что консультанты по языку SQL привлекаются для достижения хорошего результата еще на стадии планирования разработки прикладного программного обеспечения. В идеальном мире оптимизаторы БД способны найти эффективные способы "доведения до ума" даже плохо запрограммированных SQL-программ. Это конечная цель, однако, мы пока что не достигли ее.

Неудачный проект БД и его воплощение
Проблемы с пользовательским окружением
Неудачное размещение данных
Распространенные проблемы в средах серверов БД
Выявление проблем производительности

Добавить комментарий


Защитный код
Обновить