|
Максимальное количество пользователей в 8.1 ₽ | ☑ | ||
---|---|---|---|---|
0
R41
27.08.07
✎
13:25
|
Господа, хочется получить убедительные аргументы по поводу максимального количества активных пользователей, поддерживаемые 1С 8.1. Что интересует:
1)Число пользователей от 150, но в перспективе интересует 300-400 2)Хочется всех вкусностей ERP системы, которые есть в УПП. Но есть понимание, что бух.часть этой конфигурации является тормозным звеном и лучше на нее не расчитывать. Есть готовность взять конфигурацию и с нуля переносить все функции УПП, пока не начнуться тормоза. Или сделать наоборот - отрезать в УПП все лишнее. 3)На железо планируется потратить порядка 200т.у.е.: 64 битная архитектура, много памяти, СХД уровня SAN (например EVA 4100). Взлетит ли УПП? |
|||
1
Господин ПЖ
27.08.07
✎
13:26
|
>>Хочется всех вкусностей ERP системы, которые есть в УПП
смеялсо... |
|||
2
Господин ПЖ
27.08.07
✎
13:27
|
>>Но есть понимание, что бух.часть этой конфигурации является тормозным звеном и лучше на нее не расчитывать
опять смеялсо... |
|||
3
Херрес
27.08.07
✎
13:29
|
(2) хочешь сказать что регистр бухгалтерии - не тормоз ?
|
|||
4
R41
27.08.07
✎
13:29
|
Просьба не переводить все на рельсы религиозных войн. Хочется чтобы ветка получилась информативна, содержала объективный взгляд на проблему, причем со всех сторон.
(1)У нас производство, для него нам за глаза хватило бы функциональности ПУБ 7.7. |
|||
5
PowerBoy
27.08.07
✎
13:30
|
ставлю 100, кто больше? :-)
|
|||
6
R41
27.08.07
✎
13:31
|
(2)Информацию о том, что регитсры бухгалтерии - это тормоза нашел из поиска. В 1С 8.0 один план счетов - одна таблица, если логично рассуждать - то все верно, это узкое место и будем стараться его обходить...
|
|||
7
R41
27.08.07
✎
13:31
|
(5)на что? на то что взлетит?
|
|||
8
masky
27.08.07
✎
13:32
|
(4) ну и возьмите ПУБ
|
|||
9
Господин ПЖ
27.08.07
✎
13:32
|
(3) Тормоз. Но он же не один такой. Вся система низколетающая...
|
|||
10
masky
27.08.07
✎
13:33
|
(9)+1
|
|||
11
Господин ПЖ
27.08.07
✎
13:33
|
(4) сбейте смету на все железки, обучение, доработки приглашенного франча...
|
|||
12
MuI_I_Ika
27.08.07
✎
13:34
|
(6) Логичнее было бы говорить, что тормозят не регисты бухгалтерии, а механизм работы с планами видов характеристик, который на самом деле не совсем удачный.
|
|||
13
masky
27.08.07
✎
13:36
|
(12) там сама задумка неудачная. все остальное вытекает из нее
|
|||
14
Херрес
27.08.07
✎
13:37
|
(0) наверно надо говорить не о регистре бухгалтерии в отдельности, а более широко:
о том, чтобы организационными мерами достичь приемлемой производительности по принципу "разделяй и властвую" например можно начать с внедрения оперучёта и если производительность и правда подойдёт к критической - БУ вести уже в другой базе |
|||
15
R41
27.08.07
✎
13:40
|
(11)Внедрение будем проводить сами, направим аналитиков и программистов на курсы УПП. Чтобы поднатореть в прикладной части. У франча только возьмем в аренду программистов, 8-ков (если не будем успевать сами - т.е. собственный опыт в 8-ке, большой, но в УПП опыт равен 0).
Соответственно сумма внешних затрат на внедрение около 100, максимум 200. Но дело не в деньгах. А в самой возможности использовать 8.1 для 400 активных пользователей. Например можно сделать так, чтобы заказы и некоторые другие документы обрабатывались не в он-лайн, а в фоновом режиме (через специальный объект, который есть в 8.1) - т.е. применить разделение документов на потоки, которые используется например в SAP. |
|||
16
R41
27.08.07
✎
13:42
|
(14)А может тогда внедреить УТ, а уже к ней прикрутить систему производства. Или проще отделить бух учет в УПП (я просто не знаю УПП вообще)?
|
|||
17
Херрес
27.08.07
✎
13:42
|
кстати конкретно в УПП - не факт что проводки по РБ будут тормознее чем по регистрам, ибо в плане счетов аналитики на "тяжелых счетах" поменьше будет чем в регистрах (нет например характеристик)
ну и в конце концов можно сделать доработочку чтобы проводочки делались сводно, а полная аналитика на регистрах накопления |
|||
18
Херрес
27.08.07
✎
13:42
|
(16) отделить бухучёт на порядок проще
|
|||
19
R41
27.08.07
✎
14:30
|
(18)Ваше заключение - будет работать 8.1 с производственным функционалом для 400 активных пользователей?
|
|||
20
Advan
27.08.07
✎
14:40
|
Есть работающие система на 200-300 человек - правда там приходилось оптимизировать УПП - проблема то не в платформе - а в конфигурации
|
|||
21
masky
27.08.07
✎
14:47
|
> проблема то не в платформе
lol |
|||
22
Advan
27.08.07
✎
14:52
|
(21)Не LOL - я знаю что УПП работает на 300 пользователях - но это после серьезной переделки УПП
|
|||
23
masky
27.08.07
✎
14:59
|
2 раза лол.
|
|||
24
koord
27.08.07
✎
15:07
|
При всей курьёзности ветки отвечу всего на один вопрос:
8.0/8.1 может потянуть 300-400 пользователей. Но не на типовых решениях. Более того - после года разработки/поддержки от типового там вообще мало что останется. |
|||
25
masky
27.08.07
✎
15:27
|
(24) а нафига тогда 1С?
|
|||
26
Snovy
27.08.07
✎
15:37
|
(25) При наличии граммотных консультантов-постановщиков, которые знают, что такое автоматизация и знают предметную область (не знают, как это сделано в 1С, а знают, как это должно быть на самом деле и имеют соответствующий опыт - не только внедрения, но работы на соответствующих должностях глав. бухов, аудиторов, управленцев), то на платформе 1с 80-81 можно делать неплохое ПО для автоматизации предприятий. Вот за этим и нужна 1с.
|
|||
27
masky
27.08.07
✎
15:40
|
>то на платформе 1с 80-81 можно делать неплохое ПО для автоматизации
предприятий. грустно.. весьма грустно |
|||
28
R41
27.08.07
✎
16:03
|
(24)Вот уже пошла тяжелая артиллерия, пошли знакомые лица... Цифры это хорошо. Статистика знает все. Вопрос к вам: что лучше изначально писать с нуля или все таки начать переделывать УПП (чтобы вы выбрали если бы вам пришлось делать ваш проект заново)?
|
|||
29
R41
27.08.07
✎
16:06
|
(24)Кстати, если размышлять логично, то если у вас 8.0 поддерживает 300 пользователей, то используя кластер на 8.1 логично предположить что должно быть 600 (например если использовать кластер из 2-5 мощных серверов приложений).
|
|||
30
masky
27.08.07
✎
16:10
|
(29) лучше жевать чем говорить.
чтобы меня не обвинили в голословии. в последний раз, так уж и быть объясню почему: >кластер на 8.1 логично предположить что должно быть 600 (например если >использовать кластер из 2-5 мощных серверов приложений). совершенно нелогично. потому что могут не выдержать нагрузки следующие вещи(в порядке вероятности): 1) SQL сервер 2) клиенты (как минимум придется переносить все на сервер) 3) сеть |
|||
31
КонецЦикла
27.08.07
✎
16:14
|
"и с нуля переносить все функции УПП, пока не начнуться тормоза. "
Садо-мазо какое-то... |
|||
32
R41
27.08.07
✎
16:17
|
Интересно а как же все реализовано в SAP, если он выдерживает несколько десятков тысяч пользователей. Неужто мы на 1С до тысячи не дотянем никогда??
1)Мне кажется в том то и суть серверов приложений - разгрузить сервер SQL - возможно за счет грамотного кэширования, точно не знаю, ни разу не проектировал (а хотелось бы) 2)Это не проблема, особенно если изначально будем писать с нуля. А из УПП брать только идеи предметной области - "как надо". 3)Сеть? Тут ничего не могу сказать, ни согласиться, ни возразить. Не знаю... |
|||
33
Yuwa
27.08.07
✎
16:21
|
(0) Убежден, что проект не взлетит. Но не из-за мнимых или настоящих кривостей, недостатка масштабируемости и пр. А из-за того, что такие задачи не решаются отделом АСУП предприятия. Должен быть партнер извне. Неважно ЦКП или консалтинговая контора, важно, чтобы строили извне.
|
|||
34
masky
27.08.07
✎
16:26
|
(32) ппц. если ты нифига не делал и не знаешь - то НАФИГА влазить???
|
|||
35
R41
27.08.07
✎
16:27
|
(33)Причины?
-Слабость ИТ-отдела, заложенная в его цель: не разрабатывать новое ПО, а поддерживать существующее -Проблемы возникающие при внедрении (организационные проблему) |
|||
36
R41
27.08.07
✎
16:29
|
(34)Ты не так меня понял. В том посте я просто как и каждый умный человек сказал - что я все не знаю, ибо это невозможно.
|
|||
37
masky
27.08.07
✎
16:29
|
(34) а блин. ты топикстартер. тогда точно невзлетит, потому что в твоем случае надо ОЧЕНЬ хорошо знать предметную область.
|
|||
38
R41
27.08.07
✎
16:30
|
(34)Кстати ты на вопрос (точнее пути решения) в (32) ничего не ответил (не возразил) или ты согласен с ними?
|
|||
39
Yuwa
27.08.07
✎
16:31
|
(35) Конечно, п.2. Вероятность вытягивания самого себя из болота за косичку стремиться к бесконечности. Умиляет желание автора переписать в легкую переписать УПП, питаясь только идеями.
|
|||
40
masky
27.08.07
✎
16:34
|
>выдерживает несколько десятков тысяч пользователей
незнаю, невидел. предположения конечно есть |
|||
41
R41
27.08.07
✎
16:34
|
Гм, а причем здесь предметная область - ее знаю другие ответственные лица, очень хорошо знают. Но даже этого не достаточно, я отправлю их на курсы, и сам пойду.
P.S. Мне кажется мы отвлеклись в сторону. Вместо того чтобы доказать что 1С будет работать или не будет работать на большом количестве пользователей, тут хотят доказать что у меня лично ничего не выйдет :) Меня не интересует ваше мнение выйдет или не выйдет, но мне интересны советы, что в в каком случае нужно делать. Без личностей. Например в (33) корректное замечание, а вот в (37) нет - так как был переход на личности. |
|||
42
masky
27.08.07
✎
16:36
|
знание предметной области - помоему первое необходимое условие
|
|||
43
R41
27.08.07
✎
16:37
|
(39)Странно, я как раз думал, что вы будете отстаивать пункт 1. Ну что ж, спасибо. Правильно ли я понял - вы не сомневаетесь, что при грамотной реализации проекта, проблем с производительностью в 1с не будет, а ваше сомнение только в возможности написать нужную функциональность?
|
|||
44
Yuwa
27.08.07
✎
16:41
|
(41) Знания предметной области - мало. Надо иметь некий общий подход, а не наблюдать "как там у нас людишки копошаться". Как сегодня писать не надо, надо писать "как будет завтра".
Вопрос к автору ветки: Вы деньги считали???? Скоко обойдется разработка, во что встанет поддержка наваянного?? |
|||
45
Yuwa
27.08.07
✎
16:48
|
(43) Неправильно. Я думаю, что проблемы производительности вторичны и решаемы. Я сомневаюсь:
1) Что проект (ПП) реально разработать в интересующие фирму сроки даже при наличии команды (аналитики-постановщики, кодеры-разработчики, проектировщики, консультанты и пр) 2) Что даже, если ПП родиться, его нереально внедрить собственными силами, ибо это не учетная система. Решать вопросы с собственными боссами о изменении бизнес-процессов слишком сложно. Учитывая, что вы внутри даже разглядеть ненормальности сложно - вы к ним привыкли и глаз не видит. |
|||
46
masky
27.08.07
✎
16:49
|
>проблемы производительности вторичны и решаемы
весьма смелое заявление |
|||
47
R41
27.08.07
✎
16:51
|
А какие будут предложения? Возможно мы возьмем сторонних разработчиков пока будет вестись разработка: либо фри, либо фра. Но это уже детали. Хотя если есть что предложить - я вас внимательно слушаю. Я пока собираю информацию, решение будет приниматься через месяц.
|
|||
48
Unforgiven
27.08.07
✎
16:52
|
(40)Видел работает, классно работает
|
|||
49
Unforgiven
27.08.07
✎
16:54
|
Да кстати про сторонних внедренцев, допустим у нас в городе Орске, нет ни одного нормального франча, который мог бы нормально полностью внедрить хотя бы ЗуП
|
|||
50
masky
27.08.07
✎
16:57
|
(49) в Белгороде тоже
|
|||
51
Unforgiven
27.08.07
✎
16:58
|
(47)Говоришь бы подошла ПУБ, или УТ, внедрение надо начать с причин и нужд, а потом смотреть что Вам необходимо, удовлетворит ли это все восьмерка.
А вообще сетка физически одна будет??? Всегда же можно сделать две базы, и обмен между ними почаще чтобы разгрузить сервера. Щас работаем на семерке, активных юзеров где то 80, поделили базу на 2 части и все нормал |
|||
52
РазДва
27.08.07
✎
16:58
|
(46) Бывает оптимизация бизнес-процесса сводит число работающих с системой операторов к приемлимому числу, такому, что вопрос производительности даже не встаёт.
|
|||
53
Unforgiven
27.08.07
✎
16:58
|
(50)Проблема провинции... Кто головой вырастает выше уезжает в Москву или в областной центр
|
|||
54
Unforgiven
27.08.07
✎
16:59
|
(52)+1
|
|||
55
masky
27.08.07
✎
17:02
|
(52) потом хотелки увеличиваются и все приходит к тому же
|
|||
56
Yuwa
27.08.07
✎
17:04
|
Что делать???
Ищем: 1) Команду (это главное), способную решить проблему. В сотрудничестве с вами. В конце концов неважно распределение ролей. 2) ОР, наиболее близкое специфике вашей фирмы 3) Достойный бюджет 4) Желание меняться у ТОпов |
|||
57
R41
27.08.07
✎
17:06
|
(51)У нас 150 активных пользователей, все в одной базе, 1С 7.7. Работает нормал, но - мы задумались о будущем...
Сеток нексколько, практически везде 1Гб, в некоторых местах оптоволокно (видимо между коммутаторами), но точностей не знаю, не сисадмин я. Знаю что сделано максимально хорошо, но если нужно будет - подправим. |
|||
58
masky
27.08.07
✎
17:07
|
>неважно распределение ролей
lol >наиболее близкое специфике вашей фирмы я бы сначала просто поискал - где 400 человек работают. потом бы подумал >Достойный бюджет ой тяжкое это занятие >Желание меняться у ТОпов этого непонял |
|||
59
Херрес
27.08.07
✎
17:43
|
не надо решать задачу в лоб
надо внимательно смотреть какие пользователи не пересекаются между собой по данным в онлайне бухов можно высадить в отдельную базу зарплату уж точно можно выделить может быть можно как-то поделить по складам, товары и услуги... может ещё что-то ? 400 человек это же жуткая толпа народу, ну не верю что им всем одновременно нужно что-то в онлайне |
|||
60
Господин ПЖ
27.08.07
✎
17:44
|
(59) Может там у каждого станка по компу.
|
|||
61
R41
27.08.07
✎
17:48
|
Бухи сидят отдельно, у станков действительно стоят ПК (но не у всех). В основном рабочие места - это менеджеры по продажам, планируется их увеличить в 3 раза. Отсюда и цифра 400.
|
|||
62
Херрес
27.08.07
✎
17:52
|
(61) менеджеры накладные бьют что ли ?
тогда сделать им небольшую складскую базу с оффлайн-обменом если менеджеры отчёты смотрют - отвадить их от 1С в конце концов... понаделать им ОЛАП-кубов |
|||
63
Херрес
27.08.07
✎
17:54
|
... и подумать над всякими ночными ночными допроведениями, а днём проводить только по самым необходимым регистрам
|
|||
64
R41
27.08.07
✎
18:02
|
Интересно другое. А именно как у SAP (48) получается выдерживать десятки тысяч пользователей. Почему в 1С это не получется. Что у них другое (руки)? Вроде такая же трехзвенка. Что нужно сделать чтобы мы у нас получилось?
Попытаюсь начать развивать мысль: 1)Убрать все автоматические блокировки, оставить только управляемые. 2)Придумать потоки обработки информации. Например документы, которые некритичны для загрузки в базу, т.е. если они могут подождать час-другой, обрабатывать в последнюю очередь (так сделано в SAP/R3). Эти обработки реализовывать в фоновых процессах, которые должны крутиться на серверах приложений. Единственная трабла - кто-нить знает как определять степень загружденности? Наверно через счетчики MS SQL? Но тогда непонятно как определять степень загруженности серверов приложений... 3)Что еще? |
|||
65
R41
27.08.07
✎
18:05
|
(62)(63)Этими советами мы сыты, причем находясь еще на 7.7. Именно так все и сделано, а ночью выполняются куча процедур (вплоть до 8 утра).
Хочется сделать нормальную систему. |
|||
66
Snovy
27.08.07
✎
18:14
|
(65) А у САПы есть понятие "проведение"? У Аксапты точно нет. Поэтому там и крутится все быстрее, соответственно больше люду сидит в базах - ИМХО отсюда тоже ноги растут. Хотя в этом вопросе я не большой спец.
|
|||
67
Херрес
27.08.07
✎
18:14
|
(64) думаю это всё регистры и работа задними числами.
1Ссовские регистры уникальны тем, что позволяют получить остатки на любой момент времени за счёт того что хранят много срезов, из за этого таблицы итогов пухнут А во всех нормальных системах только один срез - текущий. Ну и заднее число под запретом. Ну и ещё одна причина - чисто технологическая - это плохо строящиеся индексы по полям GUID |
|||
68
R41
27.08.07
✎
18:18
|
(67)А разве в 8.х не один набор остатков? Честно говоря у меня к вам вопрос, вы здесь даете советы, а вы на 8.0 работали?
|
|||
69
Херрес
27.08.07
✎
18:19
|
(64) а ещё десятки тысяч пользователей - это брехня по большей части
больше 500 пользователей - это уже не "легко и не принуждённо" - а на уникальном оборудовании да и не без тормозов (ну тормоза там на любом количестве пользователей, почти как у нас) :)) |
|||
70
Херрес
27.08.07
✎
18:21
|
(68) не пойму, обидеть меня что ли тут хотят
ну прямо скажу на УПП я не работал, не подошла мне она. Но очень хотелось, по производительности не получилось. Поэтому для меня вопрос больной, потому и учавствую в обсуждении. Сам работаю с БП и ЗуП Не хотите советов - не надо |
|||
71
Херрес
27.08.07
✎
18:24
|
(68) принцип хранения промежуточных итогов со времён 7.7 не именился - итоги хранятся на начало каждого месяца. Это вообще краеугольный камень 1С всех поколений
|
|||
72
R41
27.08.07
✎
18:25
|
(70)Обидеть не хочу. Меня самого постоянно пытались обидеть, еле отбился :)
Хочу понять истину. Так как если я выберу 1С 8.1, то буду нести офигенную ответственность. Поэтому хочу все понять, а так как я не работал на 8.1 (только 8.0) хочу получить дельные советы. |
|||
73
Мелкий бес
27.08.07
✎
19:30
|
в одной базе могут работать только много германцев - для соотечественников желательно разделить управление на относительно независимые подсистемы с максимальным использованием типовых решений.
для топов результат будет тот же, а лейкоцитов потеряется меньше |
|||
74
Yuwa
28.08.07
✎
08:31
|
Из басни:
"А мишенькин совет лишь попусту пропал..." Из классики юмора: "Пилите, Шура, пилите.." От себя: Творческих успехов |
|||
75
Diman000
28.08.07
✎
08:47
|
(68) Нет, не один. Промежуточные и актуальные итоги точно также как и в 7.7 еще было. Но в 8.1 все это можно поотключать нах. Можно даже актуальные итоги отключить по выборочным регистрам и вообще одни таблицы движений останутся. Но с ними есть проблема - штатными средствами они плохо индексируются (нет возможности создать составной индекс). Это сказывается не только на производительности, но и очень сильно сказывается на блокировках в автоматическом режиме, поскольку в нем используется уровень изоляции SERIALIZABLE.
|
|||
76
masky
28.08.07
✎
08:51
|
>Хочу понять истину
вот только наша истина тебе судя по всеему неподходит |
|||
77
Samosval
28.08.07
✎
08:53
|
почитал ...
прикольный у вас бюджет 100 - 200 тысяч на прогеров и так далее ... причем с тем что в голове нету целей вООбще .. цель поиграться в ответственность, а это плохо. плохо для бизнеса собственников. вам аналитики нужны, которые скажут что то типа: делите учет на в УПП(1С) и на оперативку (писать самим, тысяч за 20 можно найти гения, котрый за полгода напишет на дельфях или в дот.нет). |
|||
78
R41
28.08.07
✎
11:12
|
(71)Ты не прав. Если выбрать дату границы итогов равной например 1980 год, то в итоге будет всего один набор записей - Актуальных итогов.
|
|||
79
Господин ПЖ
28.08.07
✎
11:15
|
(72) Брать на себя ответственность за внедрение системы учета в России нельзя никогда... При любом раскладе будешь виновным.
ЗЫ Брать можно только так - взял откат и уволился... |
|||
80
R41
28.08.07
✎
11:22
|
(75) Есть способ создать составные и вообще любые индесы - просто создавайте их (прямыми запросами к SQL). 1С 8.1 вполне лояльно относиться к чужим индексам. Удаляет их только если меняется структура таблицы.
|
|||
81
R41
28.08.07
✎
11:26
|
(75)Я же написал в (64) - используем только управляемые блокировки.
Продолжаем развивать идеи, новый пункт: 3)Использовать собственные индексы (особеннно составные - так как в 1С нет инструмента их создания) 4)Что еще? |
|||
82
R41
28.08.07
✎
11:27
|
(76)Истина она одна, от вас я хочу собрать информацию, чтобы вместе с вами ее найти.
|
|||
83
Diman000
28.08.07
✎
11:30
|
(81) Еще отключение актуальных итогов в подавляющем большинстве регистров. Или вообще во всех - при нормальных индексах, имхо, должно летать и без них
|
|||
84
R41
28.08.07
✎
11:35
|
(83)А как это делается? я что то не нашел...
|
|||
85
Diman000
28.08.07
✎
11:37
|
(84) Флажка в конфигураторе нет, к сожалению)) Есть метод у менеджера регистров, не помню точно - глянь в СП
|
|||
86
R41
28.08.07
✎
11:38
|
(83)Кстати вы тут ошибаетесь, представьте 10 млн записей движений. В то время как в таблице актуальных итогов их порядка 10 тысяч. Таким образом в вашем случае в среднем нужно в 1000 раз больше времени чтобы получить остаток
|
|||
87
koord
28.08.07
✎
11:46
|
(0) Попытаюсь объяснить, почему ветка курьёзная:
Автор сабжа хочет понять, брать ли ему ответственность за проект, при этом разговаривая о вещах, которые к проекту автоматизации на 400 пользователей отношения НА ЕГО УРОВНЕ (как руководителя проекта) не имеют. Какие-то автоматические блокировки, принципы хранения итогов, потоки... РП такого проекта будет 80% времени проводить на бесконечных заседаниях, работать с проектной документацией, бюджетами, отчётностью, будет решать проблемы с кадрами, выстаривать политически правильные отношения с топами и т.д. и т.п. Вы за ЭТО берёте ответственность. Вы ЭТО готовы/хотите делать? Хватает ли политического веса? Достаточно ли ресурсов? Достаточно ли дома запасов вазелина? А вы - про технические нюансы.. |
|||
88
Yuwa
28.08.07
✎
11:51
|
(87) Абсолютно точно. Я слежу за веткой и вообще не понимаю, пробьет ли автора на здравый смысл.
|
|||
89
Diman000
28.08.07
✎
11:54
|
(86) Ты говоришь о ситуации, когда для получения итога необходимо выполнить полный перебор движений, при использовании индекса это будет совсем не так. Кроме того, я, конечно, не силен в вопросах касающихся работы SQL Server, пусть меня поправят более знающие люди, например masky, но сильно подозреваю, что при увеличении количества чтений, общее время выполнение запроса вовсе не обязательно вырастет пропорционально.
Не говоря уже о том, что для целого ряда регистров актуальные итоги в принципе не нужны, потому как запросы к ним на актуальный момент времени ну очень редки. Регистры бухгалтерии в УПП это типичный пример. |
|||
90
masky
28.08.07
✎
11:55
|
>пусть меня поправят более знающие люди
Дима, лучше жевать, чем говорить |
|||
91
Херрес
28.08.07
✎
11:59
|
(87) ну а с другой стороны - стоит ли вообще начинать дело если заранее будет известно, что при такой нагрузке вообще ничего работать не будет
он всё правильно делает - сначала надо разведать техническую возможность |
|||
92
R41
28.08.07
✎
12:00
|
(87)Может быть вы правы, а может и нет. Но я привык держать все под контролем, каждый винтик в системе. Пока мне хочется понять какую систему выбрать 1с,SAP или еще что-то.
Цель данной ветки - обменятся мнениями взлетит ли 1С 8.1 (в частности УПП) вообще, т.е. теретически, при выполнении всех технических нюансов пунктов 64,81. |
|||
93
masky
28.08.07
✎
12:01
|
(91)>сначала надо разведать техническую возможность
на этом форуме он этого не узнает |
|||
94
R41
28.08.07
✎
12:05
|
(89)Ты видимо путаешь со временем доступа к одной записи (в случае если она проиндексирована). Да действительно, если записей миллион или миллиард скорость доступа особенно не изменяется (если у мы осуществляем бинарный поиск, то в первом случае доступ будет осуществлен за 20 циклов, а во втором за 30 - т.е. замедление только в 1,5). Но это применительно именно к одной записи, к 10 записям нужно 10 раз обращаться. К 1000 - 1000 раз. В то время как таблица движения растет, таблица актуальных итогов практически нет...
|
|||
95
Херрес
28.08.07
✎
12:05
|
(93) а на каком узнает ?
|
|||
96
R41
28.08.07
✎
12:05
|
(93)Не согласен, здесь есть и технически подкованные люди.
|
|||
97
masky
28.08.07
✎
12:07
|
(93) а ни на каком. помоему таких внедрений вообще нету.
http://www.sql.ru/forum/actualthread.aspx?tid=456428&pg=1&hl=� |
|||
98
Yuwa
28.08.07
✎
12:10
|
Рассудим логически. Предположим, есть сомнения в возможности комфортной работы под УПП на таком количестве активных юзеров. Тогда вперед под САП и решаем вопросы по (87). Ищем отраслевое решение и партнера.
Мне непонятно стремление изобретать велосипед, т.е. писать средствами платформы управленческое решение. Я подчеркиваю - управленческое. Неважно средствами какой платформы- САПом, 8.1 или Билли Гейтсом. А автор обсуждает индексы, итоги и пр. Вспомнилась опять одна басня. Стесняюсь процитировать, чтобы не обидеть. |
|||
99
R41
28.08.07
✎
12:18
|
(97)Очень интересная ссылка, буду изучать
|
|||
100
R41
28.08.07
✎
12:18
|
Очень интересная ссылка, буду изучать
|
|||
101
Lind
28.08.07
✎
12:28
|
||||
102
Херрес
28.08.07
✎
12:38
|
(98) т.е. только из-за наличия СОМНЕНИЙ в возможности Вы предлагаете выбрать решение в 10 раз дороже, и даже отказываете в праве исследовать вопрос ?
Кроме того зачем писать решение - автор наоборот склонен использовать типовую. И зачем здесь подчёркивать "управленческое". Фишка как раз в том, что автор хочет окучить и фискальную бухгалтерию в той же базе |
|||
103
Diman000
28.08.07
✎
12:41
|
(101) Несмотря на заявления, что "смоделированная нагрузка на систему значительно превышает нагрузку, которая наблюдается в реальных условиях" позволю себе усомнится в этом.
Во-первых, там есть интересная строчка: "Каждый тестовый пользователь создает документы со своим уникальным набором товаров, то есть все движения документов записываются параллельно, не приводя к блокировкам" Во-вторых, там всего-то проводится документ Реализация товаров и услуг в оперативном режиме. Что станет с производительностью при наличии существенного количества перепроведений уже существующих документов в том же тесте? Я вам скажу что - в типовой реализации УПП все просто загнется. Проверено на гораздо меньшем количестве пользователей. Что станет с производительностью когда будут выполняться регламентные действия по закрытию месяца? Короче, это тест для базы оперативной работы менеджеров по продажам и не более того. |
|||
104
у лю 427
28.08.07
✎
12:48
|
+103 причем когда КАЖДЫЙ менеджер торгует СВОИМ товаром и товары не пересекаются
Вывод - тест является полной наё.кой лохов - типа смотрите как круто у нас... В реалиях все абсолютно другое.... УППырище в том виде, в каком оно есть - не взлетит... Для этого оно должно быть за ХХХХ человеко-лет переписано. По цене выйдет - тоже самое дорогое решение, которое будет СРАЗУ. |
|||
105
vogenut
28.08.07
✎
12:53
|
(103) Смотри (61). Это именно то что нужно.
(104) Ну если с разных складов торгуют, то блокировок не будет, даже если номенклатура одна и та же. |
|||
106
DK_L
28.08.07
✎
12:54
|
(100) вначале провести нагрузочное тестирование в одной конфигурации - сравнить время выполнения каждой операции (есть конфигурация 1С:ТестЦентр 1.0 ), затем разрезать конфигурацию при помощи периферийных узлов РБД на 2, потом на 3 и т.д части - настроить автообмен через оптимально выверенный промежуток времени( или/и COM(ADO,OLE),WEB-сервисы если нужно что-нить в онлайн режиме получать) и в итоге в каждой базе сидит не 400 активных пользователей, а по 400/количество разрезов при помощи РБД
|
|||
107
masky
28.08.07
✎
12:56
|
LOL
|
|||
108
DK_L
28.08.07
✎
12:57
|
(107) автоматизировал таким подобным образом крупную компанию в России
|
|||
109
DK_L
28.08.07
✎
12:58
|
+ ко всему если удаленные офисы имеются можно настроить репликацию
|
|||
110
Murdoch
28.08.07
✎
13:01
|
(1)
Система взлетит. Конечно при грамотном устранении узких мест. Мощности железа достаточно. Главное, что придется сделать, программно оптимизировать множество модулей. Но, раз вы запускаетесь на 140 пользователей то проблему сможете решать постепенно. У вас будет расти профессионализм и знание системы, вы будете последовательно выявлять и устранять узкие места. За 1 год можно подняться со 140 до 400, и не слушайте всяких умников. Если есть желание, все у вас получится. Вы же не собираетесь сидеть сложа руки и ныть про "тормоза". Я сам не раз переписывал различные модули готовых конфигураций, именно с целью повышения производительности, уверяю вас, скорость возрастает на порядки. Особенно это казается проведения, как документов по отдельности так и регламентных процедур, типа проведения партий товаров. Дело в том, что модули системы пишут простые программисты за невысокую оплату, поэтому судить их за "тормоза" бесполезно. Но можно переписать. Все будет зависеть от уровня ваших специалистов. |
|||
111
Murdoch
28.08.07
✎
13:05
|
(1)
В качестве примера, берем стандартную процедуру переноса данных из УТ в БП. переносим товарное движение, приход расход + все сопутствующие данные, номенклатуру, контрагентов и т.д. скорость работы при выборе периода в 1 месяц -- 6 часов выгрузки + 6 часов загрузки. Пишем свою процедуру переноса, через текст, естесственно переносим только самые необходимые сведения. результат -- выгрузка 30 минут + загрузка 40 минут. Настройка стандартной процедуры заняла 2 дня. Написание собственной 3 дня. |
|||
112
Diman000
28.08.07
✎
13:08
|
Короче, наш девиз: "Каждому менеджеру по своему складу и каждому пользователю по своей базе!"
|
|||
113
masky
28.08.07
✎
13:09
|
>Пишем свою процедуру
и так со всем остальным? |
|||
114
у лю 427
28.08.07
✎
13:11
|
(110) - верно. НО
- временные и финансовые затраты приведут к тому же результату, что и "хорошая дорогая мощная" система. ГДЕ ЭКОНОМИЯ? - потери при таком внедрении рассчитать просто невозможно... (106) делить базу на мелкие и трахаться, трахаться, трахаться... Держать штат объединителей-админов, копировщиков, эникейщиков и т.д. |
|||
115
Diman000
28.08.07
✎
13:16
|
(114) +
Еще подносчики вазелина понадобятся. И менеджеры по его оптовым закупкам)) |
|||
116
Херрес
28.08.07
✎
13:20
|
У него всего одно узкое место - это интенсивная отгрузка
только и делов-то что взять, копированием сделать свой док "реализация", который будет не универсален, но быстр Распределение по партиям, выделение авансов - ночью. (ну и что что как в 7.7 - весь мир так работает) Делить базу можно не трахаясь, благо что всё это нынче легко делается средствами платформы. Планы обмена рулят... Если уж упоминать всуе западные альтернативы - то почему сразу САП. Наверно Аксапту надо смотреть... |
|||
117
DK_L
28.08.07
✎
13:23
|
+(111)выгрузка изменений 30 000 документов проводится средствами РБД 2 минуты с небольшим , загрузка небольше 7 минут - это грамотно настроенный РБД и автообмен )))
|
|||
118
DK_L
28.08.07
✎
13:24
|
+(117) стандартный чуть модифицированный документ "Поступление товаров и услуг " в УТ(в УПП пораздутей чуть документ)
|
|||
119
DK_L
28.08.07
✎
13:26
|
+(117) - это количество документов филиала за полмесяца(дней за 10 иногда)
|
|||
120
R41
28.08.07
✎
13:30
|
(104)В нашей текущей базе 7.7, где сидят 150 пользователей мы полностью удалили все блокировки 1С и сиквела, т.е. перевели на уровень изоляции READ UNCOMMITTED. Естетственно чтобы итоги правильно считались ввели собственные - логические. Поставили счетчики для контроля времени ожидания блокировок. Ну так вот все 150 пользователей за день находятся в режиме ожидания 30-40 сек, при максимальном времени одной блокировки 0,5 сек. А мертвых блокировок нет вообще - результат правильно составленного алгоритма.
|
|||
121
masky
28.08.07
✎
13:34
|
(120) жесть. а ведь менеджер блокировок в сиквеле 10 лет разрабатывала мощнейшая корпорация. а тут на тебе.
|
|||
122
Midaw
28.08.07
✎
13:36
|
отложил ссылку в закладки, надо будет почитать
|
|||
123
Херрес
28.08.07
✎
13:39
|
(121) ну при чём тут это. В 7.7 это единственный выход, т.к. иначе одновременно документы проводиться вообще не могут
единственное - раз у них всё уже так здорово, то психологически перейти на УПП будет очень сложно |
|||
124
masky
28.08.07
✎
13:40
|
(121)>ну при чём тут это
а при том, что от 1С там остался интерфейс да хреновая структура таблиц. |
|||
125
R41
28.08.07
✎
13:57
|
(121)Требование о наличии собственного интеллекта еще никто не отменял - пусть они хоть 100 лет что-то пишут :)
|
|||
126
France
28.08.07
✎
14:17
|
(125) т.е, 1С и Микрософт должны убить себя "апстену"?... им уже сообщили?
|
|||
127
R41
28.08.07
✎
15:39
|
(126)Кто вам сказал такую глупость?
|
|||
128
Худой
29.08.07
✎
04:36
|
Кину полторы копейки тоже.
В общем, работал в 7.7. Вернее, писал там участок для коммерческой службы(складской учет, заявки, их отслеживание и все прочее...). Естественно, все это сразу, без всяких там перегрузок, ложялось проводками в бухию. Там было 360 пользователей в 6 городах России. От Москвы до восточной сибири. Техники, конечно, немеряно. Но, главное, работало. Была снесена полностью стандартная конфа. На 8.1, думаю, возможности такой реализации гораздо выше. Мне кажется, технические вопросы можно отодвинуть не на первый план. То есть их, конечно, стоит исследовать. Но они решаемы, очень даже неплохо, при правильной идеологии. Тем более, чем-то таким, на 7.7 пришлось заниматься, судя по некоторым ответам автора. Дальше. По поводу УПП, очень сильно сомневаюсь. Верно было подмечено, что разработчики не очень то сильно на оптимизацией работают. Их девиз - Работает на трех записях и ладно. Поначалу меня удивляло желание автора с уровня руководителя проекта вникать в какие то там нюансы, типа, индексов и прочего. Но, если заряжаться на серьезную работу, то, возможно, так и стоит. Чтобы потом быть в курсе идей, возможно, влияющих на производительность системы. Я, как правило, придерживаюсь такой стратегии. Конечно, чтобы поднимать такой проект, нужно очень хорошо разбираться в учете. Или иметь сильного постановщика-интегратора, который на ТЫ с бухгалтерией и с программистами. А это не очень частое явление. И, боже упаси, это отдавать на откуп франчам. Дальше. SAP - это, на мой взгляд, по соотношению цена-качество не идет ни в какие ворота. Делали, знаем. За те бабки которые уйдут на внедрение "счастливого будущего" на SAP, можно приличную, грамотную команду содержать для нормального проекта. И еще. Все же, думаю, для начала взять БП. Там для бухии, практически, есть все. И дописывать, пока идет внедрение этого модуля. По крайней мере, я бы так поступил, на месте автора. |
|||
129
R41
29.08.07
✎
16:25
|
Изучение ссылок дало больше оптимистичности. Посему продолжу выкладывание идей, что нужно будет сделать с УПП, чтобы она быстро заработала:
4)Написать свои правила RLS, нежели те которые стоят в УПП. Основная идея - не должно быть обращения к таблицам. Нужно понимать что запросы которые пишутся в RLS услвовиях добавляются во все запросы к базе данным по этому объекту. И поэтому лучше сделать не так как в УПП, а сделать проверку по фиксированному списку, который находится в параметрах сеанса пользователя (он в свою очередь заполняется при запуске системы). Метод мною проверен в свое время на 8.0 - торомзов не дает вообще. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |