Возник вопрос по возможности одновременной работы 500-700 пользователей в одной базе 1С 8.
Имеем предприятие из отрасли дистрибьюция, распределенная базы на 1С 7.7 (примерно 8 крупных филиалов + надцать небольших). Основные транзакции - проведение отгрузочных накладных общим количеством 4000 за 3 часа. ( самом крупном филиале 500-700 документов, по 30-50 строк с хитрой обработкой урезаний).
Рассматривается вопрос по смене платформы на другую, вариант 1С 8 не исключается. Одно из важных требований, реализовать новую систему в одной базе.
Так как опыт работы с 8кой имеется, то мнение не однозначное.  С одной стороны по формальным признакам у 8-ки все компоненты приличной ERP есть (трехзвенка, кластеры, управляемые блокировки), с другой стороны на странице с внедрениями  http://www.1c.ru/rus/partners/ckp-upp_top100.jsp, в основном распределенные базы.. в решениях видно в одной базе варианты 200 пользователей, или около того.
Пообщавшись с разными франчами, информация разная. От «не будет работать» до «система потянет, если заказать в проекте оптимизацию в проекте за ХХХ руб».
Понятно, что по железу ограничений значительных нет. Нужно два-три-х серверов в кластер, то заложим (в других ERP требования к железу не меньше).
В общем-то интересует мнение коллег, кто реально работал и сталкивался с системами на 1С 8, с более 500ми пользователями 1С в одной базе, и массовым вводом документов  до 20 тыс. документов реализация за 3-4 часа..

Платформа потянет, если писать свою нетленку

(0) у нас в базе ГК 800 пользователей - это норма. 8.2.16, толстый клиент, самописька (адова каша из кусков типовых + самопальные подсистемы, тысячи их - и тех, и других).
Платформа потянет еще и не такие объемы, а вот коробочные типовые решения без оптимизации - сомневаюсь.
Другое дело, что на сколько реально надо всех загонять в одну базу - большой вопрос, поскольку это все яйцы в одно корзине: встал один сервер БД и отказали ВСЕ сервисы, ВСЕ 800 человек курят бамбук. Это плохо. У нас, к примеру, на этот год запланирован масштабный проект по разделению функционала этой базы на разные с разнесением по разным серверам БД и приложений. Чтобы все разом не падали

http://www.cnews.ru/news/line/index.shtml?2010/05/24/392723

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

А вариант управленческая общая база на 8-ке и оперативная торговая на 7-ке не рассматривается?

ПоВангую:

1) Ветка на 400 постов.
2) Обязательно подтянутся Гилевы и Софтпоинтовцы, рекламируя свои "бесплатные" поделки.
3) Будет много советов, 96% абсолютно глупых.
4) Автор обязательно будет хвалится неебически дорогими серверами.
5) Че еще? Ах да, автор обязан пропасть и мы никогда не узнаем дальнейшей судьбы.

В посте (2) - практически квинтэссенция всей будущей ветки...

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

p.s. Почему УТ такая шустрая? Потому что там РегистровБухгалтерии нет.

Интересно узнать причины объединения баз в одну.

ТС, у вас что-то с организацией работы не так...
в принципе, и мы дошли до таких объемов (600-700 реализаций), только у нас такое количество реализаций делается не за 3-4, а за 8 часов... но есть куда расти. в том числе и оргмерами...
ну и учесть (2), конечно...

то (5)
4. Серверами то хвалиться не буду. Т.к. их покупка явно будет уже после начала проекта и определенности с платформой.
5. Надеюсь не пропаду 8)

Уж полночь близицца, а Германа все нет.

Автор, бери УТ10.3, вырезай оттуда НДС регистры - и тока в путь!

(10) кстати, ты хочешь all-in-one,  или чисто оперативную систему?

гы гы гы..

миста это самое место где такие вопросы решать..

http://fragster.ru/perfomanceTest/
бывает и вот так:
http://wstaw.org/m/2013/03/05/2.png

по тесту Гилева 16 баллов в связке

вообще - вполне работать будет

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

в любом случая я-бы сделал как минимум две базы, одну чисто для руководства с отчетами и вторую для всех

(18) по тому что
1. разная оптимизация, в одной запись в другой чтение
2. у руководства ничего не висит и это хорошо :)
3. безопасность сводных данных от низов

(19) для руководства будет полезна плюшка 8.3 под названием "кубы" :)

(18) А я бы наделал распределенок в разрезе Организация-Склад.
А в документ ПеремещениеТоваров впилил бы кнопку "Обменяться".

(19) Руководство может сходить покурить, а вот продажники должны продавать.

(21) эээ, зачем кнопка?

структура 1 - 1 - * или если перифериек много (больше 20), то 1 - * - **

(23) Чтобы "Сразу, немедленно, если надо ПРЯМО сейчас, а если не надо - шут с ним, уйдет с регламентным"

где в первой - работает "центр", средня занимается непрерывным практически обменом, а в правых - работают операторы

у нас (60 перифериек) - так

(26) У нас - также было.

(25) а, это у нас для всех метаданных через веб сервисы сделано, да

(28) Только у нас периферийки - это реальные периферийки по регионам, а не виртуальные Организация-Склад.

(25) у нас лаг прохождения данных в среднем час

вообще много перифериек не нужно, если правильно написаны управляемые блокировки

(14) А зачем в обработке галки "сервер 1С" и "сервер субд"

(33) это если у тебя 2 сервера - делай 2 строки, в одной - описание сервера 1с, в другой - сервера СУБД. а если один сервер - то ставь 2 галки в одной строке

(7) А с какой стороны УТ шустрая? Сколько с ней не общался - тормозит безбожно... Хотя, конечно, побыстрее УПП, но это не ее заслуга, это беда УПП...

(35) Сколько с ней общался - шустра как заяц.

(0) Зачем мучить бедную одинэсину ???
Берем Оракл и ... что за проблема ? Хоть 50 тыщ пользователей подключай. А стоимость разработки не такая уж космическая будет (по сравнению с сексом вокруг оптимизации одинэса), зато база будет жить с момента начала до скончания веков, пока место на серваке чисто физически не закончится.

to (2)
А зачем делить на части для надежности ? Есть же вариант кластера ? Или в 1С он толком не работает ?
Вообще кто-нибудь кластеры на 1С использовал, или это маркетинг, и все стопориться на блокировках и от кластера толку нет ? С другой стороны надежность-то должна была вырасти..
to (9). И сейчас 600-700 реализиций в день есть в крупном филиале на 1С7.7. Прямые запросы 1С++ рулят. Вопрос все филиальные базы слить в одну (тогда будет 4000 накладных в день), тут то вопросы и возникают потянет ли 8ка. А про три часа, потому что торговые агенты заявки сбрасывают целый день, но пик обработки получается с 15.00 до 18.00. Т.к. после 18.00 уже маршрутизация доставки, потом передача на склад.

(34) Опубликовал, теперь бы понять бы что эти попугаи значат

(38) Проблема в блокировках на стороне SQL сервера.

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

(38) Необязательно. К примеру есть оперативные данные которые нужны для выписки документов (текущие остатки/взаиморасчеты)
А есть данные нужные для планирования, т.е. данные за последнии 3-5 лет

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

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

(38) у меня 4000 реализаций в день, и что?

(19)Подскажи может быть такое когда все работают В УТ очёт собираться корява тк кто что то пишет в регистры, когда народ не пишет в регистры те вечером отчёт собирается нормально? Как это можно обойти кроме как делать ещё одну БД?

(20)Что такое кубы можешь объяснить?

(45)
wiki:OLAP

(1)(2) и др. +1

(29)(30) Вы это, на сантиметры уже переходите, мозг народу не ломайте :)

(37) >А стоимость разработки не такая уж космическая будет
Считал? Думаю, заблуждаешься.

кстата, начинает собираться статистика, что, например, РС на МССкуле работают сильно медленнее, чем на постгре. А на ДБ2 никто не опубликовал ничего :(

(0)Потянет. Причем даже без особых финтов по оптимизации. Сейчас речь уже идет о тысячах пользователей в одной базе, там действительно нужны танцы с бубном. В вашем же случае - достаточно хорошего железа, плюс - грамотная команда на внедрение. И вот с командой - самый большой затык, во первых - она сама по себе будет стоить дорого, т.к. каждый участник будет с ЗП выше рынка и 2-ое - ее просто сложно собрать, т.к. люди, после участия на рядовых ролях в подобных проектах - обычно уходят на повышение и с подбором вед. разработчиков и тех. РП - всегда проблемы.
Т.е. они то ими были, но сейчас они нач. отделов, эксперты, РП и на проект не идут.
Это все надо воспринимать как данность и не верьте франчам, которые будут обещать другое.

в прошлом году внедряли ут 11 на 100 пользователей
сначал полёт был нормальный, ессно с учётом серверов и кластеров, потом подцепили (без моего участия) ещё 3 филиала, в итоге система просто отказалась работать
в итоге клиент перешёл на DAХ
я предлагал переписать ядро системы, но меня никто не слушал, ибо я не руководил процессом
по итогам, DAX рулед

(52)А конкретнее можно про ядро, что именно переписывать то собирались :) ? Может просто подорвали доверие Заказчика и он начал все на свой лад там делать? Жадность... обратились бы к спецам и 1С, как бренд - не потерял бы еще одного клиента :(

(42) тем более непонятно почему зависимость нелинейная

Кстати а почему в файловой версии не работает?

{Справочник.Тесты.Форма.ФормаЭлемента.Форма(76)}: Ошибка при вызове метода контекста (Выполнить)
   Задание = ФоновыеЗадания.Выполнить("Тестирование.ВыполнитьТестирование");
по причине:
Менеджер заданий не активен.

(52) предлагали внедрить режим разделения данных, выделить один склад в отдельную базу с репликацией, и немного переписать блокировки
я в принципе всегда относился к DAХ c высокомерием, но он почему-то справился

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

(56)Активно использовали РЛС?

(57) к сожалению, было такое, но, опять же, DAX справился

(55)Разделение данных не взлетело бы :( Вроде обещали поправить, но еще пол года назад - была довольно глючная штука. Случались косяки в передаче данных и мог очистится параметр разделения, как итог - становились видны все данные базы.

(57)

Отработаю за Вангу:

Активно пользовали форму списка номенклатуры в связке с остатками, резервами и ценами.

И не включали мозх.

(60) ты, как всегда, зришь в корень ;)
кстати, я тогда умело воспользовал твои советы по ДС, помогли, пасип

(58)DAX система менее гибкая и там другая архитектура. УТ 11 при правильной настройке - справилась бы. Это вечная проблема выбора универсальность/сложность или специализация/простота.
(60)Ну это совсем жесть :) Не надо так плохо о разработчиках...

(60) В каком смысле не включали мозх? Тупо использовали типовую вместо самописки? это имеешь ввиду?

(61)О как! Ну тогда тут конечно вообще без вариантов :) А потом - "1С не тянет, 1С - фигня!" А с другой стороны "Фирма 1С - козлы, разработчиков за идиотов считает, не дает инструментов для прямой работы с данными... Дайте нам хинты на SQL и мы мир перевернем" :)))

(64) ну я же говорю, не я руководил процессом
на 2-х филиалах работало круто
когда пошли в ход ещё три, система встала

(65) Я нашел тебя, бро...

v8: ТЗ или ДС


Файловая.

хе-хе-хе

Ну и запрос уежский, сам по себе адов, так еще на файловой, так еще и RLS поди дает ему "просраться"

Не знаю, что там декларирует 1С, но юзать какое-нить КОРОБОЧНОЕ решение (даже на мощном железе) для оперативной работы 800 пользователей - имхо бред.
.
выпилили бы самостоятельно оперативную базу с минимально нужным функционалом безо всяких задротных ineextr и возможно все взлетело бы.

(43) О, уже меряются! А у нас 2000 в час, в пике. на 7.7 и чо? :)

(54) зависимость нелинейная - потому что при многопоточной работе начинает упираться в разные места

на файловой не работает, потому что там управлять "потоками" уже так просто, как в клиентсерверной фоновыми заданиями - не получится. в файловой все фоновыезадания в 1 поток исполняются. после того, как будет готова 2.0 с новыми алгоритмами (учитывая советы Гилева) и глобальным обменом результатами (а не только публикацией на сайте) - начну делать тест для файловой через запуск множества сеансов - это будет версия 2.1, сами алгоритмы менять не буду.

провалы на 64 и 96 потоков скорее всего потому что сервер решил что-то поделать. или маршрутизатор.

проверка синхронизации что на 200 потоков показывает?

(70) ну тогда заблокируй выбор, чтобы не смущал. А то попа есть, а слова нет.

(71) Нет, потому что 2 раза делал тест и провалы стабильно. т.е. не случайные. Тем более на серваке никого нет, т.е. некому отвлекать его

(72) Это как?

Вот третий раз отработал. Картина такая же.
http://fragster.ru/perfomanceTest/testDetails.php?guid=358d9dac-945a-11e2-8dae-003048f00d88

(72) нашел, только не понял что должно показать?
Количество потоков 200
Момент синхронизации 24.03.2013 17:06:09

и всё никакой инфы

(75) если потоки синхронизируются плохо - то обработка это показала бы. при плохой синхронизации получается так, что некоторые потоки стартуют раньше/позже и соответственно не весь период теста конкурируют с остальными потоками

(74) хм. т.е. проседает всегда на одном и том же месте? тогда вероятно это эскалация блокировок, вот она и нашлась :)

попорбовал 5000 потоков, по тамауту вылетела

Ошибка выполнения запроса
по причине:
server_addr=tcp://ххх:1560 descr=Ошибка сетевого доступа к серверу
(Windows Sockets - 10054(0x00002746). An existing connection was forcibly closed by the remote host. ) line=1041 file=Src\DataExchangeTcpClientImpl.cpp

(77) так я не понял проблема на чей стороне :)

(78) у меня и на 1000 вылетало, на 500 еще работало, правда с разбросом в 3 секунды
(79) тут варианта 3 - в 1с и его диспетчере блокировок, в скуле, в оборудовании

а можно попросить нажать на "опубликовать" еще раз - я там в модуле веб сервиса на стороне сайта кое-что поменял - по идее работать должно так же, но...

(81) последний тест?

(82) ну да

попозже , сейчас что то связи нет

хорошо, что это все не у меня.

обновил последний тест

У меня кстати 450 потоков еще хавает, а на 500 ошибка выскакивает "Рабочий процесс не найден"

460 уже разбил на 2 потока 424 и 36

(86).1 т.е веб сервис работает, не отвалился... это хорошо!
(86).2 если рабочий процесс сервера 1с - один - то повидимому в районе 500 соединений - предел для него.
(87) ну, это неплохо, 424 было по времени раньше же? погрешность измерений на 112 потоках при таком разбиении должна быть маленькой, т.е. графики с падениями на 64 и 80 отражают реальную ситуацию, как бы странно это не было :)

(88) Ну рекомендации 1С, для 64-х битной системы держать один рабочий процесс, и он сам будет рулить.

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

на самом деле интересно, сколько теоретически может быть соединений, у меня 500 проглатывает, 750 - уже нет, причем рабочих процессов 3 32-битных...

Из переписки видно что (2) как раз ценная информация, что потянуть может. Только уже решили соскочить с единой базы на раздельные.
(90) попробовал твой тест, не понял что за показатели "количество пользователей" и "удовлетворенность пользователей". на что они влияют, и при каких параметрах скрен шоты выкладываются.
Я на своем текущем серваке протестил 5 пользователей, оценка 4: получилось по отчету "Итого/итого:6354"

(91) эти параметры ни на что не влияют :) это для остальных - типа сколько на таком сервере 1с/субд работает юзеров в продакшене и насколько их удовлетворяет скорость работы

(74) AMD Opteron 8354 2.2GHz надо бы заменить. 6 лет для процессора - уже глубокая старость.

(93) На что? Да и смысл? Замена ради замены?

6 лет еще нет, они вышли 9 апреля 2008 года wiki:Barcelona_(AMD)

(94) Нет. Ради безопасности и производительности.

(38) ...А про три часа, потому что торговые агенты заявки сбрасывают целый день, но пик обработки получается с 15.00 до 18.00. Т.к. после 18.00 уже маршрутизация доставки, потом передача на склад

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

(96) безопасность?

(98) Ну да. Сколько стоит час вынужденного простоя этого сервера?

(99) А почему он должен простаивать?

И да 0 рублей 0 коп, ибо оперативная база - файловая 7-ка. А на 8-ке ЗУП, БП и управленческая нетленка

(101) Все понятно.

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

(102) Оперативную файловую 7-ку раз в полгода сворачиваете?

(103) в год

на НГ режем по 4 квартал

ктойто мне результаты поломал своим копошением в коде? :)

хотя то, что на 999 юзерах оно еще шевелится - это круто!

http://fragster.ru/perfomanceTest/testDetails.php?guid=4713fb2a-94a6-11e2-8b0d-00155d00bd07

Сделал ради прикола 10 рабочих процессов

999 вылетело, а 750 прохавало
546 - 24.03.2013 22:24:06
204 - 24.03.2013 22:24:07

второй прогон
593 - 24.03.2013 22:25:22
157 - 24.03.2013 22:25:25

Т.е. как бы небольшой прирост есть по сравнению с 1 процессом, но не в 10 раз

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

(111) ну с одним процессом он и на 500 обычно терям рабочий процесс, а тут на 750 что то пытается сделать. Т.е. прирост в масштабируемости, а не в производительности

(38) забавная формулировка вопроса: "зачем делить на части для надежности". Кластер серверов 1С предприятия, а БД-то одна.

(113) Ясно, глянул схему кластера. Действительно СУБД одна, и на несколько серверов не размазывается ни как.. Получается потенциально узкое место в производительности для дальнейшего масштабирования.

(114) wiki:Oracle_RAC

(114) все 700 рыл в одну базу не нужно тебе. В итоге будет у тебя база на энцэть терабайт и резервное копирование - жопа, развернуть бэкап - жопа, копию организовать - жопа. Потому что 100500 терабайт - этот тебе не хрен собачий, их, как минимум складировать где-то штабелями надо. А главное - в твоей базе будет 100500 различных функциональных блоков, которые промеж себя только нормативно-справочной связаны, но изза них ты должен каждый чих продумывать, чтобы какие-нить чуваки, которые закупкой оборудования занимаются, не нагибнули блокировками каких-нить товарищей, которые с поставщиками товаров хитрые договоры заключают, или еще кого-нибудь непричастного.
Любая крайность - есть зло в чистом виде. Единая база учета все на свете (она даже не зря в такую аббревиатуру собирается веселую - ЕБУ) имеет, кроме плюсов, подарочный бонус-пак минусов. Потому что это крайность. Туева хуча маленьких баз, в каждой из которых своя маленькая функция - такая же история (попробуй потом в этом зоопарке разберись, когда ты их даже по пальцам пересчитать не можешь).
Нужна какая-то золотая разумная середина. Но в любом случае 700 пользюков, в едином порыве в одну базу херачащие свои байты, - это крайность и юношеский максимализм. Задави это в себе (ну или в том, кто это придумал).

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

(114) у Софтпоинта есть решение вроде, где они это делают. Анонс на семинаре давали. Правда я боюсь представить скольо они попросят за него...

9117) и тут встает вопрос - где она эта золотая серелина? и на первый план выходят не технические вопросы субд/кластеров/хренястеров - а вопросы разумной организации всего это хозяйства - не только в техническом плане, но и в управленческо-организационном... грамотно разделить базы по возможно более непересекающимся задачам и прочее.. - вот тут вот и затык.. - кто это все делает? планирует? рисует? нихз непонятно...

(116) Откуда такие глубокие познания про "700 рыл в одну базу" и "100500 терабайт"? Это там хранить раскадровку всей мировой классики? Сам писал приложение или как?
У меня в одной базе 750 пользователей. Вроде, нормально отрабатывает. И там "чуваки, которые закупкой оборудования занимаются" и не только оборудования. И в цехах заявки в любое время делают и отслеживают роеву тучу движений реально.
Или "с поставщиками товаров хитрые договоры" валят напрочь всю базу? Тогда можно озвучить, если не секрет, на какой степени "хитрости" договора стоит останавливаться, чтобы система не рухнула?
Насчет "обновления даже самой маленькой вот такой вот куйни".
Есть регламент. И остановка на 5-6 минут чтобы "в заказ поставщику добавить колонку" например, ночью еще никому не вредила.
Все же интересно какой опыт имеется для таких пафосных заявлений. Зачем пугать народ? Может быть, стоит самому "начали юзать поиск, читать мануалы и перестали рассказывать сказки" и, может быть, самому что-нибудь написать?

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

(121) Я не считаю коробочные продукты верхом совершенства. Это примеры использования поставляемых платформ. Насчет "штатников" все решаемо. Какие тут проблемы?

Автор, в (2) уже все сказано
От себя добавлю, возможно следует посмотреть в сторону ЦКТП http://v8.1c.ru/expert/cts/cts.htm
Если выберите 1С, то без оптимизации вам точно не обойтись.

(88) напиши мне в почту и я отвечу на второй вопрос

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

(124) какой вопрос?

Короче глядя на внедрение в Световых Технологиях, а там сумма внедрения более 1.6 млн. евро + железо более 300 тыс. евро !!! Думаю у Вас эти цифры нужно на 2 помножить и тогда взлетит.
Думаю у Вас обороты это позволяют это сделать ? Лярдов 50 в год наверно прокручиваете  ????

(126) предел количества соединений на один rphost

(116) - Да ты писАтель, ядрёно пишешь !! Твой абзац спёр к себе.

(129) Лефмихалыч очень крутой чел ! Еще больше его зауважаю когда в этом списке увижу: http://www.magnit-info.ru/about/structure/

(128) непонятно, почему через почту, но написал...

(0) у нас как раз в районе 700 пользователей работает. В момент внедрения были адовы проблемы с платформой. Не жила она с кластером никак. То рпхосты память отжитрали навсегда, то какие-то вечные "ошибки формата потока". Но 1С оперативно подключилась и допилила платформу.

База представляет из себя смесь БП 2.0 и УСН. По мере нарастания объемов данные случаются затыки которые оперативненько оптимизируем. Очень помогает КИС в этом плане.

(132) КИС - ?

КИП, наверное

ой. ЦУП =)

вот это вот

http://v8.1c.ru/expert/pmc/pmc_overview.htm

(0) Приведу простой НАШ пример. http://v8.1c.ru/expert/cts/cts-202-004.htm Начинали с 400 пользователей, затем стало до 1500 в пиках продаж. Плюс куча не-1с приблуд для дополнительных сервисов. Спокойней такой проект делать в рамках ЦКТП. Ибо руководство с высокой вероятностью не будет слушать Ваше мнение, даже если оно правильное. А вот авторитет фирмы 1С в этом деле поможет. У нас есть опыт и с более крупными базами. Типовые допилить до нужных потребностей можно и нужны.   Надо понимать, что дело тут не в 1С, а кто именно внедряет, откуда у него руки растут.
(5) обламайся, здесь нужны не утилиты а мозги :)

(5) кстати, ты напрасно путаешь нас с Софтпоинтом.
Разница принципиальная - они берут деньги, а мы - нет.
Мы берем за результат, а не за утилиты.

(138) Вот честно - я охотно верю, что вы (как Гилевы, так и Софтпоинтовцы) несете добро всем, но вот автору я бы посоветовал бы договориться за деньгу хорошую договориться с @Fragster-ом :-)

Ну вот. Как и предполагал, ничего конкретного по поводу глубоких "познаний" в (116) не ответил. Обиделся, мальчик?

(122) да вообщем никаких. Хотлось узнать - самописка или решение из коробки... Сделал вывод что скорее самописка чем коробка..

(139) ну посоветовать то ты конечно же можешь, процитирую тебя же "Будет много советов, 96% абсолютно глупых."

(0) Потянет, если разрулить узкие места.

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

(143) и будет конкретный человек, который будет нести ответственность за разгуливание этих узких мест, а не перевод стрелок админов на кодеров и обратно )))

(141) Если делать реально большую систему, то писать только после приличного разбора задачи самому.
Из коробки работает на нескольких сотнях записей, и ладно. Значит продавать можно.
Например, переписывать пришлось документооборот. Там после пары месяцев работы документы стали открываться по 3-4 минуты. Пришлось в код лезть. Мама дорогая! Сплошные запросы в цикле. После переделки за 1-2 секунды стало открываться. А так по нормальному, все бы снести и написать нормально систему. Узкие места не только в выборках данных, но и в структуре.

(146) Документооборот какой версии? У нас вроде летает (несколько сотен пользователей)

(146) угу, и ждать 2 года пока пишут нетленку.
Лучше сразу запуститься, а потом допиливать.

(137) 1500 пользователей - масштабируемость
3000 заказов по 2-10 строк - производительность

оптимизировалась производительность и результатом стала масштабируемость ?

(148) Если бы хозяева капитала конторы знали, что их ждёт с сырой прогой, никогда в жизни как минимум без тестирования не переезжали на сыряк.

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

(147) Вопрос правильный. Но не совсем.
Правильнее было бы - "Документооборот какой фирмы?"
(148) Такое тоже может быть. Главное, понимать на что подписываешься, когда "сразу запуститься, а потом допиливать". Чем подкупает платформа 1С, это тем, что на ней, вроде, быстро можно набросать прототип системы.

(150) с несырой ждало бы тоже самое только на 1.5 года позже.

(0) Сталкивался, но не с 1с. MSSQL. Ядро системы уже не задействовалось(чересчур тормозное) , все работало на хранимых процедурах с оптимизациями.

(150) Так хотя бы срок бардака уменьшился в несколько раз. Это уже плюс.

(154) Афигеть! Видать разработчики очень круто спроектировали хранилище, а вот ядро "чересчур тормозное"? Интересно, как удалось вокруг ядра обход устроить?

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

(157) Регистры бухгалтерии - это вообще АДова поделка у 1С )))) 500 счетов и 4 субконто и все дохнет ))) хоть об аптимизируйся.

(158)Он не про "АДовую поделку у 1С" пишет.
(157) А откуда объемы терабайтные? Я никак в толк не возьму, когда пишут про такие объемы. Что там такого огромного, даже на миллионных записях?

(159) Для ускорения доступа к данным база денормализовывалась, вот и объемы. А вообще, конечно, роль куба учетная система выполнять не должна, на это есть кубы. А без денормализации там была бы просто ...

(156) ну, независимые РС - то еще... особенно, если не думать с самого начала...

(160) Суровые вы ребята.

(160) Извини, что докапываюсь. Я делал что-то такое для чужой системы на ORACLE. Там тоже пришлось базу денормализовывать. Но эти самые таблицы уже теперь ваши и тригеры, заполняющие их, ваши. Но, все же, это набор ссылок и каким то образом уложенные тригерами данные. Вот и не складывается у меня в голове все эти биты и байты. В итоге, это гигабайты будут. И даже не десятки гигабайт. Это не так много.

(138) То есть вы не берете денег?;) Цель любого бизнеса зарабатывать деньги, кто говорит обратное тот лукавит. А насчет утилит - ну найдите мне пожалуйста утилиту для кластеризации СУБД MSSQL + 1C8?(http://softpoint.ru/products_id15.htm) Я скажу что пока что она есть только у нас, и в исследования было вложено очень много денег. Почему же она должна раздаваться бесплатно?  Хотя некоторые компоненты мы раздаем бесплатно.(например для параллельных вычислений для 1С)
(0) Если написать с нуля то однозначно все потянет. Сейчас к примеру запускаем проект на 1200 работающих магазинов в одной БД.

(164) а зачем только магазинов в одной базе? проблем со связностью нет?

у нас в организации примерно 500-600 пользователей онлайн + ТА с КПК льют заказы. Правда используется риб с фильтром по подразделениям в итоге все сливается в одну консолидированную базу. Если не жалеть денег на дисковую подсистему под сервер БД то и больше будет тянуть без проблем.

(164) Не хочется загонять Вас в угол. Много Вы платите за пользование википедией? Может быть Вы платите за постгресс? Кому?
Мы потратили силы на разработку инструментария, потому что сделали его прежде всего для себя. Но мы не жмотимся и даем пользоваться бесплатно нашей системой. Ферштейн?

(164) Найдите хотя бы одного человека, который бы купил наш инструментарий, например http://www.gilev.ru/querytj/, слабо? Ну тогда и не надо о других судить по себе!

9167) я не понял в чем холивар? вы даете бесплатно. а софтпоинт - платно..? ну так разные модели бизнеса. или что?

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

(170) мне тоже хочется оставить после себя хороший след. но чем дальше - тем злобнее становлюсь...

(170) я вот как на снеговика переползу и вдруг будет все плохо - я к вам приду... за хорошим следом ;-0

(170) Когда станете собственником и будете отвечать не только за себя но и за людей которые работают в компании думаю вы поменяете свою точку зрения. Впрочем спор бесмысленный , каждый вправе делать что ему хочется. Обвинять в бизнесе кого либо за то что берут деньги за свою продукцию - как то странно. А насчет оставить след - ну так это хорошо. Только для этого вовсе не обязательно дарить все бесплатно и тому множество примеров.

(168) Мне кажется у Вас начилась звездная болезнь с некоторых пор, судя по вашим непродуманным высказываниям (не только в этой ветке).
Ваш сервис "бесплатен", но абсолютно неприемлем большинству крупных компаний - так как ломает всю их безопасность.
Я не говорю о его полезности, в чем принципиальное отличие от ЦУП и других продуктов на рынке(кроме бесплатности))?
Основное достоинство мониторинга PerfExpert - его способность анализировать данные из различных источников и находиться закономерности.
Ваш "сервис" просто отображает данные из источников (технологический журнал, счетчики, лицензии) - но специалистов на рынке, которые могли их обработать очень немного. Поэтому мое личное мнение - вы пытаетесь расширить канал продаж через сервис, при этом популяризируя его мнимую пользу.
Опять же подчеркиваю, это мое личное мнение.

(173) понятно, значит не оспаривать схему раздачи постгреса ума хватило :)

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

кстати, мне дубину вернули и я бдю

(175) Ума хватило, слава богу:) Я мог бы вам рассказать о различных лицензионных политиках распостранения продуктов и о принципах формирования цены для продкутов предназначенных для ограниченного количества корпоративных клиентов. Но , не буду. Как то вы в демагогию скатываетесь, переходите на личности. Мне это не интересно.
(176) А вы не грустите;) Я желаю вам оптимизма и радости и главное больше позитива!

(0) Что мешает обратится напрямую в Интелком?

Минуя всяких посредников которые и в глаза -то не видели 1000 пользователей

(137) сейчас они то же на 1С или друга платформа ?

(182) ну это вообще "динамично развивающаяся" компания и у них  много планов, а пока да, 1С v8, и думаю что еще какое то время поживет :)

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

Честно говоря система у них сделана круто !

(147) меряться документооборотами - последнее дело, т.к. в нем, кроме одаренного кода еще очень много зависит от настроек и объемов (что в общем - следствие одаренного кодинга). Например, если у тебя несколько миллионов внутренних документов, с десяток разных видов этих документов, да еще и папок хренова туча, то новая фишка с дескрипотрами выливается в адов ад при добавлении пользователя в группу - ДО по сути кидается пересчитывать права для всего, до чего дотянуться может. Причем стэк вызовов там едренячий и на начальных этапах-то там накладываются всякие отборы по видам и прочему, но потом все это передается через 33 колена в процедуры, которые просто выгребают все дескрипторы по виду документа и начинают отапливать серверную процессорами.
А вот если видов документов два-три и они не разбросаны по разным папкам, а под каждый своя папочка, то все зачипок - дескрипторов мало и при этих диавольских пересчетах все быстро происходит.

(184) там много интересных решений, и на 1с в том числе, но к сожалению мне позволено рассказать существенно меньше чем хотелось бы
могу сказать, что там много "путей заказа товара"

Хорошая дискуссия пошла..
(137) ЦТКП как я понял из ссылки, это франч подготовил как минимум одного специалиста по "1С:Эксперта по технологическим вопросам" и с помощью него оказывает услуги по оптимизации быстродействия.
А сама фирма 1С причем в этом случае?
(180) А чем примечателен Интелком ? Тоже один из франчей + железо ?

(187) Наконец-то ТС объявилсо, Вы уважаемый лучше ответьте на (127), очень интересно бюджет имеет у Вас какие-то рамки ??? А то может Вам Выделят 200 тыщ. зеленых и скажут хотим шобы все улетало ))))

(188) Этого вполне может хватить. Ну, если только железо.