1с77 сетевая. Тормоза при работе 2х и более пользователей.

Да, не простая ситуация. Посоветовать вряд ли смогу специалиста, не потому что их нет, а потому что все одинаково советуют то, что проще, а не то, что дешевле. Отчеты проверяли на оптимизацию кода? Тем более что база самописная, проверить стоит.
Вот совсем ненормальный вариант (совет), когда пользователи работают в локальной сессии, набивая документы, а отчеты по очереди лезут в терминал делать, благо XP одну терминальную сессию держит, правда локальную закрывает.
Есть еще один бредовый вариант, оставлять на севаке открытую сессию 1С на которой запускается отчет по какому-то событию из сети через сторонние средства автоматизации. К примеру, понадобился пользователю отчет, он создает файл запроса с необходимыми параметрами в определенной папке, уведомляя, таким образом, систему автоматизации, что пора делать отчет. Система автоматизации посредством OLE-автоматизации или напрямую через WinApi открывает соответствующую меню в 1С, выбирает отчет, забивает параметры и запускает отчет. Сформированный отчет сохраняет в указанную папку и отправляет пользователю NetSend сообщение о том, что отчет сформирован и сохранен в указанной папке пот таким-то названием. Идея хотя и попахивает бредом, который обычно и приходит на ум во втором часу ночи, но зато вполне реализуемая, без нарушений, чьих либо авторских прав и уж точно избавляющая от проблем с тормозами в 1Совских отчетах. Кстати я подобную идею реализовывал как-то, правда, не с 1С, но принцип был тот же. Автоматизацию пришлось реализовывать через WinApi потому что не было у той программы поддержки OLE, а насколько я знаю в 1С OLE-автоматизация работает, на сером форуме даже как то примеры выкладывали, правда, я сам не пробовал.

---------- Сообщение добавлено 14.11.2011 02:04 ----------

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

 

слушайте, ну а чем вам идея отследить тормоза не по вкусу пришлась? process monitor качаем, добавляем в фильтр 1cv77.exe и смотрим где затык.

 

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

Что решить-то? Вы, условно говоря, посадили в запорожец пять человек и хотите решить проблему "почему медленно едет в гору". Или берите другую машину, или выкидывайте из вашей все лишнее. Волшебные палочки давно отменены научно-техническим прогрессом. У вас нет никакой проблемы. Это абсолютно штатное и нормальное поведение программы. Так что или ставьте и решайте локальные задачи по оптимизации конкретных алгоритмов или решайте общий вопрос о смене программы.

 

согласен.
но

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

Оптимизация кода - штука очень сильная, и там места для маневра хватает - от правильной организации структур хранения данных до предварительной выборки данных запросами и помещения их в оперативную память на стороне клиента (кеширование таблицы в ТаблицуЗначений, например).
Ну и исправление тупых ошибок по типу "обращение через две точки в цикле"
Например, если есть конструкии типа
"А = Спр1.Реквизит1СоставногоТипа.Ревизит1РеквизитаСоставногоТипа"
"В = Спр1.Реквизит1СоставногоТипа.Ревизит2РеквизитаСоставногоТипа"
надо менять на
Рекв = Спр1.Реквизит1СоставногоТипа;
А = Рекв.Ревизит1РеквизитаСоставногоТипа
В = Рекв.Ревизит2РеквизитаСоставногоТипа

потому что в первом случае из базы объект Спр1.Реквизит1СоставногоТипа дергаете на чтение 2 раза, а во втором - один.

как то так...

ТС - а вы хоть замер производительности в 1С 7.7. умеете снимать??

 

Ох уж эти теоретики! Умные книжки читать это хорошо, но там не все пишут. Если к знаниям из книжек применить возможности своего мозга и добавить много практического опыта, то можно достичь совершенно поразительных результатов!
Операции чтения дают ровно такую же нагрузку, как и операции записи и в транзакции ускоряются точно так же. Скорость обработки "на стороне клиента" (т.е. обработка таблицы результатов запроса), вообще не зависит от монопольного / немонопольного режимов. Собственно, в транзакцию, как правило, достаточно включить только вызов метода .Выполнить() у запроса, это самая затратная операция. При этом, фактически временно включается монопольный режим у одного клиента с соответствующим приростом скорости работы. Другое дело, что в массовом порядке такая "оптимизация", конечно, неприменима. Но можно, например, использовать в случае если директор пару раз в день формирует отчет по очень большому объему данных, остальные могут и покурить на это время, дабы не раздражать руководство тормозами.

 

panda-34,
интересное мнение - можете продемонстрировать SQL trace, на котором видно как

Я пробовал такое на практике, прироста фактически не было, так что реально интересно, как это у вас такое получилось, и почему.

Это сильное утверждение. Т.е. если я запросом считываю 5000 записей в плоском справочнике, и пишу в базу в тот же справочник те же 5000 элементов, а нагрузка аналогична, то и время выполнения операции у меня, стало быть, получится одинаковое, я правильно понял?

---------- Сообщение добавлено 14.11.2011 15:08 ----------

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

 

???? Это к чему??? Если имели ввиду замер производительности в отладчике, то скорость выполнения типового запроса к регистрам в транзакции - такая же, как и в монопольном режиме, т.е в 5 -10 раз выше чем в разделенном без транзакции.

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

 

panda-34, угу, вот значит как, интересно.
Ну покажите чтоли хотя бы то, что умеете - замер производительности в отладчике.
Давайте скриншоты - цикл на 500 раз? внутренность которого - два идущих подряд вызова одной и той же процедуры, в которой происходит чтение данных из справочника запросом, при этом первый вызов процедуры в транзакции, второй без оной.
Скриншота д.б. два - текст обработки и ее же текст с замером производительности.

---------- Сообщение добавлено 14.11.2011 16:23 ----------

И кстати, а давно ли типовые запросы в 7.7. научились изменять данные?

---------- Сообщение добавлено 14.11.2011 16:36 ----------

Доп. вопрос - о том, что в 1С 7.7 почти везде в запросах "грязное чтение" знаете?

 

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

Если хотите конкретный пример, вот типовой запрос к регистрам:
"Период с НачДата по КонДата;
|Партия = Регистр.Партии.Партия;
|Клиент = Регистр.Партии.Клиент;
|Вес = Регистр.Партии.Вес;
|КодОперации = Регистр.Партии.КодОперации;
|Выдано = Регистр.Партии.ТекущийДокумент.Выдача.ТекущийДокумент;
|Функция ВесНачОст = НачОст(Вес);
|Функция ВесПриход = Приход(Вес) Когда (КодОперации = Перечисление.КодОперации.Приемка);
|Функция ВесРасход = Расход(Вес) Когда (КодОперации = Перечисление.КодОперации.Выдача);
|Группировка Партия упорядочить по Партия.ДатаДок;
|Группировка Выдано;"
Результирующая выборка - ок. 3000 записей.
Без транзакции - выполняется 44 секунды. В транзакции - 6.5 секунд. Монопольно 3.5 секунды.

Запросы в 1с 7.7 не умеют изменять данные. И никогда не умели. И никогда не научатся.

 

panda-34, что такое скрин-шот знаете?

---------- Сообщение добавлено 14.11.2011 16:53 ----------

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

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


---------- Сообщение добавлено 14.11.2011 16:55 ----------

Вот я и думаю - а нахрена им

, если там везде почти Nolock

 

Я вообще не уверен, что мы одну и ту же тему обсуждаем...

---------- Сообщение добавлено 14.11.2011 17:04 ----------

О! Теперь я в этом уверен. (В обратном)

 

panda-34, ладно, в общем, мне понятно.
Мне от вас ничего не нужно кроме скриншотов и описания условий тестирования. (тип базы, объемы выборки, кол-во итераций в тесте и т.д. и т.п.)
Как будет что показать - пишите, я вашу инфу передам людям, которые активно интересуются производительностью решений на 7.7.
Они мне потом расскажут - че да как вышло у них на практике

 

Какое это все-же имеет отношение к обсуждаемой теме?
P.S.
Нехорошо удалять сообщение, на которое уже ответили. Я отвечал на сообщение, в котором MenBS опять пытался каким-то боком притянуть SQL сервер в обсуждение вопросов производительности dbf-версии 1с в транзакциях.
Кстати, если уж зашла речь об SQL, то вы сразу должны были признать мою правоту в том, что выполнение запроса в транзакции дает тот же прирост скорости (нулевой для SQL-версии), что и выполнение его в монопольном режиме.

 

panda-34, Вы с какими базами работаете/работали? Типа базы (SQL/DBF), максимальный ее размер?

Ну вы же сами про меня все написали

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

---------- Сообщение добавлено 14.11.2011 17:32 ----------

panda-34, я так понимаю для вас нулевой прирост - таки прирост?
удалить тут сообщение полностью нельзя - так что я мог его только отредактировать.

---------- Сообщение добавлено 14.11.2011 17:34 ----------

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

 

Автор топика конкретно заявил о наличии dbf версии и нежелании смены платформы, я и давал ему советы для его ситуации. Заранее отметя варианты перехода на sql в том числе.

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

 

panda-34, у меня, реально, остался один интерес- скрин-шоты.
Вот поверьте, мне больше от вас ничего уже не надо.
Мне нужен нормальный доказательный пост, если уж не на спец. форуме, то здесь.
И нужен он для дальнейшей передачи метода в тестирование.

 

Затык в 1с, чего тут отслеживать.

По поводу остальных комментариев. Товарищи, обратите внимание в первом сообщении темы userzak написал - терминал, sql и 8 не предлагать. Не хочу десятый раз объяснять причину почему у нас также -вкратце - официально очень дорого, варианты ломания тоже не предлагать. Повторюсь с задачей для полной ясности. есть 3 компьютера, 1 - файловый сервер (операционка _winxp_, linux, bsd - не играет роли, проверено много раз, а если при всех операционках эффект одинаковый винда там вообще не нужна) на нем хранится база 7.7 dbf. Имеется два компьютера с winxp. При входе с одного компа первым пользователем все летает, отчеты по 40-60 сек и т.д. (так что поэтому не понятны советы чего тут оптимизировать с индексами, кодами если работает бысто). При входе вторым пользователем со второго компа, общая тормознутость в работе +10% в документах, но это не критично, а вот в отчетах до 15-20мин (кому интерессно посчитайте какой процент).
Нужно чтобы оба компьютера работали -=полноценно=-, без бегания к друг другу с просьбами выйти из программы, без транзакций которые заставляют других курить - курить нельзя.
Т.е. задача от обратного - не дать нормально работающей программе тормозить в сети при 2 пользователях.

 

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

 

hooper, да разжевали уже вашу проблему миллион сто пятьдесят два раза в интернетах.
Нет у нее решения в описанных вами рамках, кроме как оптимизация кода.
Отрубается в винде кеширование файлов, и это не лечится.
про другие оси не скажу.

 

потому что какое железо стоит не влияет, пропускная способность сети не влияет, от операционок на файловом сервере не зависит. Проверяли много раз. Эта база работает в более чем 10 филиалах, между собой не связанных. Соответственно разброс железа разный от средних до мощных компов, сетки тоже разные но картина во всех одна.

---------- Сообщение добавлено 14.11.2011 18:14 ----------

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

 

Я бы для полноты картины - всетаки просмотрел на каких операциях в ОС спотыкается движек 1ски... Раз так остро проблема стоит.

 

Размышления на сон грядущий.
Однажды пожилой мужчина пришел к шаману и спросил его:
- Слушай мудрец, я вот к врачу собираюсь, посмотри там, в потустороннем мире, нет ли преград для моего пути.
Шаман его спросил:
- А зачем тебе к врачу?
- Да вот ноги болят – ответил старик.
Шаман дал старику какие-то травы и сказал, заваривай и пей на ночь, ноги перестанут болеть.
Старик ушел, и поехал к врачу, через месяц старик снова приходит к шаману и говорит:
- Посмотри, пожалуйста, будет ли мой путь к врачу благоприятен.
Шаман ответил:
- Не благоприятный путь ты ищешь, а путь потакания своим болезням, на этом пути нет блага, нечего мне смотреть, уходи.

Мораль: и чего я здесь делаю?

 

Мораль: Если есть проблема надо искать решение. xbox тоже не сразу сломали.

 

Так Вы же вроде ломать не собираетесь, да и аналогия с xbox неудачная. Есть рецепты, Вы хотя бы попробуйте их.

Я вообще-то про сетевые тормоза писал, не знаю, что Вы имеете в виду под словом "обычные".
Тут Вам уже не раз писали о том, что отчет нужно оптимизировать, и вот этот Ваш пост:

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

 

А можно вот про это поподробнее растолковать?

 

hooper,
Куклачёв,
http://www.kb.mista.ru/article.php?id=136
http://forum.mista.ru/topic.php?id=412611
Статью в ИТС я искать не буду.

 

MenBS,
Понял. Может BranchCache поможет?
http://www.microsoft.com/rus/dino7/feature-branch-cache.html

 

Я это к тому что решения раньше или позже находятся.

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

Оптимизировать отчеты может программист. Я - админ, и решаю проблемы с этой точки зрения.
У меня уже был пример с оптимизацией - когда база тормозила нереально, во всех случаях, что в терминале что монопольно. И повесили на меня. Я менял железо вплоть до i7, менял операционки и кучу других танцев в течении 3 месяцев и все без толку. Пока программист наконец то не соизволил за 15 мин исправить свою выборку в форме. А мораль - что если тормозит, то везде и в любой ситуации. А в моем текущем обсуждении база может нормально работать через сеть с 1 пользователем.
OLE и win api вещь хорошая но замороченная для пользователя.

---------- Сообщение добавлено 15.11.2011 11:00 ----------

Это для win 7, там возможно и нет такой проблемы - не проверял

 

hooper
Вы берете и пишите служебку, в которой описываете все те методы, которые изложены в ссылках, попунктно.
на тестовой инсталляции делаете все действия по каждому пункту, замеряете прирост производительности, фиксируете результат в СЗ, там же расписываете трудозатраты/стоимость/риски как в процессе применения методы, так и прогнозируемые - по типу переписывания конфы.
В конце пишите что более других способов вам в специализированных источниках обнаружить не удалось.
И ваша рекомендация - оптимизировать программным образом - за счет оптимизации алгоритмов.
И отдаете руководству для принятия решения.


И тогда ваша фраза о том "что аппаратно ничего сделать нельзя" приобретет характер обоснованного утверждения, подкрепленного общепринятой практикой.
Ну или вы на решении нобелевку в среде 1С защитите)

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

 

Ну, так обратитесь к программисту, тем более у Вас уже есть положительный опыт в этом направлении.

правильно MenBS пишет, начальство надо ставить в известность и лучше в письменном виде.