Как сильно снизится производительность обработки запросов в серверном варианте, при количестве номенклатуры более 50 000, разделения групп на виды номенклатур, и наличия у многих видов номенклатуры собственных индивидуальных и общих характеристик.
Какие методы увеличения производительности существуют.
Отражается ли использование индивидуальных характеристики от общих, и нужно ли стремиться вообще уходить от характеристик, за счет увеличения количества номенклатуры.
Короче как лучше изначально строить базу.

50 тыщ - это немного. Взлетит.
А производительность лучше оценивать исходя из количества операций в день(документов).

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

(2) скорей всего, что сквозной общий список всех индивидуальных характеристик выводиться в интерактивных формах для пользователя не будет. А поэтому на практике тебе будет все равно сколько всего, а главное будет сколько нужно отобразить на одном поле списка. В этом случае в УТ уже предусмотрено, что справочник номенклатура будет разделен на группы и внутри групп вы тоже будет вводить свои группы.

Можно предположить, что динамический или любой вообще список на тысячу строк отображается не мгновенно, но терпимо.
Отраслевая специфика у твоей номенклатуры какая? Может это Фармацевтика или Продукты питания или Одежда какая-то, что вообще?

(3)"Отраслевая специфика у твоей номенклатуры какая?" - комплектующие, аксессуары и товары электроники

т.е. я могу смело не задумываться над вопросом какое кол-во характеристик я создал, хоть по 100 индивидуальных для каждой номенклатуры? (это конечно утрированно, но как пример максимальной нагрузки хар-ик пойдет)

(0) Начнет тормозить - тогда и спрашивайте. А так не парьтесь.

(5) потом будет поздно переделывать базу.

и еще - виды номенклатуры, есть смысл разносить по типам (например виды: корпуса для телефонов, корпуса для планшетов, корпуса для фотоаппаратов) или просто использовать один вид с едиными реквизитами и характеристиками - "корпуса", учитывая что все это будет выгружаться на сайт и там управляться фильтрами? или это все чисто индивидуально и ни на что кроме удобства не влияет?

(6) Все индивидуально.
Но надо помнить одно, что чем больше характеристик, тем геморнее вести учет.

>Начнет тормозить - тогда и спрашивайте.

узнать через полгода что поздно пить боржоми и ничего сделать нельзя - это эпично

чем больше разных используемых характеристик, тем больше селективность индексов, тем параллельнее параллельная работа.
50000 - это херня на палке, а не объем.

Но в целом обсуждать производительность конфигурации в отрыве от железа - пустая трата времени

так вроде динамические списки не получают все данные для отображения, а только порции

(9) Селективность КАКИХ индексов?

Рекомендации 1С - сделать нагрузочный тест

(11) индексов регистров накопления

(13) Извиняюсь, селективность индексов какой конкретно из таблиц регистров накопления?

допустим не 50 000, а 500 000 тыс наименований.

(9) > чем больше разных используемых характеристик, тем больше селективность индексов
т.е. использование хар-ик это больше плюс чем минус, как я понял?

> Но в целом обсуждать производительность конфигурации в отрыве от железа - пустая трата времени

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

(15) использование характеристик - не плюс и не минус. Это просто функция информационной системы.
Производительность не определяется каким-то одним параметром. Пытаться предугадать производительность системы, оценивая только один, влияющий на эту производительно, аспект бессмысленно.

Сколько пользователей будет? На сколько они будут активно читать/записывать? Какое железо под всем этим будет?

Вы на полном серьезе считаете, что количество элементов в одном справочнике полностью определяет производительность?

(16)> Вы на полном серьезе считаете, что количество элементов в одном справочнике полностью определяет производительность?

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

Сколько пользователей будет? - 15 - 20
На сколько они будут активно читать/записывать? - не знаю, как менеджеры
Какое железо под всем этим будет? - Intel Core I7 3770, 2x8 GB DDR3

(17) Чтоб перебдеть, см (12)

(17) ну во первых это сложно назвать сервером, а во вторых производительность и ут11 вещи слабо совместимые

(19)Не мужики, залезли в дебри. Я задавал простой вопрос - насколько сильно можно загружать характеристиками, и что лучше: использовать разновидности номенклатуры вместо характеристик, а если характеристики, то общие или индивидуальные. На данном этапе наполнения меня только это интересовало в общем-то. Чтобы не пришлось потом переделывать.
А железо, пользователи, документы и пр. - это уже следующий этап.

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

но тогда вытекает следствие - чем больше характеристик, тем больше будет объем базы. Это влияет на быстродействие?

1. Нагенерировать для теста различные сочетания количеств номенклатур и характеристик и проверить что нужно не так долго, зато даст 100% результат.
2. В случае большого количества номенклатур (любого большого справочника) упор нужно сделать в то, чтобы эти номенклатуры можно было потом найти за адекватное время - проблема наименований.
3. Проблема быстродействия вылезет в другом месте и гораздо важнее определиться с объемом документов и активностью пользователей. Впрочем, имея планируемое железо, тест можно устроить аналогично п.1.

(22) (12) верно. так и сделаю. спасибо

а что с (21)?

(23) на быстродействие общий объем не дает практически ничего. Это будет решать упомянутая выше "селективность индексов".

Здесь нужно все-таки не слишком увлекаться. Если справочник Номенклатура будет избыточно перегружен, допустим, группами и подгруппами, то чем это на практике окажется?
Берем просто доведение до абсурда.
Пользовать не сможет пользоваться подбором без нервотрепки и вынужден будет наплевать на структурированный справочник и подбирать из списка без отборов. Что тогда будет с тормозами? А вот то самое и будет, что 50 000 элементов не сервер нагрузят - ему как раз пофиг на это - а на клиентскую машину будут нагрузку давать.

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

(24) справочники не будут превышать 5 уровней вложенности. К тому же, строим по принципу формирования наименования номенклатуры из реквизитов. Т.е. подбор как через папки структурированные,так и быстрыми фильтрами в ут11

(25) Я так прикинул, вид номенклатуры стоит разделять тогда, когда появляются собственные реквизиты, необходимые для быстрых отборов на сайте и УТ11. Можно задать один вид "корпус", и реквизит к нему "тип корпуса" - телефоны, планшеты, фотоаппараты и пр. А так как у них у всех единый набор реквизитов (материал, размер, цвет, комплектность), то нет смысла разделять на отдельные виды.

и вот интересно, в больших магазинах что используют для внутреннего учета? 1С? было бы интересно посмотреть на организацию дерева справочников и видов номенклатуры.

(0)
Количество номенклатуры вообще не сильно влияет. Влияет количество документов и позиций в день

Идефноль-то как с производительностью?..

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

(29) Производительность сервера никак не связана с возможностями пользователя осознавать и обрабатывать информацию. Тормозит не сервер, а клиент. Вначале на клиента передается результаты выборки данных с сервера, затем управляемые формы на клиенте начинают полученные данные раскрывать. Когда данные будут структурированы через одно место, то и смотреть придется на эти данные точно также

(30) если это ответ про идефноль, то я не понял

(27) интерес к одним справочникам. как раз к тому что не влияет на производительность базы напрямую.

Так обычно люди далекие от ИТ размышляют. Что если 100 позиций номенклатуры, будет все быстро. А 100 тыщ медленно.

(20) забей на справочники. смотри на регистры и документы.

знаю одну базу, в которой один справочник весит 2 с хером терабайта (или даже уже шесть?.. ну, вы поняли). И этот справочник ни как вообще совсем насовсем на быстродействие не влияет в конфе, в которой овер 700 пользователей одновременных.
Так что сабж - хрень.

(35) чем торгуют, что так набили справочник?

Главное не объем справочника - а формирование отчета с этим справочником.

производительностью 1С напрямую зависит от железа  и клиент-серверного варианта.

только это.

(38) ну конечно же. че все блокировками парятся. ну тупыеее...

купил железо подороже и мощнее, и можно справочник делать в 100 тыщ мильенов позиций, и отчеты с ним формировать. красота.

(39) количество юзеров тоже имеет значение. Ноя знаю автора у него не 50 юзеров.

а скорее 5. и не каждую секунду новый документ.

Блокировками парятся когда 150 юезров и в секунду пара документов.

И то в восьмерке на SQL блокировка на уровне конкретных записей.

(36) это не номенклатура, но обращений чтения-записи к нему вдругорядь и 2лимона в месяц бывает и даже больше

на 700к номенклатуры и 4 миллиона характеристик я работал на двух серваках купленных на бу рынке по 150 тыщ рублей.

Главное SSD  и памяти по 128 гиг.

Один под SQL сервер - другой под Сервер 1С и частично терминал.

Впёрлись вам эти справочники, а?.. Дал же живой объективный пример, что количество элементов и объем инфы в справочнике не играет роли.

парни, был бы я ИТ-шником или 1С-ником, согласитесь - этой темы не было бы. А так - ясно и понятно объяснили.
Особенно (40), (35) - безапелляционно. (25) и (26) - здраво и технично.

Спасибо всем. Закрываем тему.

(41) Евгений, я вам больше скажу, в данный момент база вообще почти не наполнена и даже ни одного пользователя нет. Все в процессе обработки и наполнения. И ваш пакет программ, как раз для этих целей используется.

(41) количество юзеров не имеет значения.

При 50 тыс. номенклатуры работать в УТ11 практически не возможно.  УТ11. Долго открываются формы.
  Установка цен, ввод начальных остатков, отчеты - все тормозит так, что работать могут только идиоты.

Мы вбухали в эту гребанную Ут11 200 тыс. рублей и выкинули ее на помойку.

Если учесть, что в УТ11 50% функционала работает с ошибками, то непонятно вообще, кто на ней может работать.

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

(49) я вот недавно машину купил, вот гоvно эти ваши машины. постоянно едет не туда, врезается во все столбы и глохнет. пришлось выкинуть на помойку. ездить могут только идиоты.

(48) (49) просто у УТ11 нет мозгов, вам надо было использовать свои

(52) Ты мне сказки не рассказывай, я тебе говорю, что есть. Конечно если поставить все SSD диски. RAM на временные файлы, то полгода УТ11 протянет, потом все равно умрет.

(53) Я с вами полностью согласен. Если переписать 30% функционала, то все будет нормально, только какой идиот это профинансирует

Извините для 50 тыс номенклатуры нормально УТ11 не будет никогда.

(54) шыдевар просто...
(55) не надо ни чего переписывать, просто вы ожидали, что ПО - это все, что нужно для автоматизации, но в реальном мире это не так

Вы знаете какие алгоритмы УТ11 использует для поиска дублей в табличных частях?

(56) если вместо сервера игровой десктоп, а сеть "живет" на свичах длинк, то - да, ни когда

(56) на файловой согласен.

Кстати автор забыл уопмянуть что он и прайсы будет загружать в 1С от множества поставщиков с такой номенклатурой.

У него моя обработка)

И скорее всего его главный вопрос связан не с тем что в базе стока номенклатуры а с тем что при импорте прайса - обработка будет искать по экселю каждую номенклатуру чтобы синхронизировать каждый прайс и впоследствии зарегистрировать цены в 1С.

И работа эта ежедневная.

)))))

Речь идет не об автоматизации, а о быстродействии УТ11. Не надо ля ля. У нас сервер нормальный. SSD 16 гигов x64
На файловой при 50 тыс. номенклатуры УТ11 легла при установке отбора по родителю. Она это делала 20 сек.

(62) :)

(62) софт на сервере какой (ось, субд)?

(56) более 100к номенклатуры, более 100 юзеров, 13к складских документов в месяц, "УТ11" летает более 2 лет без всяких ССД.

ЧЯДНТ? :)

(64) тебе сказали же - нормальный сервер, чо ты занудствуешь? :)

Конфигурация сервера:
Intel Xenon 3.3 Ghz
Память 16 Гб
Диск SSH
SQL 2008 R2  x64
Сервер 1с х 64 8.3.5.1146

(65) идиот, очевидно же. в (48) все написано.

(65)  смотри сюда (49)  - там кто-то сделал на этом 200 кусков и ни чего компании не дал. В этом ответ на вопрос, что ты делаешь не так

ты просто, Feanor, не эффективный менеджер

(70) вообще не менеджер. может в этом проблема?

(71) угу, а еще спрашиваешь, что ты делаешь не так...

(48) открой для себя интерфейс Такси - УТ11 все формы, списки, поиски, выборы - летают!
Все открывается со скростью звука.

(65) Значит у вас от УТ11 осталась только УТ10 :)
Здесь видел УТ10 на сети розничных магазинов. Быстро работает. Я стал расспрашивать что да как, оказалось, что партионный учет отключен, используют только остатки.

(72) спасибо, братцы, я все понял, ушел исправляться :)

(67) этот Intel Xenon 3.3 там, я так понимаю, один? И это тот самый the Server, на котором и домен, и почта, и прокси, и скуль, и сервер приложений, и файлопомойка

(73) и не важно сколько у меня элементов номенклатуры и какой сервер? надо брать.

Вообще при работе с номенклатурой в УТ11 важно только одно - форма подбора номенклатуры - которая перегружена данными выводимыми в списке - ценами, остатками и прочими финтиплюшками.

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


Это лечится с помощщью такси.

Либо самиписными подборами.

(74) складской функционал типовой абсолютно. специально вообще ничего не тюнили.

(77) сервер тоже важно.

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

Опять же повторюсь у автора все связано с (61)

Поэтому больше вопрос адресуется конкретно ко мне)

(80) так надо было же (48) УТ просто в метро интерфейсе запустить. и залетало бы все завертелось. вон оно че.

(82) Сегодня бушке БП в такси переключил. Через 2 часа звонок - мне неудобно. Пришлось объяснять, как обратно переключать

Задача автора - 50к номенклатуры и ежедневная загрузка прайсов на эти 50к номенклатуры.
С учетом в том числе характеристик.

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

(84) отпусти ручник, задача автора уже давно ни кому не интересна

(83)а вогт это уэе другой вопрос)) что в такси все желто ядерное и большое)))

(61) это верно

(80) а работа из под rdp, не желательна для 8.3?

(85) а зря. наверное сейчас каждая вторая фирма именно с этой задачей и связана.

или ты думаешь кто то 50к номенклатуры руками набивать будет и цены регистрировать.

Да все торгаши сейчас все загружают из прайсов поставщиков.


По сути мы имеем что основная нагрузка как раз заключается именно в этой задаче.

(87) 8.3, rdp и желательность ни как не связаны

(87) под rdp - только и желательна.

просто насколько я понял из (48), работал через терминал.

(88) мне не интересны твои поделки, не надо мне их продавать

ничего быстрее быть не может чем прямая работа на серваке.

(92) я не продаю сейчас ничего.

Я объясняю в чем суть вопроса и поставка вопроса.
И основная нагрузка.

(91) насколько я понял из стенаний автора (48) там проблема в том, что ресурсы аппаратного обеспечения ни кто не оценивал до внедрения и не согласовывал с потребностями внедряемого ПО. То есть - некомпетентность внедренцев и все. Ни какого отношения к rdp это не имеет

(93) угу, а балансировку нагрузки между сервером приложений, сервером ДБ и клиентом придумали трусы, которые еще тормоза в автомобили придумали, да?

Подитожу

1) Серверная 1С 64 - обязательно = 100к
2) SQL плюс серверная винда и тп -  обязательно = 100-150к
3) Более менее вменяемый сервак - обязательно = 150-200к.


Ориентир 5-10 юзеров, работа с 100к номенклатурой и 300 характеристик.

Бюджет 400-500 тысяч.

(96) я тя умоляю. если будет пара лезвий с SSD и достаточным объемом оперативки - автору на 10 юзеров и 1 миллион элементов хватит за глаза.

Без всяких вызовов супер специалистов по балансировке.

Хотя лично я бы на месте автора УТ11 вообще убрал и заменил на УТ10.
У номенклатуры УТ11 почти 100 реквизитов в метаданных. это пипец.

В идеале.

>У номенклатуры УТ11 почти 100 реквизитов в метаданных

маня, скажи что ты гонишь...

Вызвать мегаспеца по балансировке будет стоить 100к.

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

(100) конечно же гонит. 51 их там всего  (11.1.10.94)

(100) открой пофигуратор - зайди и посчитай.

Сори не 100. Специально сам сейчас посчитал - 56.
Странно - в прошлых релизах было 81.

81?

аааа

(101) ты непроходим...
да, в мире твоих поделок и задач, которые они решают, (93) абсолютно верно. В (96) я имел в виду намекнуть, что мир гораздо шире, чем помещается у тебя между ушей, но, тут до меня дошло, что это филькин труд

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

(106) еще чуть-чуть и ты станешь смешным, давай сменим тему

(106) знаем! он грузит прайс в 50 тыщ твоей обработкой и от этого  счастлив и улыбается.

(108) счастливый юзер бывает только в 1 день - в день зарплаты.
И то не всегда)

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

(110) И какие же?)

(67)
>>Память 16 Гб

На 16 и у нас бы легла

А то что управляемые дрянь - еще известно было 5 лет назад. Сам разгребал кучу проблем с ними. Если  Maniac про Такси правду глаголет - это очень здоров

Ля ля он про Такси. Формы списка и в обычных УФ не тормозят.
Тормоза УТ11 связаны на 50% с тормозами УФ. Большие документы, отчеты, СКД - стандартные тормоза. Остальное - это тормоза алгоритмов. Если они дубли строк ищут перебором, тогда о чем тогда можно говорить. УТ11 - это удел ларьков.

Еще один кусок тормозов - это кривое кеширование. Для УТ11 это становится актуальным т.к формы там магко говоря большие.
После интенсивной работы через неделю любая форма в УТ открывалась за 30 сек.
  Можно конечно устроить танцы с бубнами. Перегружать постоянно сервера. Чистить кеши. Но это не правильно

Через веб сервер все формы летали

Но это не всем подходит