CftClub.ru
Клуб специалистов ЦФТ-Банк

Что ограничивает быстродействие ERP систем, I часть

 
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Новости и публикации
Предыдущая тема :: Следующая тема  
Автор Сообщение
Alquimista
Участник


Вступление в Клуб: 25.06.2007
СообщениеВт Авг 21, 2007 14:29   Что ограничивает быстродействие ERP систем, I часть Ответить с цитатой

Мартынов Дмитрий, Мольков Вячеслав

Что ограничивает быстродействие ERP систем, I часть

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

Почему тормозят многие ERP?

Неужто прогресс компьютерных технологий отстает от запросов бизнеса?
Нет уж, поверьте ветеранам автоматизации – шустро обрабатывать данные в тех объемах, которые вам нужны (даже если у вас крупная сеть розничных магазинов) умели и персоналки десятилетней давности.

А почему тогда все так медленно?

Многие пугаются даже самой постановки вопроса. ERP-системы представляются людям, не связанным с ИТ, сложными монстрами, которыми управляют шустрые программисты и ИТ-консультанты, сами до конца не ведающие, каким образом устроена их система. Хуже то, - многие консультанты и программисты, знающие определенные части ERP, имеют свое представление о ERP в целом. В таком контексте вопрос о том, по каким причинам система все-таки "тормозит", кажется сложным и требующим отдельной комиссии для каждого случая.

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

Начнем с очевидных:

Сети

Сложность диагностики: сложно определить, где именно застревает пакет при движении от одного компьютера к другому.
Решение: изменение топологии сети, сегментирование сети.

"Если бы Эдисону необходимо было найти иголку в стоге сена, он … начал бы осматривать соломинку за соломинкой,
пока не отыскал бы искомое".
Никола Тесла


Низкая скорость сети влияет на возможность работы с данными на удаленном компьютере. Особенно это заметно, если вы работаете с Интернетом через обычную модемную связь. Но, бывает, что и в корпоративных сетях возникают проблемы. Эти проблемы становятся ощутимыми в территориально-распределенных сетях от 100 компьютеров. Чаще всего причина кроется в неправильной топологии (структуре) сети. Есть два ключевых компонента топологии: коммутаторы (switch) и концентраторы (hub). Концентратор - это простое устройство, быстро рассылающее пришедший пакет на все подключенные к нему компьютеры (не только туда куда нужно). Иными словами, пакет данных широковещательно размножается. При неправильном использовании концентраторов мы получим сеть с множеством лишних пакетов. Каждый компьютер сети затратит немало времени на их фильтрацию. Современный коммутатор(switch), наоборот, умный, и тратит свое заметное время на обработку пакета и маршрутизацию: отправляет его только нужному адресату. При неправильном использовании коммутаторов мы получим значительную задержку во времени при доставке пакета на нужный компьютер.

Кроме упомянутой тонкости, бывают и другие проблемы в сетях, связанные с разбиением сети на сегменты, например, с выбором оборудования и сетевого ПО.

Зоопарк систем

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

"Электроника- это наука о контактах: или их нет там, где они должны быть, или они есть там, где их не должно быть" .
Студенческий фольклор.


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

Выход прост: рекомендуется вводить корпоративные стандарты на оборудование и ПО. Так же рекомендуется использовать активное сетевое оборудование от одного производителя, причем оборудование должно быть рассчитано на работу в сетях соответствующего размера. На сайте выбранного вами производителя обычно есть вся необходимая информация.

Оперативная память

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

Непомерное увлечение ИТ-специалистами райд-массивами, большим дисковым пространством и прочими специальными инструментами хранения данных, повлияли на перекос использования систем в пользу использования жестких дисков против наращивания оперативной памяти.

Современные дисковые системы выгодно отличаются от своих более молодых собратьев, однако они работают даже медленнее, чем оперативная память десятилетней давности. Дело в том, что оперативная память работает со скоростью электрического взаимодействия, т.е. со скоростью света, с поправкой на сложность электрической схемы процессора. А дисковый накопитель работает со скоростью вращения диска.

Конечно, современный жесткий диск всегда имеет Кеш-память, которая, по сути, является кусочком оперативной памяти накопителя. Но этот кусочек мал и предназначен для хранения последних считанных данных или наиболее часто считываемых данных. Большая потеря времени в жестких дисках происходит еще на процессе передвижении головки с одной дорожки на другую. И в этот момент разница по скорости в сравнении с оперативной памятью может достигать 106 раз.

В случае если приложению не хватает оперативной памяти, оно начинает записывать информацию на диск, и потом считывает ее обратно и так далее. В этот момент и происходит видимое временное зависание. Это заметно даже на персоналках, при работе в нескольких программах одновременно. Но если говорить про ERP-приложения, то увеличение количества оперативной памяти больше 2-х Gb имеет смысл только для сервера СУБД.


Структуры и хранилища данных

Сложность исправления: если в системе уже есть данные, то изменение - это длительная операция, которая возможна только при остановке системы.
Решение: возможно, что тяжелый запрос к СУБД – "SELECT" можно заменить более легким или разложить на два подзапроса. Если же необходимо изменение структуры данных, то, чем раньше будут сделаны изменения, тем легче их будет выполнить.

"Если говорить прямо, то практически весь SQL базируется на единственном
краеугольном камне, а именно - операторе "SELECT"
PL/SQL в Oracle


Данные ERP-систем в отличие от данных в Интернете структурированы и жестко взаимосвязаны. Они хранятся в таблицах. Основным оператором при программировании разработчиком запросов SQL для получения данных из таблиц является оператор "Select". Но именно он часто и является источником торможения многих систем. На скорость его работы может заметное влиять накопленный объем данных.

Упрощенно оператор "Select" - это перемножение матриц (выборок из различных таблиц). Действие этого оператора зачастую плохо оптимизируются. В увеличении быстродействия помогают индексы, правильный выбор таблиц и их взаимосвязи. Неправильное использование "Select" при критической массе данных приводит к перемножению больших таблиц данных (например, 10`000`000x10`000`000 записей и больше. Но в современном мире уже существует единичные суперкомпьютеры, которые умеют делать такую операцию мгновенно, а типовые, даже дорогие сервера, на этом тормозят). Современные ERP могут содержать много SQL-кода, и среди прочих правильных "Select" нередко встречаются неправильные (непродуманные или не оптимизированные разработчиком) системы. Опытные специалисты хорошо знают эти места и заранее при настройке системы ищут способы их обхода. Но, как упоминалось в статье " Проблемы быстродействия ERP" интеграторы не любят специалистов с таким опытом.

Индексы тут - не панацея. Эффективность использования индексов в "Select" по нескольким таблицам заметно падает в отличие от работы с одной таблицей.

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

Тут уместно сказать, что для разработчика, существует и другие решения оптимизации - методы увеличения таблиц - с заранее вычисляемыми значениями. То есть на этапе внесения данных заранее формируются необходимые в дальнейшем наборы/срезы расчетных данных в дополнительных таблицах. Хотя в редких случаях это увеличивает длительность транзакций, но может приводить к "блокировкам". Об этом продолжим в следующей части.

© www.erpnews.ru

>> Что ограничивает быстродействие ERP систем, II часть
Показать сообщения:   
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Новости и публикации Часовой пояс: GMT + 3
Страница 1 из 1

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Рейтинг@Mail.ru