Тестирование скорости перепроведения документов 1С 8.2 на разных связках windows и SQL серверов 1С УПП 1.3

09.06.16

При внедрении УПП сталкнулся с проблемой медленного (по мнению участников проекта) перепроведения документов. Решил протестировать перепроведение документов за одинаковый промежуток времени на разных связках windows и SQL серверов.

Исходные:

1С:Предприятие 8.2 (8.2.14.533)

1С:Управление строительной организацией, редакция 1.3 (1.3.12.4),

документы за 4 года.

Для теста выбраны первые 2 месяца, всего 346 докумнтов (платежные поручения, поступления товаров и услуг, реализация товаров и услуг).

Контрольный замер производительности:

Процессор E5335 2,00GHz шина 1333 4 проца (контрольный замер)

W2K8R2 + SQL2008R2 - 20 минут проц. E5335 2,00GHz шина 1333 4 проца

Процессор E5320 1,86 шина 1000 4 проца

1 W2K8R2 + SQL2008R2 31 мин

2 W2K8R2 + SQL2008 33 мин

3 W2K8R2 + SQL2005 35 мин

4 W2K8R2 + SQL2005 снят режим совместимости 8.2.13 и очищен регистр версий и отключено версинирование 37 мин

5 W2K8R2 + SQL2005 1С 8.2 переустановлена на диск на хранилище (не на диск С:) 31 мин

6 W2k3 + SQL2008R2 30 минут

Процессор X5450 3.00 шина 1333 4 проца

7 W2k8R2 + SQL2008R2 17 мин

Процессор X5450 3.00 шина 1333 8 проца

8 W2k8R2 + SQL2008R2 17 мин

Процессор X5650 2,66 шина 1333 4 проца, память DDR3 шина 800MHz 32Gb

W2K8R2Std SQL2008R2 11 мин

Таким образом, исходя из выше продставленных тестов, можно сделать вывод что:

На скорость перепроведения документов, при одинаковых условиях по железу, разные вырианты компановки операционной системы и SQL сервера большой разницы не имеют. В большинстве случаев несмотря на "тяжеловесность" SQL 2008 R2 именно связка W2k8R2 + SQL2008R2 дает максимальную производительность (хоть и не существенную по приросту). При равных условиях по связке ОС + SQL Сервер на производительность влияет исключительно производная частоты процессора на частоту шины. Существенного пользования ресурсами дисковой подстстемы не обнаружено (3.5 МB в рандоме).

SQL

+69 –

См. также

Поиск и анализ длительных вызовов - CALL, SCALL

HighLoad оптимизация Технологический журнал Системный администратор Программист Бесплатно (free)

Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.

24.06.2024 5141 ivanov660 12

Что не так с методом ЗаполнитьЗначенияСвойств

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.

06.06.2024 9260 Evg-Lylyk 61

[Замер] Кто самый быстрый в конфигураторе?

HighLoad оптимизация Механизмы платформы 1С Системный администратор Программист Стажер Платформа 1С v8.3 Бесплатно (free)

Сравним «Регистры сведений» с «Сервисами интеграции» и узнаем, кто быстрее!

28.03.2024 5006 dsdred 23

Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024 5097 spyke 28

Быстродействие типовой 1С

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024 7573 vasilev2015 20

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих запросов на sql, ожиданий, конвертация запроса в 1С и рекомендации, где может тормозить.

2 стартмани

15.02.2024 12422 241 ZAOSTG 80

115

Переход на Clickhouse для анализа метрик

HighLoad оптимизация Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Принимать, хранить и анализировать показания счетчиков (метрики) в базе 1С? Почему бы нет? Но это решение быстро привело к проблемам с производительностью при попытках построить какую-то более-менее сложную аналитику. Переход на PostgresSQL только временно решил проблему, т.к. количество записей уже исчислялось десятками миллионов и что-то сложное вычислить на таких объемах за разумное время становилось все сложнее. Кое-что уже практически невозможно. А что будет с производительностью через пару лет - представить страшно. Надо что-то предпринимать! В этой статье поделюсь своим первым опытом применения СУБД Clickhouse от Яндекс. Как работает, что может, как на нее планирую (если планирую) переходить, сравнение скорости работы, оценка производительности через пару лет, пример работы из 1С. Все это приправлено текстами запросов, кодом, алгоритмами выполненных действий и преподнесено вам для ознакомления в этой статье.

1 стартмани

24.01.2024 5669 glassman 18

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024 14018 doom2good 49

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. fishca 1259 08.09.11 13:18 Сейчас в теме

Лучше измерять производительность с помощью многопользовательских тестов. При перепроведении 4 проца ты не сможешь задействовать.

2. pulpik 106 08.09.11 13:50 Сейчас в теме

то что производительность измеряется при многопользовательских тестов я знаю. спасибо за напоминание. Однако, так как при перепроведении все системные ресурсы были заняты на незначительный показатель я подумал что все из-за неправильного подбора связки, после чего я попробовал протестировать именно изменение поведения базы из-за связки Windows + SQL server.

3. fishca 1259 08.09.11 13:55 Сейчас в теме

перепроведении все системные ресурсы были заняты на незначительный показатель

Можно перечислить системные ресурсы которые были заняты на этот самый незначительный показатель. Что-то мне подсказывает, что процессор вваливал на все 100% при перепроведении. Или процессор это не системный ресурс?

4. Aragorn 08.09.11 13:56 Сейчас в теме

все конечно интересно, автору респект за проведенную работу. Но все же не надо упирать на связки Win+SQL, а рассматривать проблемы кода и настройки самой sql

5. fishca 1259 08.09.11 14:01 Сейчас в теме

(4)да, ждем статьи на тему Тестирование скорости перепроведения документов 1С 8.2 на разных связках Linux и SQL серверов 1С УПП 1.3 ;)

6. cool.vlad4 2 08.09.11 14:53 Сейчас в теме

Неужели что-то интересное после новшеств на сайте ;) Спс.

7. Ёпрст 1065 08.09.11 14:57 Сейчас в теме

Снеговик мегатормоз.. это полный ПЭ.
20 минут на 300 доков..жесть.

8. fishca 1259 08.09.11 15:06 Сейчас в теме

(7)это не снеговик, а УПП, а может и то и другое. Насколько я знаю еще никто адекватного сравнения не делал клюшек и снеговика на предмет сравнения производительности, или я ошибаюсь?

9. Арчибальд 2709 08.09.11 15:11 Сейчас в теме

(8) Никто не делал, но оно и так заметно. Рюшечки 8 небесплатны.

10. fishca 1259 08.09.11 15:14 Сейчас в теме

(9) за все, к сожалению, приходится чем-то расплачиваться, такова се-ля-ва :)

11. LeaNaeD 08.09.11 16:22 Сейчас в теме

Самый смак был бы сравнить с файловым вариантом работы. А хотя бы создать новую базу с данными за год, например, или сколько там ваша база в файловом вприанте потянет. И ту же базу в этих ваших серверных связках. От это было бы интересно посмотреть.

12. fishca 1259 08.09.11 16:28 Сейчас в теме

(11) файловая база на одном пользователе выиграет, если база будет расположена локально на том же компе :).

14. pulpik 106 08.09.11 16:33 Сейчас в теме

1.
LeaNaeD 08.09.11 16:22 Ссылка Цитата Ник
Самый смак был бы сравнить с файловым вариантом работы. А хотя бы создать новую базу с данными за год, например, или сколько там ваша база в файловом вприанте потянет. И ту же базу в этих ваших серверных связках. От это было бы интересно посмотреть.
Ответили: (12)
[+] [−]

этот вариант не рассматриваю так как планируемый размер базы от 20 гигов

19. LeaNaeD 08.09.11 17:15 Сейчас в теме

(14)

этот вариант не рассматриваю так как планируемый размер базы от 20 гигов

Очень жаль, далеко не все фирмы могут себе позволить полляма-лям на переход на скл-версию. См. (18)

21. fishca 1259 08.09.11 17:18 Сейчас в теме

(19) скули бывают разные ;) можно и постгрес попробовать

18. LeaNaeD 08.09.11 17:13 Сейчас в теме

(12)

У нас файловый вариант с эдак 50-60 одновременно работающих юзверей. Работает достаточно шустро за счет следующего:
1) 2 4х-ядерника
2)SSD или даже рейд-массив из SSD
3) База периодически будет обрезаться (раз в год-да), в этом году уже обрезали.
4) Ну и несколько хинтов, навроде переделки ролей пользователей (стандартная роль "Пользователь" ОЧЕНЬ сильно тормозила работу всех юзверей без полных прав, поначалу даже не подозревал, что дело в ней. Другие роли переделал с отключением ограничений доступа к данным по чтению, оставил только на запись + контроль на запись по складам; ограничения на чтение нехило тормозило работу. А вот роль "Пользователь" ушами-то и прохлопал поначалу), переделка универсального отчета на бОльшее быстродействие, взятая с этого сайта. ну и может еще что-то.

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

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

Кто может подскажет полезную статью по такой теме?

20. fishca 1259 08.09.11 17:18 Сейчас в теме

(18)
1. в терминалке сидите?
2. размер базы какой?
переход на SQL версию прироста производительности не даст, он обеспечивает только более высокую надежность хранения данных.

22. LeaNaeD 08.09.11 17:24 Сейчас в теме

(20)

Да, все сидят в терминале, забыл это упомянуть. База 4,5 где-то, в прошлом году было примерно под 6 (это за полтора-два года работы, но тогда и пользователей было гораздо меньше). Так что где-то раз в год в принципе можно успеть обрезать. Да, был еще хинт. У номенклатуры фирмы (очковые и контактные линзы) есть такая неприятная особенность, как огроменный ассортимент: миллионы, десятки миллионов характеристик номенклатуры. Тут файловая база трещала по швам, но тут тоже сделали хинт ушами, хотя по бОльшей части смахивает на костыль.

(21)

Стандартный ответ - фуфу, это же бесплатное поделие, то ли дело православный MS SQL, такие-то мощщи. Ну и все в таком же духе.

25. alexk-is 6544 08.09.11 18:38 Сейчас в теме

(20)

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

Не правда. Так было в 7.7. В 8.х всё иначе. Прирост производительности есть и очень значительный даже при 1 пользователе и особенно при использовании RLS.

Когда у нас база стала останавливаться, то поставили на рабочую станцию с XP 1С:Сервер и IBM DB2. Технические данные у машинки простенькие: RAM 2 Gb, HDD 200 Gb. Без наворотов. Одно рабочее место. РИБ. После перевода на SQL база сразу залетала.

26. romansun 194 08.09.11 19:14 Сейчас в теме

(25)
дополню, что в случае нагруженных пользователями и данными баз и тяжелых отчетов только SQL и работает. Файловые версии тупо не работают даже в виде тестовых у программера - просто тупо зависают или пишут про недостаток памяти.

Прирост особенно заметен при использовании настоящих серверов. При использовании обычных тачек даже есть вероятность ухудшения скорости (к примеру, медленнее грузится выгрузка).

По статье и скорости проведения доков - очень большое значение имеет количество памяти и особенно скорость винтов. Мне кажется, даже более, чем сам проц.
И еще - при проведении доков поставьте замер производительности в 1С, тут, имхо, самое интересное это, ибо 300 доков за 20 минут - это, да, жесть :D

LeaNaeD пишет:
Очень жаль, далеко не все фирмы могут себе позволить полляма-лям на переход на скл-версию. См. (18)

а почему полляма - лям? какой примерно расклад по ценам получается?

Но вообще, когда 50-60 одновременно, значит всего в базе зарегено сотня минимум наверное. Это же уже не пивной ларёк - солидная контора, солидная база, много важной инфы

27. LeaNaeD 08.09.11 19:40 Сейчас в теме

(26)
1) 1С:Предприятие 8+MS SQL Server Standard 2008. Клиентская лицензия на 50 рабочих мест 401 800 руб.
2) 1С:Предприятие 8+MS SQL Server Standard 2008. Клиентская лицензия на 10 рабочих мест 82 600 руб.
3) 1С:Предприятие 8.2. Лицензия на сервер(x86-64)+MS SQL Server Standard 2008. Лицензия на 1 процессор 272 000 руб (умножать надо бы эдак на 4-8)

Может еще и отдельный ключ на сервер 1С-Прдприятия нужен? Тогда еще сотенку, после предыдущих карман не отяжелит!

4) 1С:Предприятие 8.2. Лицензия на сервер (x86-64) 72 000 руб
5) собственно сам компьютер-сервер скл, еще 50-100 тыр
6) Возможно дадут скидку при обмене старых ключей, мобыть сотенку и скинут

Короче, дело - табак. Контора мобыть и солидная, но не московская, так что сам понимаешь. Лямы за воздух тратить далеко не каждый себе позволит, тем более, что и так нормально работает. Особенно в свете предыдущих трат на ключи защиты, лицензии за терминальные подключения, лиценции за ms office на кучу юзверей и прочее, прочее.

31. a-novoselov 1158 09.09.11 09:30 Сейчас в теме

(18) Файловый вариант в любом случае будет быстрее серверного работать (по крайней мере при измененнии данных), из-за отсутствия двух промежуточных звеньев между клиентом и базой данных. Т.е. файловый: клиент -> БД, серверный: клиент -> сервер предприятия 1С -> SQL сервер -> БД.
При чтении одновременно с несколких таблиц (отчет по 5-6 регистрам, отчет поверх которого RLS накладывается...) SQL даст фору файловому варианту при повторном обращении, из-за оптимизации плана запроса и других внутренних механизмов SQL сервера по улучшению производительности. Плюс кеширование данных сервером 1С при многопользовательском режиме.
Другое дело, что файловый вариант просто не потянет базу больше 50, тем более 100 ГБ. Да и база в 20 ГБ тупо не развернется в файловом варианте, если хотя бы одна таблица превышает размер в 4 ГБ (например тот же регистр ВерсииОбъектов при включенном версионировании всех объектов легко перевалит за такой размер).

34. echo77 1906 09.09.11 13:13 Сейчас в теме

(31) Я не хочу здесь спорить про то что быстрее файловый вариант или серверный. Но по своему опыту скажу, что многопользовательский файловый вариант(не терминал) с включенным RLS намного тормознее серверного. И не зря в некоторых решениях пишут, что включение ограничения на уровне записей не рекомендуется для баз в файловом варианте.

37. a-novoselov 1158 14.09.11 15:06 Сейчас в теме

(31) Файловый вариант "не терминал" тормозить будет намного сильнее терминального, там большие потери идут на сеть. Попробуйте файлы базы данных SQL сервера (собственно саму базу) расположить не на самом SQL сервере, а на шаре другого компютера в сети, у вас и серверный вариант тормозить начнет.

13. pulpik 106 08.09.11 16:32 Сейчас в теме

fishca 08.09.11 13:55 Ссылка Цитата Ник
Цитата
перепроведении все системные ресурсы были заняты на незначительный показатель

Можно перечислить системные ресурсы которые были заняты на этот самый незначительный показатель. Что-то мне подсказывает, что процессор вваливал на все 100% при перепроведении. Или процессор это не системный ресурс?
[+] [−]

Процессор 18-25%
Оперативная память по нарастанию (при базе в 6 гигов) от 2 до 4 гигов
Дисковый массив Raid10 - 6 дисков Iscsi - максимум 3,5 MB/Sec рывками при перескокое на след документ (похоже запись по регистра) между этои по нулям.

15. fishca 1259 08.09.11 16:36 Сейчас в теме

Процессор 18-25%

- при 4 процессорах это и есть загрузка под 100%, что и следовало ожидать.

16. pulpik 106 08.09.11 16:45 Сейчас в теме

fishca 08.09.11 16:36 Ссылка Цитата Ник
Цитата
Процессор 18-25%
- при 4 процессорах это и есть загрузка под 100%, что и следовало ожидать.
[+] [−]

можно сделать вывод что клиентское приложение работает исключительно как монопроцессное и ничего с этим не поделать.

17. fishca 1259 08.09.11 16:47 Сейчас в теме

(16)

это было изначально известно еще при выпуске 8.0, что по сравнению с 7.7 ничего в этом плане не поменялось и думаю не скоро поменяется.

23. fishca 1259 08.09.11 17:28 Сейчас в теме

Стандартный ответ - фуфу, это же бесплатное поделие, то ли дело православный MS SQL, такие-то мощщи. Ну и все в таком же духе.

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

24. LeaNaeD 08.09.11 17:35 Сейчас в теме

(23)

железобетонные аргументы - это тесты-обзоры из авторитетного источника, а не мнения незнамо кого из форумчиков. В этом-то и суть. По клиент-серверному варианту 1С я и сам мало что знаю, разве что изучал когда-то ansi sql, ну и книжка есть по MS SQL серверу от мелкософта же, читал когда-то, да не пригодилось.

28. V_V_V 08.09.11 21:06 Сейчас в теме

Один момент остался незамеченным, судя по комментариям. А именно - при равных условиях операционка WIN2003 уделала WIN2008. Хоть в приведенных автором данных и несущественно, но именно из-за этого я откатился назад с 2008 на 2003 (SQL остался 2008). У меня прирост получился многократный, при двух процах XEON 5600 (суммарно 12 ядер), памяти 24 ГБ и весе базы в 30 Гиг отчет за 4-е года по всем оборотам с разбивкой по годам и общими итогами на 2008-м строился около получаса - на 2003-м не больше 2-х минут (конфа самописная, управляемые формы 8.2, отчет не изменялся, данные втянуты за прошлые периоды). И там и там загрузка ВСЕХ процов доходила до 95-100%, пользователи на 2008 ощутимо тормозили, на 2003 мало кто заметил неудобства. Для себя сделал вывод - старое не всегда хуже...

29. fishca 1259 08.09.11 21:14 Сейчас в теме

(28)

А именно - при равных условиях операционка WIN2003 уделала WIN2008

кстати на эту тему кто-то здесь кажись описывал эксперименты или на партнерском форуме, причем на разных серверах выигрышь 2003 над 2008 либо были либо нет и к общему знаменателю не пришли.

30. echo77 1906 08.09.11 22:35 Сейчас в теме

(0) диски как разбиты?
выполните скрипт(VBS) с сервера 2003:

strComputer = "." ' Local Computer
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") 
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_DiskPartition",,48) 

For Each objItem in colItems     
	Wscript.Echo "Disk: " & objItem.DiskIndex & "  Partition: " & objItem.Index & "  StartingOffset: " & objItem.StartingOffset & " Bytes"     
Next

Показать

лучше из консоли, т.е. командой:

cscript скрипт.vbs

- не совсем понятно, почему с отключенным версионированием процедура заняла больше времени :-/
- что значит?:

5 W2K8R2 + SQL2005 1С 8.2 переустановлена на диск на хранилище (не на диск С:)

До этого все тесты проводились на системном разделе?

32. pulpik 106 09.09.11 09:32 Сейчас в теме

- не совсем понятно, почему с отключенным версионированием процедура заняла больше времени :-/
- что значит?:
Цитата
5 W2K8R2 + SQL2005 1С 8.2 переустановлена на диск на хранилище (не на диск С

по умолчанию программа ставится на диск С:
в этом случае я ее поставил на диск D: туда же где лежали базы SQL

33. mad_maksim 88 09.09.11 09:38 Сейчас в теме

5 W2K8R2 + SQL2005 1С 8.2 переустановлена на диск на хранилище
Да, мне тоже это непонятно. Если речь именно о файлах базы данных SQL, то они однозначно должны быть на отдельном диске.
Если речь о платформе - не имеет никакого значения, где они.

35. sumixam 09.09.11 15:17 Сейчас в теме

у меня стояла конфа самописка 1с8.2 файловый вариант 10 пользюков номально работала потом пипец ваще загибаться стала, перевел на СКЛ 2005 ваще супер летает 40 юзеров, полет нормальный, правда памяти 4 гига пришлось на сервер добавить))))))

36. Gasdrubal 12.09.11 05:38 Сейчас в теме

Самый смак бло бы сравнить с доступным всем программистам SQL - express edition. по заявлению производителя там должны быть худшие штуки в плане оптимизации плана запросов и прочего. Но действительно ли это хуже будет работать н типовых конфигурациях. Тем более у многих фирм база не достигает 4 гб - типовя бухгалтерия ил торговля ( если своевременно делать выгрзку)

38. dreamland 2 14.09.11 19:32 Сейчас в теме

Недавно устанавливал 1С БП 2.0 (количество документов 2910, остатки на начало года по 14.09.2011г) на сервак DEPO Storm 2300L2 (Intel® Xeon® E5620, 12ГБ ОЗУ), на VMware три виртуальных сервака (1С Администрирование - 2ГБ ОЗУ, SQL Server 2008 R2 - 2ГБ ОЗУ, Терминал - 3ГБ ОЗУ), на всех ОС - W2K8R2. Время тестирования - 35 минут, красота, доволен, это при учете того, что на серваке крутится шесть баз (и все бухам нужны :D ). В скором будущем планируем переход на УПП, посмотрим, как она себя покажет.

39. yliasha 21.09.11 11:08 Сейчас в теме

Спасибо большое,за интересную статью. Очень помогла разобраться.

40. tiniji 164 21.09.11 14:48 Сейчас в теме

А в файловой БД не пробовали? Может быть еще быстрее будет чем SQL ?

41. powerpc 225 28.09.11 00:01 Сейчас в теме

у нас Core i7 на VMWare ESXi 5 порвал все серваки Depo, HP. Прирост скорости в 2 раза на файловых базах и в 2,5 раза на SQL. Причем на связке W2K3+SQL2K8R2 оптимальная смесь получилась.

42. timothy 27.10.11 13:25 Сейчас в теме

Подскажите статью, где можно будет прочесть как правильно SQL srv 2008 правильно настроить. а то база тормозит - жуть. а всего 13-15 пользователей.

43. Motor24 12.12.11 17:14 Сейчас в теме

Присоединяюсь к последнему комментарию - очень интересует вопрос правильной настройки SQL 2008 для работы с платформой 8.2

44. пользователь 01.03.12 20:21

Сообщение было скрыто модератором.

...

45. пользователь 18.10.12 15:15

Сообщение было скрыто модератором.

...

Оставьте свое сообщение

E-mail:

Автор:

(pulpik)

Рейтинг: 106

Для получения уведомлений о новых публикациях автора подключите телеграм бот: Инфостарт бот

Публикация:

№ 89589

Создание 08.09.11 13:13

Обновление 09.06.16 11:31

Статистика:

Просмотры 13815

Загрузки 0

Рейтинг 69

Комментарии 44

Характеристики:

Код открыт Не указано

Рубрики HighLoad оптимизация

Кому Системный администратор

Тип файла Нет файла

Платформа Платформа 1С v8.3

Конфигурация 1С:Управление производственным предприятием

Операционная система Windows

Страна Россия

Отрасль Не имеет значения

Налоги Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Бесплатно (free)