Каково максимальное количество пользователей в 8.3?

1. Fox-trot 156 22.12.16 22:14 Сейчас в теме
Сабж собственно
К моему сожалению на сайте производителя и в документации ответа не нашел
По теме из базы знаний
Ответы
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
4. ture 606 23.12.16 09:25 Сейчас в теме
(1) более 3 кусков. Но если они полезут в одно горлышко, то начнут дергать поддержку. Не важно количество, главное их рассортировать по табличкам и транзакциям (и убрать отчеты обо всем сразу).
5. dmt 66 23.12.16 09:30 Сейчас в теме
(4) 3000 одновременно работающих?
6. ture 606 23.12.16 09:33 Сейчас в теме
8. dmt 66 23.12.16 09:40 Сейчас в теме
(6) Гм. Это несколько меньше 3000. :-)
10. ture 606 23.12.16 09:44 Сейчас в теме
(8) ну, да это меньше, боюсь только, что не на долго.
эти гады лезут со всей страны через терминал в любое время суток.
44. collider 25.01.17 10:19 Сейчас в теме
(1) 5000 человек в "деловых линиях", конец 2013-го года
http://v8.1c.ru/expert/cts/cts-218-001.htm

Недавно ещё появилась запись о 9000 человек, но это скорее маркетинговый ход. Ведь, эти 9000 человек были распределены по огромному количеству отдельных серверов и баз.
http://v8.1c.ru/expert/cts/serv.html
2. Kamikaze43 11 22.12.16 23:29 Сейчас в теме
1С 8.3 УТ 11 - 1250 активных пользователей на реальном предприятии (розница+инет-магаз)
7. nihfalck 23.12.16 09:38 Сейчас в теме
(2) 1250 активных - это одновременно подключенные и активно вколачивающие данные/дергающие отчеты?
9. ture 606 23.12.16 09:42 Сейчас в теме
(7) это как меряться разными частями тела. Пусть они лучше ничего не делают, т.к. ели они начнут "работать" то просто зря повесят все, что найдут.
3. alxarz 31 23.12.16 09:20 Сейчас в теме
максимум неограничен, вопрос что они делать будут - если просто висеть в базе это одно, а если каждый по 10 документов в минуту записывать по 10 строк каждый, то это другое...
11. Fox-trot 156 23.12.16 11:32 Сейчас в теме
если верить профайлеру то 1с запрашивает максимальное количество 2147483647 пользователей
причем делает это не оптимально: вместо Количество(*) выбирает полный список. Лохи, хотя может я чего-то не знаю или пропустил
если такие проблемы с большим количеством пользователей, то может есть смысл логиниться от имени одного-двух пользователей в зависимости от ролей, а разделять потом по какому-нибудь своему справочнику, например "Пользователи". но тогда придется свой журнал регистраций рисовать, хотя это не проблема канешна
12. 1qazxsw21QAZXSW2 4 23.12.16 12:53 Сейчас в теме
Формально количество пользователей не ограниченно, но на доле все будет зависеть от производительности сервера
13. Fox-trot 156 23.12.16 14:11 Сейчас в теме
(12) не только, капитан
чтобы узнать количество пользователей нужно выполнить код
ПользователиИнформационнойБазы.ПолучитьПользователей().Количество()

что в свою очередь сначала создает массив всех пользователей и только потом рассчитывается количество, что напрочь вешает сервер. а ведь было сгенерировано-создано всего-то сто тысяч записей
14. asved.ru 36 11.01.17 20:25 Сейчас в теме
(13) А вы сначала купите всего-навсего сто тысяч лицензий, а потом уже и анюзабл кейсы постить можно.
15. Sergey.Noskov 1376 12.01.17 08:11 Сейчас в теме
если правильно понял, интересует НЕ сколько одновременно работающих соединений потянет 8.3, а просто максимально возможное число записей в списке пользователей ИБ?
Думаю поэтому поводу переживать точно не стоит.
Проверка кодом "ПользователиИнформационнойБазы.ПолучитьПользователей().Количество()" не показательна вовсе, для чего она?
16. Fox-trot 156 12.01.17 12:07 Сейчас в теме
(15) не показатель чего? количество показывает, чего там еще показывать?
интересует именно максимальное количество одновременно работающих, которое в свою очередь наверное не может превышать максимальное количество пользователей в иб вообще
(14) у вас весьма оригинальный подход к решению вопроса - сначала покупаем, потом тестируем, если не подходит говорим снабженцу "отнеси обратно" :)
17. Sergey.Noskov 1376 12.01.17 14:18 Сейчас в теме
(16)
не показатель чего?
в рамках вашего вопроса - вообще не показатель, ну долго выполняется этот метод, это никак не помогает получить ответ о максимально возможном числе работающих пользователей. Да, в платформе нет быстрого способа подсчета числа пользователей ИБ, можно либо прямым запросом (если в рамках теста, то можно), либо делать связку один-к-одному со справочником конфигурации "Пользователи" и считать число элементов в нем.
Из своей практики могу сказать, что текущие версии 8.3 на высоконагруженных системах работают достаточно стабильно при 1000-2000 активных соединений, при большем числе (особенно заметно от 3000) начинаются проблемы стабильности (отваливаются соединения, подвисания). Это цифры наших тестов, причем соединения рвались и на холостой нагрузке - просто открыто 3000 ничего не выполняющих сессий и через какое то время часть из них падает. Но это наши тесты - наша специфика (толстый клиент, мощное железо, самописная конфа, использование виртуальных терминалок, Win машины, MSSQL), а в вашем случае значения могут быть другими.
Чаще всего, когда речь идет о 500-1000 активно работающих пользователях, на первый план выходит оптимальность конфигурации и нагрузка на сервер СУБД.
18. mairon 12.01.17 15:48 Сейчас в теме
Какое-то максимальное количество пользователей врядли можно вывести, зависит от типа СУБД, конкретной конфы (а там и от оптимальности её доработок) и т.д....
вот тут, к примеру, говорят о почти 7000 рабочих мест http://www.1c.ru/rus/partners/solutions/solution.jsp?SolutionID=362311 и объёме базы почти в терабайт
19. Fox-trot 156 12.01.17 19:58 Сейчас в теме
спс за инфу
а то что долго, это просто походу дела выяснил - решил поделиться
20. starik-2005 3033 12.01.17 22:47 Сейчас в теме
Фактически в 1С нет механизмов, позволяющих комфортно работать больше 100 пользователям. Все остальное - это совсем нетиповое оборудование + различные скульные оптимизаторы от известных и неизвестных контор. Даже примитивный шардинг, использующийся везде для оптимизации работы с базами данных, 1С не позволяет делать, превращая высоконагруженные решения в танцы с бубном вокруг оптимизации всего и вся. Не умеет это 1С искаропки. В итоге при 100+ реально активных юзверей контора попадает:
1. На постоянную работу эксперта с целью оптимизации решения.
2. На мощные сервера.
3. На стороннее ПО для оптимизации скульных запросов.
4. На разделение базы на отчетную и оперативную.

На прочие нервные потрясения.

Отсюда как бы совет: если еще не начали, до делайте что-то оперативноучитывающее на чем-нибудь, позволяющем производить шардинг данных, а потом оттуда грузите все в бухню для сдачи отчетности.
21. Sergey.Noskov 1376 13.01.17 11:11 Сейчас в теме
(20) Не согласен, вы смешиваете возможности платформы и возможности конфигурации конкретной БД.
Основная проблема при 100+ активных юзерах не 1С, как таковая, а архитектура конфигурации + её же код. Что бы написать нормальный код и архитектуру в 1С практически всё что надо есть. Для выявления узких мест в производительности - так же возможностей коробочных версий 1С и СУБД достаточно.
Ну а то, что высоко-нагруженная система требует другого качества кода(в первую очередь), другого железа и вообще большего внимания к себе - так это всегда так и не зависит 1С у вас или что то другое.
22. starik-2005 3033 13.01.17 11:52 Сейчас в теме
(21)
Ну а то, что высоко-нагруженная система требует другого качества кода(в первую очередь), другого железа и вообще большего внимания к себе - так это всегда так и не зависит 1С у вас или что то другое.


С первым совершенно согласен, но у 1С нет доступных хороших инструментов анализа кода. Вот, например, в Самсунге такой инструмент есть, но он, конечно, не для кода 1С, а для кода С/С++./Java Произвела этот инструмент IBM, в Самсунге было, помнится, всего 6 лицензий на нескольких серверах удаленной разработки, тимлиды в очередь записывались для использования этих инструментов. Но это так, 1С и IBM в принципе не сопоставимы, конечно, но хорошо бы было, если бы именно 1С вместо своего ЦУП начала бы делать серьезные инструменты исследования не только последствий "плохого кода" (который может быть весьма хороший, при том характер данных сделает его плохим - например, разный уровень повторяемости ключей поиска, который в разных случаях даст разные по эффективности планы запроса), но и сам код. Где анализатор кода от 1С? Сторонние же разработки больше показывают статистику и сложность, не давая ни каких рекомендаций.

А по поводу другого железа, то скорость записи дисковой подсистемы обычного компьютера (не сервера) достигает 20-50 мегабайт в секунду. Это мы не об SSD говорим, а об обычных ноутбцчных дисках. Фактически у нас есть возможность записывать 20 миб/с, а это весьма нехилый по содержанию массив данных. 1С способна до определенного момента использовать данную производительность. В файловой системе и одном пользователе это может быть использовано весьма эффективно. Добавляем пользователей и выносим клиента в веб-интерфес - и мы получаем достаточно неплохую работу 10-ти пользователей. С помощью SQL мы сможем рассчитывать на снижение скорости работы одного пользователя раза этак в три, но при этом данная скорость работы будет сохраняться при одновременной работе до 100 пользователей, но только если вдруг все они не захотят сформировать какой-нибудь отчетик (даже небольшой), после чего система встанет колом. А сели большой, то результат запроса будет долго и упорно вставляться в таблицу СУБД (видели запросы, которые по 5 часов формируются? Знаете, почему, да?).

Т.е. фактически при большом количестве пользователей появляется ситуация, когда ожидание на блокировках становится весьма долгим, т.е. система не работает, а ждет. Шардинг везде (в том же фейсбуке и прочих системах) успешно решает проблемы избыточного ожидания за счет увеличения парка серверов, при том не нужно никаких очень крутых машин. Сложности возникают при сборке общих данных, но они успешно решаются архитектурно. Т.е. горизонтальный шардинг на 10 серверов с общей стоимостью в 1кк руб позволяет достичь производительности сервера за 1кк вечнозеленых. По крайней мере эксперты говорят, что линейный рост нагрузки приводит к нелинейным затратам на оборудование, а квадратичным. Шардин же позволяет повысить производительность с линейным ростом затрат, но 1С так не умеет, при том внешние программы, нарушающие то самое злополучное лицензионное соглашение, за счет этого механизма как раз и позволяют повысить производительность, распараллеливая запросы к разным базам и собирая итоговые таблицы. Т.е. фактически делают из взаимоотношений 1С и СУБД здоровую систему, а не г-на кусок.
23. Sergey.Noskov 1376 13.01.17 13:00 Сейчас в теме
(22) Про шардинг, мое личное мнение - все не так однозначно, очень много нюансов. В вашем же примере (сильно утрированном надо сказать), не обязательно покупать сервер за "1кк зеленых", а достаточно поменять диск и это не будет дороже покупки двух-трех доп. серверов. Шардинг это скорее специфика работы сайтов, да и тот же фейсбук вряд ли шардит системы с простыми ноутбучными дисками, скорее всего они берут ту самую макси железку за 1кк$.
Второй момент - концепцию как вертикального так и горизонтального шардинга можно реализовать в самой конфигурации - декомпозируйте метаданные и делите большую БД на несколько.
Конечно, никто не будет против наращивания функционала платформы и действительно есть куда расти - хотелок много, но и с заявлениями вида "Фактически в 1С нет механизмов, позволяющих комфортно работать больше 100 пользователям" согласиться не могу.
25. starik-2005 3033 13.01.17 13:52 Сейчас в теме
(23) всегда интересует новое, поэтому очень бы хотелось понять, как можно в самой 1С без OLE реализовать шардинг? Ведь суть последнего в том, что при вертикальном шардинге несвязанные таблицы размещаются на физически разных серверах, а при горизонтальном большие таблицы бьются по разным серверам, т.е. происходит сегментация. В принципе SQL давно уже поддерживает данный механизм через партиции, но 1С запрещает вмешиваться в данные, а сама 1С не умеет разбивать данные по партициям, хотя разделитель данных в современных типовых релизах уже имело бы смысл партиционировать, что явно сказалось бы на производительности, да и по низкоселективным ключам (например, организации) можно было бы партиционирование реализовать, сделали бы уж галочку для индекса "Партиционирование" - и уже бы много проблем можно было бы так решить. То же регистр бухостатков и итогов по счету партиционировать. Но 1С это не делает и, полагаю, делать не будет, ибо влом. Ну и реструктуризацию могли бы уж сделать нормально за вменяемое время, чтобы не было миллиардов селектов-инсертов, а был бы один "инсерт селект", а потом абдейт для исключенных типов. Нахрена было городить такое г-но для реструктуризации только для того, чтобы отобразить пользователю сообщение о количестве отреструктуризированных записей. В итоге архитектура, как я уже писал, в больших решениях перестает развиваться, т.к. при архитектурных изменениях реструктуризация просто вышибет бизнес из системы на эндцать часов. И вместо изменения таблиц программистам приходится создавать новые таблицы, которые потом хитро привязываются к владельцам. В итоге консистентность данных может быть нарушена, если под этим термином понимать связь данных друг с другом (англ. data consistency или data validity - это согласованность данных друг с другом, целостность данных, а также внутренняя непротиворечивость. Множество всех условий, налагаемых на данные определяется моделью (структурой) данных, прим. словарь), ибо никто не запретит записать в регистр что-то, не отвечающее условиям, а платформа это не контролирует на "физическом" уровне (в отличие от того же реквизита ТЧ, который просто не может быть записан без ссылки на элемент справочника, и при удалении элемента ТЧ тоже очищается).
Fox-trot; +1 Ответить
28. Sergey.Noskov 1376 13.01.17 14:36 Сейчас в теме
(25)
всегда интересует новое, поэтому очень бы хотелось понять, как можно в самой 1С без OLE реализовать шардинг?
ну т.е. вы согласны, что используя OLE его уже можно реализовать? Конечно же потребуется некий промежуточный программный слой, который будет определять в какую ИБ перенаправлять запросы. Если клиент у нас сайт - то определять источник вызова можно и на стороне клиента.

Встречный вопрос по поводу нового и не пощупанного, есть что то "искаропки", что позволит взять существующую БД и раздербанить её, допустим только одну, таблицу на N серверов? Ну т.е. чтоб не кодить ни прослойку ни морду для настройки, но получить возможность настраивать как число серверов, так и условие секционирования. Без сарказма - ответа не знаю, хочется верить в то, что есть, но "quick гугл" молчит либо выдает ответы типа "Из коробки счастья нет".
29. starik-2005 3033 13.01.17 14:57 Сейчас в теме
(28)
ну т.е. вы согласны, что используя OLE его уже можно реализовать? Конечно же потребуется некий промежуточный программный слой, который будет определять в какую ИБ перенаправлять запросы. Если клиент у нас сайт - то определять источник вызова можно и на стороне клиента.
Тут как раз необходимость в 1С отпадает. Зачем платить за лицензии, если можно реализовать все на NODE, JBOSS или чем-нибудь ином. Трудоемкость такого подхода ниже за счет реализации ORM, в 1С же придется пилить кучу кода и совсем не ООП.
32. starik-2005 3033 13.01.17 15:46 Сейчас в теме
(28)
Встречный вопрос по поводу нового и не пощупанного, есть что то "искаропки", что позволит взять существующую БД и раздербанить её, допустим только одну, таблицу на N серверов?
Ну, наприммр, вот. Это, конечно, не "искаропки", но оно уже реализовано и скачивабельно без всяких стартманей.

Ну и вот тут тоже кой-что есть (вопсче, первые две сцылки гугла).
и про корейскую разработку CUBRID и их реализацию шардинга «из коробки»
Заметьте, 2012 год на тему хайлоада. А сегодня уже 2017-й, а мужики из 1С-то и не знали...
И вапсче:
В одном из первых слайдов промелькнул вопрос — мол нужно ли вообще использовать реляционные БД, когда вокруг столько «сладких» NoSQL-решений. Опираясь на тот факт, что такие успешные конторы, как Facebook, Twitter, Evernote и пр. используют РСУБД с шардированием для хранения больших объемов данных, то значит реляционные БД таки востребованы. Основная фишка, судя по заверениям авторов, состоит в том, что реализацию механизмов шардирования от CUBRID можно использовать не только с дефолтовым движком CUBRID, но также и с MySQL и даже с Oracle (правда вот с Oracle пока все же ещё нельзя, но по словам докладчика, в ближайших версиях точно появится).
33. Sergey.Noskov 1376 13.01.17 16:50 Сейчас в теме
(32)примерно понятно, спасибо. Укрепили мысль, что все это специфично "сайто-ориентированная" архитектура. Зачем пытаться сюда впихнуть 1С, при этом ругаясь и посыпая платформу "г-нами", пусть останется тайной.
34. starik-2005 3033 13.01.17 17:01 Сейчас в теме
(33) "сайто-ориентированность" и HiLoad - это, конечно, близко и 1С тут близко не валялась, но то, что основное применение данных технологий находится в сегменте веб, как самом высоконагруженном, несомненно. Отсюда и основная мораль басни: если Вы собрались автоматизировать бизнес-процессы, подразумевающие высокую нагрузку и высокую скорость изменений, то не стоит выбирать для этой цели 1С. А вот если Вам бухотчетность сдавать - проще организовать выгрузку в отчетную базу синтетических показателей из любой системы, чем довести 1С до какой-то большой и сферической вакуумной кобылы.

И хотелось бы получить от Вас ответ на такой вопрос: в чем специфичность-то веб-порталов, кроме высокой (в десятки и сотни раз выше, чем самые супер-пупер крутые внедрения 1С) нагрузки?

ЗЫ: Слово Oracle в последней цитате не навело Вас на какую-нибудь мысль, отличную от "сайто-ориентированности"? Хотя... Куда Вам )))
35. Sergey.Noskov 1376 13.01.17 18:29 Сейчас в теме
(34)
Хотя... Куда Вам
и это после вопроса
И хотелось бы получить от Вас ответ на такой вопрос: в чем специфичность-то веб-порталов
спасибо, повеселили )))
И давайте закончим, пока Вы не скатились до прямых оскорблений.
36. starik-2005 3033 13.01.17 18:31 Сейчас в теме
(35) ну т.е. у Вас нет ответа на этот вопрос? Так зачем городить-то кучу теста? Ну не знаете - не пишите ничего такого больше.
37. Sergey.Noskov 1376 14.01.17 12:33 Сейчас в теме
(36)Сергей, диалог мог бы получиться интересным, но вы позволяете себе не уважительные выпады, что вызывает одно желание - ответить тем же, т.ч. конструктивного разговора уже не получится.
nazirovramzil; baha2772; +2 Ответить
24. v3rter 13.01.17 13:27 Сейчас в теме
Скажем так, начиная с определенного уровня нагрузки, разработка и поддержка собственной системы (с экспортом проводок в 1С для отчетности) обойдется дешевле. Собственно, на очень многих предприятиях до сих пор используют собственные самоделки. В юности даже видел на одном предприятии самодельный 99% аналог 1С 7.7 бухгалтерии (без регламентной отчетности) и склада на связке Access 97 + SQL 2000, разработанный и обкатанный четырьмя местными программистами в течении года. Я это к тому, что подобные разработки не относятся к запредельно сложным.
26. starik-2005 3033 13.01.17 14:03 Сейчас в теме
(24) вот с этим сложно поспорить. При наличии таких инструментов, как Java/C#, реализовать механизмы оперативного учета уже проще, чем адаптировать под оное какую-нибудь УТ. Если есть желание - можно на NODE.JS зарелизить всю серверную часть, а потом бутстрапом реализовать клиентский интерфейс, затратив на разработку куда меньше бабла, чем на допил УТ'шки. А на JS сейчас только ленивый не программирует, поэтому всегда есть масса студентов, которые будут за 30к пахать даже в МСК, создавая ПО приемлемого качества с хорошими показателями производительности.

Вообще, на западе в части разработки на PHP широко используют фреймворк Laravel, введение в который начинается с настройки миграции. Все изменения таблиц СУБД описываются фалом миграции, после чего для объектов миграции создается объектно-реляционная модель, с которой уже на уровне контролера данных работает программист. И это верный подход к изменению модели данных, в отличие от подхода 1С, где программист только догадывается, что происходит с данными при изменении метаданных.
27. herfis 498 13.01.17 14:13 Сейчас в теме
ТС интересует, на добавлении какого по счету пользователя 1С выкинет эксепшн?
Это чрезвычайно полезное знание несложно получить простым экспериментом.
Но т.к. кроме ТС это никого не интересует, ему и карты в руки.
30. vis1984p 2 13.01.17 15:07 Сейчас в теме
Видел на личном примере 700 пользователей, на MS SQL
31. brr 182 13.01.17 15:15 Сейчас в теме
Посмотрел сейчас число активных пользователей в рабочей базе = 696.
38. Fox-trot 156 14.01.17 21:52 Сейчас в теме
таким образом напрашивается вывод, что на данном этапе развития система пригодна только лишь для систем со скромным количеством пользователей?
а для чего-то сурьезного нужен бубен или ... вопщем на сколько хватит денег и фантазии
если так, то вопрос про снимается как не уместный
41. starik-2005 3033 15.01.17 00:05 Сейчас в теме
(38) сэкономив на разработке в 1С какого-то начального функционала из-за достаточно развитого дерева типовых объектов, Вы через какое-то время столкнетесь с тем, что у Вас нет добротного механизма групповой разработки и Вам придется содержать кучу хранилищ конфигурации для каждого экспериментального функционала; нет хорошего механизма тестирования функционала; не хватает производительности сервера для отдельных регламентных процедур; нет хорошего инструмента анализа кода...

Вот, например, наши проблемы:
- накатить пару-тройку объектов из тестового CF-ника до включения этого функционала в релиз на весьма неплохих серверах оказывается весьма затратное по времени мероприятие - 2-3 часа, из которых сравнение и объединение занимает львиную долю времени.
- реструктуризация доходит до - вдумайтесь! - двух недель! При том копирование этой самой реструктуризируемой таблицы средствами SQL на этом самом SQL сервере занимает всего 3 часа, при этом добавить нужную колонку и заполнить ее пустой строкой занимает 1 минуту. А т.к. клиенты у нас разные, то и количество данных у них отличается. У кого-то в этой таблице вообще ничего нет, а у кого-то десятки гигабайт, которые 1С реструктуризирует эти самые 2 недели. И ведь мы, как поставщики отраслевого решения, не можем предполагать, сколько данных в эту таблицу поместит тот или иной бизнес-пользователь.
- как-то пытались сделать в 1С поддержку ФЗ-115, но оказалось, что при достаточной скорости селектов для проверки недействительного паспорта, скорость обновления таблицы оставляет желать лучшего (читай - удавиться, ибо нужно 100кк паспортов туда засунуть). Запись в регистр сведений предварительно упорядоченного списка занимает - вдумайтесь! - 8 часов! Пишется по 50к записей за раз. А при попытке обновить данные, добавив только новые, приходится проверять каждую запись на предмет наличия в базе, а это оказывается еще дольше, так что проще все грохнуть и записать без проверок заново, только проблема в том, что в это время кто-то может нуждаться в этих данных. В итоге плюнули и сделали инсертом в скульную таблицу из файла, а чтобы ничего не нарушать в плане лицензионного соглашения, инсертим не в базу 1С, а в другую базу. 20 минут вставка против 8 часов средствами 1Сю И это не С++, а батушник со скриптом!

На прошлой работе в базе (300 гигов) постоянно присутствовало 500 пользователей, в базу постоянно ломились сотни запросов от веб-сервисов онлайн-фронтэнда, который по благоразумию был написан на JAVA и кешировал данные. Для реализации пришлось сделать очень многое:
1. Купить за дохрена бабла сервера и отдать их в датацентр на аутсорс, но все админство серверов пришлось держать в своих руках.
2. Разделить базу на ту, где формируются отчеты, и ту, где работают юзеры. Для того, чтобы юзеры входили в одну базу и формировали отчеты в другой, был создан механизм формирования отчета в базе №2 и отображения его в базе №1 (в действительности, механизму было фиолетово, в какой базе формировать отчет - он на входе получал адрес сервера и параметры формирования отчета - этакий шардинг отчетов получался). При том отчет для пользователя формировался полностью прозрачно, для любой отчета можно задать сервер, на котором он должен быть сформирован. Любые расшифровки работают. Т.е. любой (100%) отчет, созданный на базе СКД (даже с программным выводом схемы), мог быть сформирован в любой копии базы - нужно было пять строк кода добавить, и все! Я, кстати, это всего за неделю сваял. Потом коллега запилил веб-сервис за пару дней. И пришлось кое-что снести из типового в УТ, чтобы при инициализации соединения не было записи, ибо для формирования отчета использовался снапшот базы, который за 7 секунд делался, но он доступен только в режиме "только чтение". В этом же механизме сделали так, чтобы юзер не мог одновременно формировать отчетов больше, чем ему разрешено.
3. Каждый год резать базу, вычищая старые периоды, переносить еженощно остатки из базы прошлого года в базу этого года (потом уже и из позапрошлого в прошлый и т.д. вглубь веков). И тут тоже интересная особенность: ДЗ по покупателям переносилось за минуты, а вот ДЗ по поставщикам, по которым не было прямого закрытия в разрезе документов, а было закрытие по договорам, что привело к наличию примерно 3кк единиц ДЗ/КЗ, переносилось уже 5 часов. И это на совершенно пустой базе прошлого года (к которой никто не подключается ночью).
4. Для множества обращений веб-сервисов пришлось выделить отдельно базу-посредник, которая маршрутизировала запросы к доступной базе. Если рабочая база по какой-то причине становилась недоступной, то запросы перенаправлялись в копию.

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

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

ЗЫ: Наши коллеги. которые запиливали фронтенд на JAVA, тоже сталкивались с определенными проблемами производительности, но они решали их куда менее затратно и в несколько раз быстрее. Отсюда и мое отношение к HiLoad + 1С, как к попытке на танке выиграть заезд формулы 1.
39. Pavel_nv 16 14.01.17 22:19 Сейчас в теме
42. Fox-trot 156 15.01.17 12:46 Сейчас в теме
(39)это все частные случаи теоремы :)
40. starik-2005 3033 14.01.17 23:15 Сейчас в теме
HiLoad - это вот как-то так: https://habrahabr.ru/post/178525/ Это даже на 1С можно сделать, только нафига платить за лицензии?
43. Fox-trot 156 25.01.17 09:55 Сейчас в теме
для информации
Прикрепленные файлы:
starik-2005; +1 Ответить
45. Fox-trot 156 04.02.17 00:06 Сейчас в теме
вышел новый релиз 8.3.9.2170
Подключение пользователей к информационной базе
Код ошибки: 10171187
Дублирующие: 10167480 10172395 10172739
Код(ы) обращения: CSR-12879 CSR-14006 CSR-14389 SW1105115
Статус: Исправлена в выпущенной версии
Зарегистрирована: 30.11.2016
Исправлена: "Технологическая платформа", версия 8.3.9.2170

Описание:

В клиент-серверном варианте информационной базы, при одновременном подключении большого количества пользователей может происходить аварийное завершение работы рабочего процесса сервера.

так вот непонятно сколько имеется ввиду, когда говорится
при одновременном подключении большого количества пользователей
46. starik-2005 3033 04.02.17 10:28 Сейчас в теме
(45) совершенно непонятно, что они исправили. В последних релизах часто валятся ошибки от "POST невозможно прочитать файло..." до "Ошибка SDBL - контекст сдох...", которые еще с 8.2 (если не 8.1) постоянно "то явятся, то испарятся". Про 1С можно сказать так:
Сисоп  Крутых написал предвыборную прог-
рамму  на языке Бейсик и начал её отлажи-
вать.  Исправляя  одну  ошибку, он вносил
три  новых.  Через  какое время программа
ругнется: "1982 Sinclair Research ltd."?
https://zxpress.ru/article.php?id=3080
Оставьте свое сообщение
Вакансии
Программист 1С
Москва
зарплата от 180 000 руб. до 220 000 руб.
Полный день

Аналитик 1С / Бизнес-аналитик
Нижний Новгород
зарплата от 100 000 руб. до 250 000 руб.
Временный (на проект)

Программист 1С
Москва
зарплата от 250 000 руб.
Полный день

Программист 1C
Волгоград
зарплата от 200 000 руб.
Полный день

Аналитик
Санкт-Петербург
зарплата от 200 000 руб. до 250 000 руб.
Полный день