Печать

     Многие в процессе работы сталкивались с неудовлетворительной скоростью работы решений на платформе 1С:Предприятие 8. Сегодня мы рассмотрим некоторые вопросы производительности продуктов на примере конфигурации 1С-КАМИН:Зарплата. Версия 5.0. Примерно такие же результаты можно получить для других продуктов на платформе 1С:Предприятие 8. Статья ориентирована на технических специалистов, которые ранее не работали (или мало работали) с 1С.

     Для начала рассмотрим случай, когда с базой работает 1 человек, который сидит за своим отдельным компьютером, где и расположена информационная база. Для первой серии тестов возьмём относительно старый компьютер с процессором Athlon X2 255 (индекс производительности cpubenchmark.net (далее ИП) 1842) и проверим, как влияет на скорость выполнения операций объём оперативной памяти.

 

  Старт Отчёт Проведение Выгрузка
Athlon X2 255, DDR3 2Gb, HDD 53 72 247 181
Athlon X2 255, DDR3 4Gb, HDD 23 39 161 140
Athlon X2 255, DDR3 8Gb, HDD 23 37 164 125

    

     Очевидно, что 2 Гб памяти нам явно недостаточно, при этом, увеличение до 8 Гб не принесло ощутимого прироста производительности. Тесты мы проводили в «тепличных» условиях — на компьютере не было запущено ничего лишнего. Только для операционной системы Windows 10x64, на которой проводился тест, «ничего лишнего» — это когда примерно 1.3 Гб оперативной памяти используется системой. При таких условиях, платформа 1С, которая при отсутствии дефицита памяти легко «отъедает» более гигабайта, начинает активно использовать файл подкачки, нагружая дисковую систему. В реальных условиях редко встречаются случаи, когда компьютер используется только для 1С. Браузер с десятком страниц легко «съест» ещё гигабайт, а средства общения, офисные программы, специфические драйверы и антивирус – второй. В последнее время тенденции к уменьшению расхода памяти приложениями нет. Поэтому будем считать, что для комфортной работы необходимо, как минимум, 4 Гб оперативной памяти. 

     В процессе тестирования можно увидеть, что кроме активного использования процессора, нагрузка ложится на дисковую систему. Попробуем её ускорить, переместив базу данных и кэш платформы 1С на SSD диск.

  Старт  Отчёт Проведение Выгрузка
Athlon X2 255, DDR3 4Gb, HDD 23 39 161 140
Athlon X2 255, DDR3 4Gb, SSD 23 31 122 47

 

     Помогло? Да. Но в нашем опытном стенде «узким местом» является относительно слабый процессор, поэтому результат есть, но особо не впечатляет. Поэтому возьмём более новые компьютеры с процессорами Pentium G840 (ИП 2590) и Intel Core i7-3770K (ИП 9563) на борту.

  Старт Отчёт Проведение Выгрузка
Athlon X2 255, DDR3 4Gb, SSD 23 31 122 47
PentiumG840, DDR3 4Gb, SSD 20 26 105 40
Core i7 3770K, DDR3 32Gb, SSD 14 18  65 25

 

     Как видим, скорость операций растёт по мере увеличения производительности процессора, но растёт не линейно. На мой взгляд, оптимальным будет выбор между Pentium G и Core i7, т.к. цена Core i7 довольно высока (в данный момент цена процессоров серии Pentium G начинается от 3 500р., а Core i7 от 28 000р.). Диск SSD желателен, но нужно помнить, что он имеет ограниченный ресурс и, в некоторых случаях, внезапно смертен. Восстановить данные с вышедшего из строя диска SSD на порядок сложнее, а иногда вообще не возможно. Поэтому не забываем про резервные копии на другие независимые носители. Цены на SSD тоже довольно гуманные, 120 Гб от известной фирмы начинаются от 3 500 р. и продолжают снижаться, а ресурса вполне хватит лет на 5.

     Общие выводы для максимально комфортной монопольной работы в базе 1 пользователя:

1.      Чем производительнее процессор, тем лучше. Оптимальным вариантом (цена/производительность) является cерия Pentium G/Core i3/Core i5.

2.      Память минимум 4 Гб.

3.      Наличие SSD диска.

     Если с одним пользователем обычно не бывает проблем с производительностью, то, при одновременной работе нескольких человек в базе, эти проблемы как раз проявляются. Самым простым и дешёвым способом работы нескольких пользователей в базе данных является размещение её в папке локальной сети, к которой имеют доступ все пользователи. Измеряем следующим образом:

1.      Проводим тест монопольно с базой данных, находящейся в локальной сети.

2.      Добавляем пользователей, которые бездействуют в базе и проводим тест (пассивный пользователь или ПП).

3.      Имитируем бурную деятельность прочих пользователей, запуская массовое проведение документов, и снова проводим тест (активный пользователь или АП).

     В итоге получаем интересные результаты. Даже один пассивный пользователь (просто «висящий» в базе) замедляет работу прочих, хотя и не критично. А четыре дополнительных активных пользователя могут замедлить скорость операций более, чем на порядок. Обратите внимание, что при активной работе множества пользователей производительность компьютера, за которым производится тестирование, всё меньше влияет на результат. Очевидно, что в этой схеме «узким местом» является локальная сеть, а именно скорость доступа к информационной базе. И что-то сделать с этим довольно проблематично. 

     Что же делать, если работать хочется всем вместе и без «тормозов»? Вариантов решения два – сервер терминалов и сервер 1С:Предприятия. В терминальном режиме все операции фактически происходят на отдельном сервере, а на компьютерах пользователей происходит только отрисовка наших действий. Главное преимущество – крайне низкие требования к компьютеру пользователя. Подойдёт любой компьютер, который сможет запустить программу для подключения к серверу терминалов или вообще тонкий клиент. Недостаток –  нужна большая производительность. Примерно конфигурацию сервера можно рассчитать следующим образом: процессор – 1 ядро процессора на 4 пользователей, память – 2 Гб на операционную систему + 1Гб для 1 пользователя. 

     Общие выводы для многопользовательского файлового варианта работы:

1.      При увеличении пользователей, одновременно работающих с базой, значительно снижается скорость проведения операций. (Обычно более-менее терпимо сразу могут работать менее 5 пользователей).

2.      Производительность клиентских компьютеров слабо влияет на скорость выполнения операций при большом количестве одновременно работающих пользователей.

3.      Для снижения потери производительности можно использовать сервер терминалов (актуально для 5-20 пользователей). Максимальное количество пользователей, работающих с файловой базой, которое я видел своими глазами – 22. И в том случае имелись проблемы из-за большого объёма файла базы данных.

     А теперь посмотрим на сервер 1С:Предприятие, который установим на тот же сервер с Core i7 3770K и протестируем работу непосредственно с него же, а так же со всех предыдущих компьютеров, участвовавших в тесте. В качестве СУБД будет использован Microsoft SQL Server 2012 установленный там же.

  Старт Отчёт Проведение Выгрузка
Core i7 3770K, DDR3 32Gb, SSD        
Монопольно

14

10 119 44
+1ПП 13 7 112  
+4ПП 13 7 112  
+1АП 14 7 110  
+4АП 15 7 120  
G840, DDR3 4Gb, SSD        
Монопольно 12 8 113 51
+1ПП 12 7 112  
+4ПП 12 7 114  
+1АП 12 7 113  
+4АП 12 7 116  
Athlon X2 255, DDR3 4Gb, HDD        
Монопольно 13 7 114 61
 +1ПП 14 7 119  
 +4ПП 13 7 114  
+1АП 13 8 113  
 +4АП 14 7 117  

 

     Тоже интересный результат. На что следует обратить внимание:

1.      Производительность некоторых операций для одного пользователя в клиент-серверном режиме ниже, чем для того же пользователя в файловом режиме.

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

3.      От «железа» клиентских компьютеров опять мало чего зависит, т.к. практически все вычисления происходят на сервере. Особо это заметно на конфигурациях, предназначенных для работы в режиме управляемого приложения.

4.      Интересный момент – отчёт при первом измерении строился 10, при последующих 7-8, даже при возрастающей нагрузке. Вызвано тем, что SQL сервер кэширует часто вызываемые запросы и в дальнейшем исполняет их быстрее.

Александр Илясов, руководитель технического отдела

185 в помощь сисадмину