Я зубр и монстр 1С, но из-за текучки некогда изучать УФ, работаю с УТ 10.3, УТ 11 тоже не смотрел, например.
Понятно, что доведется если менять работу, то через франчайзи - кузницу кадров, там и УФ научат и УТ 11-му.
Ну а вообще, сейчас незнание УФ - это большой недостаток на рынке труда или нет. Если что, стаж с восьмеркой 10 лет, с 2005 года.

(271) а чо не файловую тогда ?

по мне так критикуя механизм платформы 1С делать пассажи типа "ну и что что тут тормозит СУБД - в главном то я прав, 1С-гомно, и разработчики пудаки" - не очень корректно

(274) то что выглядит это как отстой криворукий..

(272) Тогда ты должен понимать, что информативности такой тест не даст.

(275) Он такого и не утверждал.
(277) Приведи свои результаты.

Просто теоретические изыскания на тему "так низя" - это всего лишь теоретические изыскания.

(275) Ты меня удивляешь. Я от тебя даже не ожидал такой позиции. Т.е. 1С сгенерила запрос за секунду с планом выполнения на полчаса: 1С молодец, а СУБД - тормоз?

следите за руками...

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

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

ЗЫ все аргументы Drac0 высосаны из пальца...

(278) Наши результаты: все, что сложное элементарного левого или внутреннего соединения нах*й из динамических списков :)

(281) Дальше читай.

(280) ну так мы в контексте корректности тестирования производительности платформы или нет?

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

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

как изменится быстродействие у первых десяти?

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

?

(284) В контексте производительности системы. Отдельно от СУБД это абсолютно некорректно. И таки в моем примере 1С молодей или нет?

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

речь то идет о принципиальном тестировании - сколько генерить пользователей и какова будет погрешность..

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

в итоге у тебя на 100 человеках будет определенная погрешность в тестировании..

а теперь ключевой вопрос: на сколько эта погрешность будет отличатся от погрешности результатов которые ты получишь тестируя по схеме "количетсво пользователей примерно равно максимальному количеству пользователей на рпхост" ?

лично я убежден что эта схема правильнее ибо:

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

>Для этой информации есть отчеты на СКД

для этой информации есть банальная выгрузка списка

отчет должен агрегировать или наоборот расшифровывать данные в нужной аналитике с произвольными отборами недоступными в тех же списках

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

вопрос к знатокам:

10 рпхоств к скулю сделают 10 подключений или одно ?

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

Так это уже совсем другое. Что тебе мешает такое реализовать?

(288) Один рпхост - одно соединение.

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

(287) Не нужно путать сумму выделенных пользователем документов и итог всей таблицы. Против первого никто ничего не имеет.

>Так это уже совсем другое.

почему "другое"?

>Что тебе мешает такое реализовать?

мешает костыли 1с и ипанутая объектная модель, где часть того что можно сделать в гуе нельзя сделать программно. до сих пор. со времен 7.7

я хочу чтобы это было доступно "из коробки"

(290) отсюда возвращаемся к моей теории..
у тебя допустим наглухо кривой план запроса.. ну вообще ч0кнутый..
но работает 2 рпхоста.

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

не?
чем логика хромает?



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

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

(291) да не нужны мне итоги на поллимона строк, предлагаю начать с малого

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

кстати глобально по теме:

мелкие конторы с приходящими бабушками-бухами плавно и массово переходят с 7ок на 8ки. причем сразу на крайние, и тащут за собой тех кто в ТИСе работал..

наблюдаю эту картину с декабря.

Спасибо 1Су и минфину за проверку ИНН :)

отсюда - даже если ты не работаешь на супермегапроекте - мелочь тоже уходит в такси..

(296) заниматься оптимизацией производительности надо постепенно.. шаг за шагом..

если у тебя тупо свопится сервер 1С упарываться планами запроса для скуля глупо..

(298) Конечно нужно комплексно подходить. Для начала выявить узкие места

(298) +1

(299) ну дык и среднестатистическому 1снику план работ то какой?

1. проверяем сервер 1С
2. проверяем гамногод на 1С (обращения через пять точек в циклах и прочие запросы в циклах)
3. тестируем всякие динсписки и проиче отчет на предмет завешивания сервера 1С и адекватности работы


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

(301)

исправлюсь

п.1 проверяем настройки сервера 1С и сервера SQL - те что админские.. с точки зрения настроек ПО и операционок с железом..

(0) возьми перепиши свои обработки/разработки на УФ.

(301) Не правильный план.
1 этап - это настрйока тж на сбор длительных операций

(303) бугага.. он откроет свою мегаразработку где на форму выводился вордовский активикс и заплакав пойдет пить горькую.. ибо в этих тупых УФ даже элементарного нельзя сделать..

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

проблема с УФ не в том что она "плохая", а в том что ее функциональность урезана и местами непонятно почему, местами криво...

причем сначала 1с пытается ипать мозг в стиле "эта крута" и "не держите ее так"... а потом сама "переизобретает" показать в списке

"такси" это по сути вторая попытка перезапуска... ждем SP3

(293) "почему "другое"? "

Потому что получать данные из таблицы СУБД и из данных, которые уже пришли на клиент две большие разницы.

(295) ПриАктивизацииСтроки и ВыделенныеСтроки спасут отца российской демократии. Или 1С должна весь код за вас писать?

(304) хз.. честно  - я как понахватавшийся вершков ремесленник никогда тж не пользовался еще :)

(306) а мы тут не про те которе развгод а про те которые каждый день да толпой да постоянно

(305) Ну пусть функционал с 0 реализует :)

(307) в 8.3.7 сделали спплит окна..
недMDI - 2 окошка можно теперь открыть  :) :) :)

(298) Ну вот серьезно. Ты же сам должен понимать, что большинство проблем производительности - это именно взаимодействие 1С и СУБД. И без реального взгляда на возможности СУБД любое тестирование бессмысленно.

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

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

(301) В итоге все три пункта связаны по факту с СУБД :)

(305) Если не знать, то да нельзя сделать.

(315) ты просто не сталкивался с реальной оптимизацией,а не с вычищением г-на

(276) не знаю что там у тебя не так выглядит... у всех все нормально.

>Ты же сам должен понимать, что большинство проблем производительности - это именно взаимодействие 1С и СУБД

проблемы 1с из-за 1с

(315) Как раз таки гомнокод и приводит к некорректному обращению к СУБД.

(320) Проблем нет только у Сибирского Ананаса. Просто потому, что самого сибирского ананаса нет :)

(0) Лучше учи что-нибудь с ЗП в твердой валюте )

(312) потом родит еще пару фишек запиндюрив 2-3 "флажка" в совместимость

сделают проведение "асинхронным"... Записать() -> НачатьЗаписывание()


тут зрители аплодируют, аплодируют кончили аплодировать

(323) например, технику выполнения лакокрасочных работ

(324) А что плохого в асинхронности?

+(326) Да и сейчас можно сделать проведение асинхронным, если напрячься.

(326) Она слишком сложная для рядового тупого 1Сника.

(328) Sad but true :(

(326) ничего.. равно как ничего плохого нет в клиентсерверной работе управляемых форм..

(326) плохого в самом подходе - ничего

но как это реализует 1с - это откровенное уебанство

(328) 5-ти минутка самокритичности?..

(332) Ну вообще то это ты жалуешься на асинхронность, мне как-то по барабану - ввели да и пожалуйста.

(333) чукча не читатель...

не отделяешь подход от реализации

(0)Уряяя! Я тоже как и Г1С не знаю УФов.

(334) Накидай в двух словах свою реализацию. Чтобы было с чем сравнить.

(331) Что, как и с итогом по выделенным строкам, самому писать код нужно?

(331) а как же ты еще предлагаешь обходить запрет веб-браузеров на модальные окна?

(338) еще раз.

проблема не в подходе, проблема в реализации

вместо того чтобы "спрятать" параметр в сигнатуру функции 1с делает новую функцию и плодит очередной признак в совместимости. зачем плодить сущности без необходимости??

(339) значит необходимость была.

(339) Приведи примеры реализации из других языков.

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

слабоватый вброс

(341) реализацию чего?

необязательного параметра сигнатуры? это сама 1с "умеет"...

или просто как функцию перегрузить? полно в инете

(0) Странный вопрос. Если ты зубр, то сам почувствуешь момент, когда незнание какой-то технологии станет серьезно сказываться на твоей основной квалификации и кошельке. И, соответственно, освоишь технологию. ИМХО, рано или поздно сделать это придется.
Сама концепция УФ - то что надо. По сути, УФ = ДинамическийИнтерфейс(декларативный) + ТонкийКлиент. Никакие "терминалы" тонкого клиента не заменят. Кроме самоочевидных плюсов УФ открыли дорогу в веб и мобильное приложение. Другое дело, что изначально реализация подкачала и продвигается по факту итерационно. Но вот на "Такси" в последних релизах можно уже смотреть без содрогания. А в 8.3.6 вроде задекларировали лечение тормозов тяжелых форм тяжелых объектов. Развитие идет и идет в нужном направлении. Ругают технологию в основном те, кому тонкий клиент нафиг не впился (но это сегодня, а завтра элементарно может пригодиться). В этом  случае - да. Минуса начинают выпирать. Клиент-сервер ессно несколько сложнее разрабатывать (больше тонкостей надо учитывать, но что приятно - в основном это тонкости общепрограммистского характера а не чисто фичи 1С), больше ограничений при разработке интерфейса. Специфичные глюки и тормоза еще есть. Но даже в этом случае есть вкусные плюшки - динамический интерфейс, полнотекстовый поиск из коробки со сквозной интеграцией ну и по мелочи.

(345) вот скажи - кому ты сейчас все это объяснял?

(346) Частично ответ ТС. Частично реакция на критику УФ. Ну и ЧСВ потешить, куда ж без этого.

(347) с ТС разговаривать - это как разговаривать с копипастой

(348) Да ладно. Производит он в основном оригинальный контент. И при всех своих заскоках, как одинэсник он - выше средней температуры по больнице.

Когда то давно я вообще 1с-кой не занимался. Но занимался другой учетной системой, так получилось что пришлось искать новую работу. Когда меня на собеседовании спросили а знаю ли я 1с четно сказал что не знаю, но благодаря тому опыту котрый у меня есть и прочим знанием имею возможность быстро освоить, через 3 месяца состоялось мое первое успешное внедрение 8-ки.
Человек который называет себя зубром и монстром и при этом боиться остаться без работы из-за того что не знает какую то технологию по моему просто страдает завышенной самооценкой, ты не зубр ты не монстр ты обычный выпускник ПТУ который освоил газовую сварку и четко знает что для того что работать может только с ней, а вот для работы с электрической сваркой ему еще надо учиться.

+ (350) И еще всегда большое "уважение" вызывали люди которые не знают чего то но имеют об этом свое мнение.

(344) "реализацию чего? " Асинхронности

(352) выдыхай уже...

тебе про фому, ты продолжаешь долбить про ерему...

(353) Это ты как-то странно метаешься. То написать две строчки в ПриАктивацииСтроки - труд непосильный, то еще что.

На счет итогов в ДС все таки можно реализовать на уровне платформы проверку на отборы или вообще в виде кнопки - показать итог. Была бы мегарюшечка. Настроил отборы. Нажал кнопку. Если отбор установлен оно выдало итоги, если нет - пусто)

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

(355) Это можно сделать и сейчас. Только надо написать десяток другой строк.

(357) В 8.3.5 нужно написать не десяток-другой, а побольше. В 8.3.6, к счастью, стало проще.

>ты предлагаешь чтобы рефакторинг кода для асинхронного вызова делался всегда автоматически и прозрачно для программиста.

я предлагаю не городить костыли без крайней нужды

>Простой перегрузкой функции такого не реализовать.

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

(357) та написать то можно. Вопрос в том, что бы это было на уровне платформы) В 7ке тоже реализовывали несколько табличных частей в документе и кнопочки сами рисовали. Только 1с прикладная программа, которая позволяет более оперативно решать прикладные задачи. Поэтому не хочется тратить время на игры с формами.

(359) Ну, вот у тебя пара функций - ВвестиЗначение и ПоказатьВводЗначения. Синхронная и асинхронная. Вот у тебя примерно такой код:

Если ВвестиЗначение(Значение) Тогда
   Сообщить("Зашибись"); // для простоты, не пинать
КонецЕсли;

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

>Как ты это заменишь прозрачно на асинхронный вызов? Всё равно ведь должен сработать обработчик события

если он есть в сигнатуре - сработает, нет - не сработает

есть, но нет самого обработчика - сломается. Что собственно сейчас и происходит, не смотря на "новую" функцию

(362) в текущей реализации тоже есть свои плюсы.
Например при переработки конфы на отказ от модальности при простом перегрузе процедур можно не заметить гдк нкжно менять а где нет. а так сразу видно

Я думаю, что в 1с стоял выбор как сделать, и они сделали вот так.

(362) Тьфу. Дошло. Ты просто небольшое упрощение предлагал, чтобы старая функция могла выступать и инициатором асинхронного вызова? А я вообразил невесть что :) Не, ну это вообще непринципиально. Я тут даже на стороне разработчиков 1С. Переписывать хоть так, хоть эдак. А так, несмотря на еще одну сущность, более наглядно получается.

>Например при переработки конфы на отказ от модальности при простом перегрузе процедур можно не заметить гдк нкжно менять а где нет

ради этого 1с внесло инструментарий по рефакторингу кода

>Переписывать хоть так, хоть эдак. А так, несмотря на еще одну сущность, более наглядно получается.

не согласен

1. доп. костыли в совместимости
2. .удацкий выбор имен для "новых" функций - вводят нефункциональный префикс "Начать"

(366) не всегда можно автоматом

(368) высосаные из пальца извраты предлагаю опустить

(367)
1. Эти "доп-костыли" введены для удобства, как ни странно. Чтобы этот момент можно было контролировать на уровне "рубильника". И при дальнейшей разработке физически не могли воткнуть модальное окно.
2. Это уже вкусовщина, непринципиально

>Эти "доп-костыли" введены для удобства, как ни странно. Чтобы этот момент можно было контролировать на уровне "рубильника"

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

я не думаю что это "удобно"

(371) Конкретно этот рубильник как раз даст по рукам, не позволив сделать вредную вещь по незнанию. Несомненно, это удобно. А вообще, в период активного развития платформы естественно приходится изучать её состояния "до", "после" и "во время". Это не вопрос удобства. Это неизбежно.

Опять пилишь пилишь, бац - а прикрепление форм убрали, мать перемать все как обычно... может вернут к 9-ой версии.

(373) китайское проклятие - жить в эпоху перемен. 1с не хочет тупо рубить бабло, предпочитает любить мозг конфигурастам. ;-)