hi all.
Сабж. Есть ли в моск. регионе примеры РЕАЛЬНЫХ внедрений на обозначенное число пользователей ?
Нашей конторе требуется прежде всего складской учет с минимальным временем отклика на ввод данных по первичным операциям, а также очень быстрый отклик на "проведение документов" в кассе.
Также актуально время отклика при оформлении документов на услуги (ввод ремонтных операций).

Если эта тема - драный баян, киньте, плз, ссцЫлки.
Заранее спасибо за ответы.

Просветите, плз, в общих чертах, что такое "кластера" в понимании 1с ?

ISGRпроблема блокировки , ибо в управляемый режим придеться переводить

2ISGR: поясните, плз, свою мысль. По этому адресу насчёт блокировок написано следующее:

1c8_FAQQ: Насколько в 1С:Предприятии 8.0 повысилась производительность системы при одновременной работе большого числа пользователей по сравнению с 1С:Предприятием 7.7?

A: В отличие от версии 7.7, в модели данных, поддерживаемой системой 1С:Предприятие 8, не существует таблиц базы данных, однозначно приводящих к конкурентному доступу со стороны нескольких пользователей. Это относится как к файловому, так и к клиент-серверному варианту работы системы. Соответственно не возникает проблем при включении разнородной функциональности в одно прикладное решение.

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

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

Меня интересует именно клиент-серверный вариант. В чём Вы видите проблему блокировки для него ?

ПЖречь идет про управляемые блокировки Если я правильно понял из этого текста, для достижения уровня изоляции read committed в 1С надо её переводить в управляемый режим и там всю работу по установке блокировок делать "ручками". И что, Вы именно в ЭТОМ видите серьёзную проблему ?

ПЖУправляемые группировки в 1С 8.1 <> блокировки 1С на SQL-ой базе -- в том смысле, что команды на установку блокировок надо записывать руками, как в примере, который приведен в вышеупомянутой ссылке ?

ПЖа всё-таки на 500 чел. - другое решение не рассматривались? Заказное како-нибудь, GUI попроще + БД Другие решения оказались, прежде всего, гораздо дороже. Все эти САПы и Навижны, как я понял, для других секторов экономики.
Сапописки делать пытались сами, и неоднократно. Не получилось из-за необх-сти сопровождения старого ПО: наши программисты просто не могли одновременно делать два дела ХОРОШО; получалось, что оба дела выполняются ПЛОХО (что, впрочем, совсем неудивительно).
Заказать на стороне тоже пытались, нам сделали для пробы "нечто" на Дельфе в связке с IB 6.5: это был "ужос". Прежде всего, по количеству глюков (access violation'ов) на клиенте. К тому же, это "нечто" оказалось совершенно непригодным для групповой разработки. Про функционал вообще молчу -- нет и сотой доли того, что я сейчас вижу в demo-обучалке по 1с v 8.1 (коробка с книжками Радченко и учебной версией). Простейшие вещи надо было делать через %@#$%@&*.

Главное, что я понял: не следует тратить время и силы на изобретение велосипеда.
Руководителям бизнеса совершенно наплевать на то, на чём написана программа, простой там ГУИ или навороченный. Юзерам - обычно также всё это до лампады. Никого и никогда, кроме коллег-разработчиков, не заинтригует, насколько элегантно спроектирована система и никто не будет восхищенно цокать языком на тему "ах, до чего же вы там, в IT, все умные!", если отчет, составлявшийся в старой системе 1 минуту, стал составляться 10 сек. Никто не заметит (а если и заметят, то воспримут это в духе "О! что-то сегодня чуть-чуть побыстрее работает!" - и всё).

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

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

СисойВнедрить можно, но только с участием специализированной конторы типа softpoint.ru Почему так категорично ? Вы имеете ввиду, что к ним придётся обращаться за консультациями или чтобы они сами всё делали ? Если второе, то вопрос: а что, для создания конфигурации, работающей на 3-4 кластерах, требуются танцы с бубном и сами мы выучиться этому никогда не сможем ?

JD Edwards и TradeHouse не смотрели. Решение на базе Аксапты нам привозили, но это было какое-то недоделанное посмешище. К тому же, почти все наши вопросы на тему "а как нам самим сделать то-то и то-то" демонстратор отвечал: "пока никак, это к нам". То есть, просто предлагали заплатить деньги за недоделанную систему и доделывание её чужими программистами (вместо наших). Может, эта система бы и заработала у нас, но 1) через какой срок ? и 2) какая итоговая стоимость внедрения при этом бы получилась ? Короче, тот вариант также был забракован. Как я в последствии понял, начальство что-то там подсчитывало и главная причина этой "забраковки" была опять-таки в деньгах.
Но на мой взгляд, фактор доступности на IT-рынке спецов по саппорту и доработке также должен учитываться. "Сломается", скажем, этот самый JD Edwards, и где нам искать "слесарей" для него ?!

ПЖПо вопросам масштабируемости и производительности связок 1С и SQL рекомендую обратится сюда http://www.softpoint.ru/ - я сюда зашёл, но там все ссылки пестрят циферками "7.7", а циферок "8.х" не видно совсем. Между тем, как я понял, восьмая версия 1це серьёзно отличается от 7.7. В частности, по этому адресу я прочитал:
1c v7 FAQ Q : Насколько в 1С:Предприятии 8.0 повысилась производительность системы при одновременной работе большого числа пользователей по сравнению с 1С:Предприятием 7.7?
A : В отличие от версии 7.7, в модели данных, поддерживаемой системой 1С:Предприятие 8, не существует таблиц базы данных, однозначно приводящих к конкурентному доступу со стороны нескольких пользователей. Это относится как к файловому, так и к клиент-серверному варианту работы системы. Соответственно не возникает проблем при включении разнородной функциональности в одно прикладное решение.
... <skipped> ...
Таким образом, 1С:Предприятие 8 обеспечивает возможность параллельной работы гораздо большего количества пользователей без возникновения проблем конкурентного доступа, по сравнению с 1С:Предприятием 7.7.

Видимо, сайт софтпойнта обновляется с опозданием (не могут же они заниматься только 7.х ?)

ISGRесли Вы не видите в этом серьезных проблем например для УПП, Вы либо очень хороший специалист и я готов взять Вас на работу, либо просто не понимаете объем и сложность работ Я не специалист в 1с (пока; дальше, надеюсь, им стану, т.к. сейчас усиленно изучаю эту платформу). Однако в моей практике был период (более 10 лет) программирования на одном из dbf-языков в связке с ADS-сервером. И там ни одной операции нельзя было сделать без предварительной установки блокировки (уровня записи, есс-сно). И не дай бог забыть эту блокировку снять после того, как запись будет завершена.
Общее число строк в той программе было ~150'000. Сами понимаете, что количество мест, где надо было "ручками" ставить и снимать блокировки, исчислялось, наверное, не одной сотней. Тем не менее, я остался жив и невредим :-). Код, записывавший в БД инфу, практически всегда был "содран" с шаблона, примерно такого:

1) проверить служебный массив на наличие в нем имени функции, являющейся инициатором транзакции; если такого имени там нет, то добавить туда имя текущей функции;
2) получить имена таблиц, в которых требуется провести запись;
3) для каждой такой таблицы получить список строк, в которых будут обновлены данные;
4) запросить блокировки строк последовательно для всех таблиц; для добавляемых строк - запросить блокировки на добавление записей;

5.1) при отказе в п. 4 -- снятие всех предыдущих блокировок и выход с кодом возврата меньше нуля ("авария"), т.е. переход к п. 10;
5.2) при получении ВСЕХ строковых блокировок -- повторная проверка допустимости выполнения
текущей операции (блокировки могли устанавливаться не мгновенно!);
5.2.1) если в предыдущем пункте какая-либо проверка НЕ выполнена, снятие всех предыдущих блокировок и выход с кодом возврата меньше нуля ("авария"), т.е. переход к п. 10;

6.1) если текущая функция является инициатором транзакции [см. пункт 1: проверяем служебный массив!], то объявить начало транзакции (BEGIN TRANSACTION)
6.2) иначе проверить, не выполняется ли текущий код внутри активной транзакции (то есть, была ли объявлена транзакция).
6.2.1) Если да, то перейти к п. 7;
6.2.2) Иначе - выход БЕЗ снятия блокировок (переход на п. 11, код возврата 0)

7.1) запись в таблицы (ТОЛЬКО ТУТ в разных местах программы были разные операторы);
7.2) если текущая функция является инициатором транзакции, то перейти к п. 8); иначе -- перейти к п. 11 (выход БЕЗ снятия блокировок, код возврата равен 0);

8) проверка бизнес-правил перед завершением транзакции;
9) если в предыдущем пункте какое-то правило не выполнено -- ROLLBACK и установка кода возврата меньше нуля ("авария"); иначе -- COMMIT;
10) снять блокировки со всех таблиц. Очистить служебный массив с именами таблиц, номерами строк и именем функции-"инициатора" транзакции
11) выход с кодом возврата (0 = Ok, <0 = Error)

Так вот: самым трудным было не "сочинение" этой схемы, а создание механизма, благодаря которому одни и те же функции, проводящие запись, могли бы "понимать", имеют ли они право ОБЪЯВИТЬ ТРАНЗАКЦИЮ (п. 5) или нет (и, соот-но, могут ли они проводить сейчас запись и проверять бизнес-правила для COMMIT/ROLLBACK'a). Потому что в том ADS-сервере не было понятия "вложенной транзакции" (да и вообще это какое-то "странное" понятие, имхо). Программный модуль должен каким-то образом понимать, выполняется ли он ВНУТРИ кода, который является "инициатором" транзакции, или эту транзакцию надо делать ему самому. Этот механизм был реализован в виде служебного массива, в котором содержится имя функции, являющейся "инициатором" транзакции -- см. п 1 в вышеприведенном описании.
Подчеркну еще раз: мои воспоминания о той "эпопее" сводятся к тому, что самым сложным является не кодирование "ручками" (берётся шаблон-болванка и методом copy/paste вставляется в новое место). А именно разработка механизма, позволяющего функциям (модулям) "понимать", имеют ли они право объявить транзакцию и завершить её, или НЕ имеют (т.к. работают в "подчинённом" режиме).

ЗЫ. Насчет того, что не понимаю объем и сложность, Вы не правы: еще как понимаю. Потому и завёл этот топик.

Но у меня появились вопросы по блокировкам, к-рые надо ставить в управляемом режиме:
1) есть ли возможность циклического повтора попытки установить к-л блокировку на строку, если в данный момент времени эта строка занята ? То бишь, существует ли в 1с некий механизм, позволяющий в цикле запрашивать блокировку и ждать некоторое время в случае неудачи (с возможностью прерывания юзером этой попытки и возвратом в исходный режим) ?
2) после получения блокировки приложение часто должно проверить заново состояние данных в той строке, которую оно так страстно "домогалось" (потому что за время ожидания блокировки данные в этой строке могли стать уже другими, в т.ч. такими, при которых выполнение операции становится недопустимым -- например, было списано последнее изделие и текущий остаток стал равен 0). Так вот: есть ли в 1с некая "штатная" возможность повторной проверки на допустимость выполнения операции, уже после того, как все блокировки получены ? Или это тоже надо делать "руками" ?
3) запоминает ли 1с в какой-нибудь структуре (массиве ?) те строки, которые оказались заблокированными, и можно ли к ним обращаться напрямую, БЕЗ SQL-запросов, т.е. примерно как через "goto" ?

И еще: есть ли в 1с понятие static-переменной (и массива), в том смысле как в Си: чтобы после окончания работы функции эта переменная "жила" и её можно было бы задействовать при новом вызове этой функции ? Без static-переменных реализация того алгоритма, который я привёл, будет просто невозможна (т.к. все функции вызываются фактически ДВАЖДЫ: сначала для установки блокировок, а затем для записи).

ISGRможете не пытаться освоить подход к программированию 1С через ваш опыт ( в данном случаи опыт не облегчает обучение, а усложняет, вам придеться бороться со своими же навыками) я и не собирался лезть в 1с'овский монастырь со своим уставом :-)
Мне просто стало интересно, что там такого "великого и ужасного" надо сделать, чтобы проводить критически важные операции в управляемом режиме (если я правильно понял, именно в нём достигается уровень изоляции read committed).
Когда о необходимости "вручную" устанавливать в большом числе мест блокировки говорится как о проблеме, то это, имхо, рутина, требующая внимания и аккуратности, а не проблема.
Или 1с не может работать "частично" в управляемом режиме, а "частично" в автоматическом, и надо переводить под управляемый режим всё сразу ? (не пинайте сильно, т.к. я только начал знакомиться с этой системой и могу, ес-сно, "морозить")

Ну да, именно это я и читал вчера на их сайте. Так что получается, самой большой неприятностью при переводе в управляемый режим будет РУТИНА по добавлению кода установки и снятия блокировок, да ?