Ускорить ВЫБРАТЬ КОЛИЧЕСТВО(*) ИЗ РегистрСведений.<> [Вопрос 1С Эксперт]
Задача с экзамена 1С Эксперт. (частично обсуждение было )
Текст задачи:
"В базе работают 1000 пользователей. Есть регистр сведений в нем 100 млн записей. запрос select count выполняется t= 60 сек. Необходимо сделать так, чтобы данные были получены за t = 1c."
Можете ли Вы подсказать, пожалуйста, в каком направлении мыслить/искать? Преподаватель говорит, есть порядка 12 способов решить задачу.
Коллеги отвечали преподавателю (Александру Морозову) по-разному, мы заранее придумали что можно отетить и отвечали
1) требуется выполнение всех регламентных операций, дефрагментация, реиндексация
2) требуется создание некластерного индекса или сделать регистр таким, чтобы был хотя бы один некластерный индекс, т.к. scan по нему быстрее скана по кластерному индексу
Первые два совета недостаточны.
3) Пробовали ответить, что нужно хранить заведомо где-то количество в этом регистре, типо константы и при записи наборов записей или удалении - следить за тем, сколько у нас записей (жертвуем записью ради запроса по выбору количества записей) - тоже не подходит
4) Коллеги предлагали из DMV представлений или статистики получать значение - тоже преподаватель говорит нарушение лиц.соглашения, нельзя в обход rphost подключаться к SQL базе напрямую
5) может быть нужно секционирование предложить было? Но Вы писали где-то, что его оч.сложно настроить и нужны знания сертифицированного специалиста MS SQL
6) Может быть надо MDOP = 1 выставить? Т.к. если 60 секунд выполняется сканирование - может быть происходит блокировка параллельных сканов или что-то такое.
7) Мы предлагали преподавателю перестроить бизнес-логику решения. Тоже не "прокатило".
Если подскажете, что можно было бы сделать, или где почитать (направление), очень многие люди будут благодарны!
Сейчас это задание как триггер, отсеиватель, добрая часть людей отсеивается просто в самом конце экзамена:)
Спасибо!!!
Текст задачи:
"В базе работают 1000 пользователей. Есть регистр сведений в нем 100 млн записей. запрос select count выполняется t= 60 сек. Необходимо сделать так, чтобы данные были получены за t = 1c."
Можете ли Вы подсказать, пожалуйста, в каком направлении мыслить/искать? Преподаватель говорит, есть порядка 12 способов решить задачу.
Коллеги отвечали преподавателю (Александру Морозову) по-разному, мы заранее придумали что можно отетить и отвечали
1) требуется выполнение всех регламентных операций, дефрагментация, реиндексация
2) требуется создание некластерного индекса или сделать регистр таким, чтобы был хотя бы один некластерный индекс, т.к. scan по нему быстрее скана по кластерному индексу
Первые два совета недостаточны.
3) Пробовали ответить, что нужно хранить заведомо где-то количество в этом регистре, типо константы и при записи наборов записей или удалении - следить за тем, сколько у нас записей (жертвуем записью ради запроса по выбору количества записей) - тоже не подходит
4) Коллеги предлагали из DMV представлений или статистики получать значение - тоже преподаватель говорит нарушение лиц.соглашения, нельзя в обход rphost подключаться к SQL базе напрямую
5) может быть нужно секционирование предложить было? Но Вы писали где-то, что его оч.сложно настроить и нужны знания сертифицированного специалиста MS SQL
6) Может быть надо MDOP = 1 выставить? Т.к. если 60 секунд выполняется сканирование - может быть происходит блокировка параллельных сканов или что-то такое.
7) Мы предлагали преподавателю перестроить бизнес-логику решения. Тоже не "прокатило".
Если подскажете, что можно было бы сделать, или где почитать (направление), очень многие люди будут благодарны!
Сейчас это задание как триггер, отсеиватель, добрая часть людей отсеивается просто в самом конце экзамена:)
Спасибо!!!
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Закинул уважаемым товарищам в скайп:
Добрый день. Мы (сообщество Инфостарт) ломаем голову над вопросом. Может подскажете чего-то? Очень (прямо чрезвычайно) будем признательны! Ссылка . Тема Ускорить ВЫБРАТЬ КОЛИЧЕСТВО(*) ИЗ РегистрСведений.<> [Вопрос 1С Эксперт]
Может таки чего-то напишут...
Добрый день. Мы (сообщество Инфостарт) ломаем голову над вопросом. Может подскажете чего-то? Очень (прямо чрезвычайно) будем признательны! Ссылка . Тема Ускорить ВЫБРАТЬ КОЛИЧЕСТВО(*) ИЗ РегистрСведений.<> [Вопрос 1С Эксперт]
Может таки чего-то напишут...
со слов автора поста похоже что преподаватель страдает херней: можно пожертвовать чем то ради скорости, тогда будет быстрее
например можно пожертвовать достоверностью и в каждой строке хранить номер строки, иметь индекс по полю с номером чтобы крайний номер соответствовал количеству строк и спрашивать самый большой номер таким образом с некоторой достоверностью можно быстро получить количество
также можно получить статистику субд и оттуда определить количество, но это тоже жертвовать достоверностью
возможно платформа тоже в каком то методе получает кэшированное значение
но то что преподаватель говорит про не лицензионность то это "жалкий" аргумент, он же сам поднял технический вопрос
например можно пожертвовать достоверностью и в каждой строке хранить номер строки, иметь индекс по полю с номером чтобы крайний номер соответствовал количеству строк и спрашивать самый большой номер таким образом с некоторой достоверностью можно быстро получить количество
также можно получить статистику субд и оттуда определить количество, но это тоже жертвовать достоверностью
возможно платформа тоже в каком то методе получает кэшированное значение
но то что преподаватель говорит про не лицензионность то это "жалкий" аргумент, он же сам поднял технический вопрос
(113) Мотивация аргументов в данном случае не имеет значения. Это всего лишь условия задачи, довольно синтетической. Ты же не придираешься к надуманности условий в арифметических задачках из учебников :)
Преподавателю ведь нужно не реальную проблему решить любой ценой. Он добивается какого-то очень конкретного известного ему ответа, который удовлетворяет сформулированным ограничениям и до которого должны додуматься экзаменуемые.
В сформулированные ограничения по версии ТС вошли:
1) не использовать прямые запросы со стороны 1С
2) не хранить количество записей "сбоку", жертвуя скоростью и параллельностью записи
Опираться на некую нумерацию - очень сомнительная идея, так как процент погрешности при этом фактически неконтролируем - вплоть до полной недостоверности.
Преподавателю ведь нужно не реальную проблему решить любой ценой. Он добивается какого-то очень конкретного известного ему ответа, который удовлетворяет сформулированным ограничениям и до которого должны додуматься экзаменуемые.
В сформулированные ограничения по версии ТС вошли:
1) не использовать прямые запросы со стороны 1С
2) не хранить количество записей "сбоку", жертвуя скоростью и параллельностью записи
Опираться на некую нумерацию - очень сомнительная идея, так как процент погрешности при этом фактически неконтролируем - вплоть до полной недостоверности.
(114) ИМХО, тогда ковырять в сторону получения статистики и плана выполнения запроса средствами платформы.
Технологический журнал, вероятно, не покажет т.к. требует, по-идее, выполнения запроса.
Сама постановка задачи говорит о получении статистики иным способом.
Может объект СхемаЗапроса при установке текста опрашивает план выполнения запроса?
Технологический журнал, вероятно, не покажет т.к. требует, по-идее, выполнения запроса.
Сама постановка задачи говорит о получении статистики иным способом.
Может объект СхемаЗапроса при установке текста опрашивает план выполнения запроса?
Добавить числовое измерение. Проиндексировать.
Пронумеровать с 1.
При добавлении записи брать максимальное значение измерения, прибавлять 1, записывать.
При удалении записи запоминать значение измерения, находить запись с максимальным значением, записывать в этой записи сохраненное значение удаляемой записи.
Т.о. будет поддерживаться сплошная нумерация.
Количество записей получать по максимальному значению этого измерения.
Но это решение "сбоку", хотя вроде бы не попадает в
Пронумеровать с 1.
При добавлении записи брать максимальное значение измерения, прибавлять 1, записывать.
При удалении записи запоминать значение измерения, находить запись с максимальным значением, записывать в этой записи сохраненное значение удаляемой записи.
Т.о. будет поддерживаться сплошная нумерация.
Количество записей получать по максимальному значению этого измерения.
Но это решение "сбоку", хотя вроде бы не попадает в
Первые два совета
.
(118)
Остроумно :)
Но во избежание дублей номеров придется отказываться от параллельной записи, что по сути не отличается от хранения счетчика записей в константе.
При добавлении записи брать максимальное значение измерения, прибавлять 1, записывать.
При удалении записи запоминать значение измерения, находить запись с максимальным значением, записывать в этой записи сохраненное значение удаляемой записи.
Т.о. будет поддерживаться сплошная нумерация.
При удалении записи запоминать значение измерения, находить запись с максимальным значением, записывать в этой записи сохраненное значение удаляемой записи.
Т.о. будет поддерживаться сплошная нумерация.
Остроумно :)
Но во избежание дублей номеров придется отказываться от параллельной записи, что по сути не отличается от хранения счетчика записей в константе.
Запись в константу зависнит на ожиданиях.
Возможно такое решение:
1. Создать служебный РС (периодический(?)) с ресурсом "Количество записей"
2. При записи в основной регистр добавлять запись в служебный РС, предварительно прочитав из него СрезПоследних и прибавив 1
3. Фоновым заданием чистить старые записи
Небольшие потери при записи, но моментальные при чтении.
Возможно такое решение:
1. Создать служебный РС (периодический(?)) с ресурсом "Количество записей"
2. При записи в основной регистр добавлять запись в служебный РС, предварительно прочитав из него СрезПоследних и прибавив 1
3. Фоновым заданием чистить старые записи
Небольшие потери при записи, но моментальные при чтении.
(121) хотя... другой вариант:
1. Создать служебный РС с измерением момент времени в миллисекундах и ресурсом "Количество записей"
2. Пишем на начало дня количество записей
3. В течение дня при записи в основной регистр добавляем значение "+1", при удалении добавляем "-1"
4. Фоном ночью сворачиваем и повторяем с п.2
Соответственно, в запросе берем сумму по полю "Количество записей" уже из второго регистра. Псевдостатистика своими силами.
1. Создать служебный РС с измерением момент времени в миллисекундах и ресурсом "Количество записей"
2. Пишем на начало дня количество записей
3. В течение дня при записи в основной регистр добавляем значение "+1", при удалении добавляем "-1"
4. Фоном ночью сворачиваем и повторяем с п.2
Соответственно, в запросе берем сумму по полю "Количество записей" уже из второго регистра. Псевдостатистика своими силами.
Да какая разница, какой ответ.
У 1С есть:
- ИТС с документацией;
- ТВКВ;
- партнерский форум с обсуждениями;
- книга по проф. разработке;
- курсы.
Всё это по 4-м (8.0, 8.1, 8.2, 8.3) платформам, также добавьте режимы совместимости, в источниках есть противоречивая информация.
Автор вопроса также мог ошибаться.
Оптимизация работы с данными зависит от анализа и статистики использования данных. Про регистр ничего не известно. Может это адресный классификатор и изменения в нем делаются раз в месяц?
У 1С есть:
- ИТС с документацией;
- ТВКВ;
- партнерский форум с обсуждениями;
- книга по проф. разработке;
- курсы.
Всё это по 4-м (8.0, 8.1, 8.2, 8.3) платформам, также добавьте режимы совместимости, в источниках есть противоречивая информация.
Автор вопроса также мог ошибаться.
Оптимизация работы с данными зависит от анализа и статистики использования данных. Про регистр ничего не известно. Может это адресный классификатор и изменения в нем делаются раз в месяц?
(128) Я в 89 и 90 постах приводил результаты замера на своей базе, получение 50+ млн записей, время от 0,3 до 2,5 секунд (верхний предел видимо в момент пиковой нагрузки на регистр со стороны пользователей), так что 100 млн прочитать за 1 сек вполне реально. Поэтому вряд ли автор вопроса ошибся. Все обсуждения с доп регистрами, реквизитами, константами не прокатят, уже писалось что сдающие экзамен на эксперта всё это предлагали и не прокатило. Тут скорее всего ключевая фраза - это то, что читают одновременно 1000 пользователей, видимо с этим такая задержка связана.
(133) Вопрос про средства платформы.
Думаю, дополнительный регистр накопления не поменяет логику решения.
Отдельный регистр сведений с информацией о количестве, который скорее всего имелся в виду прошлом ответе, это плохое решение, будет блокироваться при обновлении.
А вот отдельный дополнительный регистр накопления, по-моему, вполне вариант.
Думаю, дополнительный регистр накопления не поменяет логику решения.
Отдельный регистр сведений с информацией о количестве, который скорее всего имелся в виду прошлом ответе, это плохое решение, будет блокироваться при обновлении.
А вот отдельный дополнительный регистр накопления, по-моему, вполне вариант.
(135) При 1000 пользователей если работа в режиме версионника, то можно получить давление на tempdb (при размещении там "версий"), но поскольку мы читаем крайнюю строку всего одну, то максимум будет 1000 версий и
60х кратного ухудшения не будет, разве что админ с кривыми руками
кроме того не понятно что люди пишут "не прокатит" хранить значение крайнего номера строки, что значит ломается бизнес-логика, аргументации - ноль
хотелось бы для начала увидеть оригинал "постановки задачи"
и для какой реальной задачи идет подсчет строк
60х кратного ухудшения не будет, разве что админ с кривыми руками
кроме того не понятно что люди пишут "не прокатит" хранить значение крайнего номера строки, что значит ломается бизнес-логика, аргументации - ноль
хотелось бы для начала увидеть оригинал "постановки задачи"
и для какой реальной задачи идет подсчет строк
(163)Можно, даже два:
1) преподу нужно завалить как можно больше людей, чтобы эксперты не слишком расплодились.
2) нужно как можно больше людей загнать на эксклюзивные платные курсы, которые он сам и ведет.
Вот такие реальные задачи:)
1) преподу нужно завалить как можно больше людей, чтобы эксперты не слишком расплодились.
2) нужно как можно больше людей загнать на эксклюзивные платные курсы, которые он сам и ведет.
Вот такие реальные задачи:)
(148)Я имел в виду, может быть это один из правильных ответов: настроить по правам, всем запретить, одному (начальнику) оставить, тогда параллельного чтения не будет, начальник спокойно будет получать нужные данные за 1 сек, остальные - брать при необходимости эти данные по служебной записке.
(156) Вариант параллельных вычислений уже обсуждался, но как-то вяло. Главный вопрос - как бить по диапазонам.
Теоретически можно завести дополнительный индексированный ресурс, куда писать МАКСИМУМ плюс один для каждой записи. И пофиг, что там могут быть дырки и дубли. Если такое допустимо по условию задачи (а это не до конца понятно), то тогда может и получится эффективно распараллелить.
Теоретически можно завести дополнительный индексированный ресурс, куда писать МАКСИМУМ плюс один для каждой записи. И пофиг, что там могут быть дырки и дубли. Если такое допустимо по условию задачи (а это не до конца понятно), то тогда может и получится эффективно распараллелить.
накопал тут .
Может есть аналогичная технология применительно к MSQL?
Применительно к MSQL:
1. Как вариант создать RAM диск и выкинуть на него эту таблицу (через файловые группы)
или
2. или когда-то softpoint-а как я понимаю что это т.е. фактически означает нарушение лицензионного соглашения.
Может есть аналогичная технология применительно к MSQL?
Применительно к MSQL:
1. Как вариант создать RAM диск и выкинуть на него эту таблицу (через файловые группы)
или
2. или когда-то softpoint-а как я понимаю что это т.е. фактически означает нарушение лицензионного соглашения.
(159) prewarm, насколько я понимаю, это всего лишь предварительный "прогрев" кэша, чтобы сразу при старте работы пользователей критичные данные уже находились в кэше и пользователи начинали работу без лагов. Т.е. оно тупо выполняет предварительные обращения к данным таблиц. Никакого "удержания таблицы в памяти" при этом не происходит - происходит обычное кэширование СУБД. Не, ну если таблица небольшая, а память отведенная СУБД для кэша позволяет - то ессно будет в памяти находиться какое-то время.
Помню, Лустин в сумбурном вебинаре по правильной готовке постгри для 1С использовал "прогрев" таблиц с конфой и еще чего-то там.
Только, EМНИП, для этого использовалось не отдельное расширение, а чей-то гитхабовский скрипт то ли на перле, то ли на питоне.
Только, EМНИП, для этого использовалось не отдельное расширение, а чей-то гитхабовский скрипт то ли на перле, то ли на питоне.
(168) для мелкософтовского на стеке так написано:
По сцылке разбираются три запроса, один из которых выполняется мгновенно, а два других - очень долго. На это отвечают, что скул использует "самый узкий" некластерный индекс для того, чтобы получить количество строк. Если нет некластерных индексов - используется скан таблицы (= скан кластерного индекса, ибо он и есть в случае 1С таблица). Ну и дальше, если только кластерный индекс у таблицы, предлагают использовать динамические представления и прочие системные таблицы.
Отсюда как бы один простой ответ вытекает. Сами догадаетесь или нужно подсказать?
For the other two queries, SQL Server would use the following rule. To perform a query like SEL ECT COUNT(*), SQL Server will use the narrowest non-clustered index to count the rows. If the table does not have any non-clustered index, it will have to scan the table.
Also, if your table has a clustered index you can get your count even faster using the following query (borrowed fr om this site Get Row Counts Fast!)
Also, if your table has a clustered index you can get your count even faster using the following query (borrowed fr om this site Get Row Counts Fast!)
По сцылке разбираются три запроса, один из которых выполняется мгновенно, а два других - очень долго. На это отвечают, что скул использует "самый узкий" некластерный индекс для того, чтобы получить количество строк. Если нет некластерных индексов - используется скан таблицы (= скан кластерного индекса, ибо он и есть в случае 1С таблица). Ну и дальше, если только кластерный индекс у таблицы, предлагают использовать динамические представления и прочие системные таблицы.
Отсюда как бы один простой ответ вытекает. Сами догадаетесь или нужно подсказать?
(169)
Да, подскажите, как это всё реализовать средствами платформы 1С!?
For the other two queries, SQL Server would use the following rule. To perform a query like SEL ECT COUNT(*), SQL Server will use the narrowest non-clustered index to count the rows. If the table does not have any non-clustered index, it will have to scan the table.
Also, if your table has a clustered index you can get your count even faster using the following query (borrowed fr om this site Get Row Counts Fast!)
Also, if your table has a clustered index you can get your count even faster using the following query (borrowed fr om this site Get Row Counts Fast!)
Да, подскажите, как это всё реализовать средствами платформы 1С!?
(170)
1. Некластерный индекс (самый узкий). Читаем об индексации соответствующей таблицы в 1С (измерение1, ...), чтобы его получить.
2. Меняем запрос, добавляя в него условие по индексированному полю и агрегат по количеству этого поля.
3. Профит.
как это всё реализовать средствами платформы 1С
По сути нужно:
1. Некластерный индекс (самый узкий). Читаем об индексации соответствующей таблицы в 1С (измерение1, ...), чтобы его получить.
2. Меняем запрос, добавляя в него условие по индексированному полю и агрегат по количеству этого поля.
3. Профит.
(172) нечто типа. На сколько я знаю, если добавить поле с индексом в регистр, то 1С создает по нему отдельный индекс.
Вот интереса ради для постгреса получил такой план запроса для таблицы _inforg167 теста Гилева:
В общем и целом не удалось мне никоим образом заставить это работать иначе, как "Seq Scan on _inforg167" - т.е. всегда в постгресе сканируется таблица.
Вот интереса ради для постгреса получил такой план запроса для таблицы _inforg167 теста Гилева:
SELECT COUNT(_recorderrref)
FR OM public._inforg167"Aggregate (cost=168.50..168.51 rows=1 width=8)"
-> Seq Scan on _inforg167 (cost=0.00..156.00 rows=5000 width=17)
-> Seq Scan on _inforg167 (cost=0.00..156.00 rows=5000 width=17)
В общем и целом не удалось мне никоим образом заставить это работать иначе, как "Seq Scan on _inforg167" - т.е. всегда в постгресе сканируется таблица.
(178)
выросло поколение, которое "плохую" 1С заменяет "хорошим" другим "не 1С"...
люди с одним из самым престижных сертификатов от 1С говорят что 1С гов.о...
фиерия, чего тогда требовать от более слабых специалистов
Но регулярки куда лучше для анализа логов, чем 1С.
на этом можно закончить дискуссию
выросло поколение, которое "плохую" 1С заменяет "хорошим" другим "не 1С"...
люди с одним из самым престижных сертификатов от 1С говорят что 1С гов.о...
фиерия, чего тогда требовать от более слабых специалистов
(179)
Если говорить об 1С, то есть весьма много претензий к ней от специалистов, которые действительно разбираются в стеке технологий, связанных с хранением и обработкой данных. 1С - медленная. Не в плане выборки из БД - это делает SQL-сервер, а в плане интерпретации кода собственного языка. 1С содержит много трудно-отлавливаемых багов (например, с ошибкой запроса POST к данным формы, 1С рекомендуют переходить на асинхронное выполнение кода обработки/отчета/прочего для того, чтобы потом не было потери контекста формы, вызывающей эту ошибку, хотя открыто и не признают, что ошибка из-за багов в платформе, в результате чего теряется контекст формы, вызывающий продолжительный серверный метод). 1С с трудом позволяет создавать многопоточные механизмы, ибо для этого отсутствуют структуры для хранения общих данных потоков, механизмы синхронизации потоков (семафоры, мьютексы) - все это приходится создавать с помощью дополнительных механизмов (либо вообще использовать что-то не из мира 1С).
Ну вот за сколько 1С сможет вытащить из лога в пару ГиБ отфильтрованные значения? Grep это сделает на порядок быстрее. Так зачем использовать 1С? Какая разница, на чем написать анализатор логов? Да, можно и на 1С, но если есть более простые и скоростные механизмы, то зачем так себя ограничивать-то?
ЗЫ: есть. конечно, те, кто в свое время остановился в развитии (о чем может свидетельствовать, например, тест Гилева, который до сих пор работает в толстом клиенте и не умеет асинхронно подгружать результаты, асинхронно выполнять сам тест, что приводит к фризу окна, что весьма неприятно смотрится в Unity, не говоря уже об Aero) - они нашли себе нишу и живут там в своей зоне комфорта. Им, предположу, обидно, что они не в состоянии развиваться дальше, поэтому они утешают себя мыслью о том, что развиваться нужно в глубь того, что уже есть, сужая горизонт до точки. Их право.
выросло поколение, которое "плохую" 1С заменяет "хорошим" другим "не 1С"
Выросло поколение, которое кроме 1С ничего не хочет знать.
Если говорить об 1С, то есть весьма много претензий к ней от специалистов, которые действительно разбираются в стеке технологий, связанных с хранением и обработкой данных. 1С - медленная. Не в плане выборки из БД - это делает SQL-сервер, а в плане интерпретации кода собственного языка. 1С содержит много трудно-отлавливаемых багов (например, с ошибкой запроса POST к данным формы, 1С рекомендуют переходить на асинхронное выполнение кода обработки/отчета/прочего для того, чтобы потом не было потери контекста формы, вызывающей эту ошибку, хотя открыто и не признают, что ошибка из-за багов в платформе, в результате чего теряется контекст формы, вызывающий продолжительный серверный метод). 1С с трудом позволяет создавать многопоточные механизмы, ибо для этого отсутствуют структуры для хранения общих данных потоков, механизмы синхронизации потоков (семафоры, мьютексы) - все это приходится создавать с помощью дополнительных механизмов (либо вообще использовать что-то не из мира 1С).
Ну вот за сколько 1С сможет вытащить из лога в пару ГиБ отфильтрованные значения? Grep это сделает на порядок быстрее. Так зачем использовать 1С? Какая разница, на чем написать анализатор логов? Да, можно и на 1С, но если есть более простые и скоростные механизмы, то зачем так себя ограничивать-то?
ЗЫ: есть. конечно, те, кто в свое время остановился в развитии (о чем может свидетельствовать, например, тест Гилева, который до сих пор работает в толстом клиенте и не умеет асинхронно подгружать результаты, асинхронно выполнять сам тест, что приводит к фризу окна, что весьма неприятно смотрится в Unity, не говоря уже об Aero) - они нашли себе нишу и живут там в своей зоне комфорта. Им, предположу, обидно, что они не в состоянии развиваться дальше, поэтому они утешают себя мыслью о том, что развиваться нужно в глубь того, что уже есть, сужая горизонт до точки. Их право.
(181)
Если говорить об 1С, то есть весьма много претензий к ней от специалистов, которые действительно разбираются в стеке технологий, связанных с хранением и обработкой данных. 1С - медленная. Не в плане выборки из БД - это делает SQL-сервер, а в плане интерпретации кода собственного языка. 1С содержит много трудно-отлавливаемых багов (например, с ошибкой запроса POST к данным формы, 1С рекомендуют переходить на асинхронное выполнение кода обработки/отчета/прочего для того, чтобы потом не было потери контекста формы, вызывающей эту ошибку, хотя открыто и не признают, что ошибка из-за багов в платформе, в результате чего теряется контекст формы, вызывающий продолжительный серверный метод). 1С с трудом позволяет создавать многопоточные механизмы, ибо для этого отсутствуют структуры для хранения общих данных потоков, механизмы синхронизации потоков (семафоры, мьютексы) - все это приходится создавать с помощью дополнительных механизмов (либо вообще использовать что-то не из мира 1С).
Про претензии в плане интерпретации кода собственного языка:
Зачастую все эти претензии суть кривого кода не в платформе, а в конфигурации.
Про баг с ошибкой запроса POST к данным формы:
Если Вы запустили тягомотный процесс и передали контекст формы на сервер, то клиент может зависнуть.
Это вполне ожидаемо.
Про многопоточность:
А что с легкостью позволяет создавать многопоточные механизмы?
Erlang, Scala? Да и, многопоточность в каком именно смысле Вам понадобилась?
Если говорить об 1С, то есть весьма много претензий к ней от специалистов, которые действительно разбираются в стеке технологий, связанных с хранением и обработкой данных. 1С - медленная. Не в плане выборки из БД - это делает SQL-сервер, а в плане интерпретации кода собственного языка. 1С содержит много трудно-отлавливаемых багов (например, с ошибкой запроса POST к данным формы, 1С рекомендуют переходить на асинхронное выполнение кода обработки/отчета/прочего для того, чтобы потом не было потери контекста формы, вызывающей эту ошибку, хотя открыто и не признают, что ошибка из-за багов в платформе, в результате чего теряется контекст формы, вызывающий продолжительный серверный метод). 1С с трудом позволяет создавать многопоточные механизмы, ибо для этого отсутствуют структуры для хранения общих данных потоков, механизмы синхронизации потоков (семафоры, мьютексы) - все это приходится создавать с помощью дополнительных механизмов (либо вообще использовать что-то не из мира 1С).
Про претензии в плане интерпретации кода собственного языка:
Зачастую все эти претензии суть кривого кода не в платформе, а в конфигурации.
Про баг с ошибкой запроса POST к данным формы:
Если Вы запустили тягомотный процесс и передали контекст формы на сервер, то клиент может зависнуть.
Это вполне ожидаемо.
Про многопоточность:
А что с легкостью позволяет создавать многопоточные механизмы?
Erlang, Scala? Да и, многопоточность в каком именно смысле Вам понадобилась?
(184)
По поводу интерпретации, то даже в PHP5 цикл работает быстрее, чем в 1С, не говоря уже о питоне или PHP7, в которых производительность выше.
По поводу многопоточности, что любой функциональный язык паралеллит процесс вычислений, так что можно сказать, что программист в этом случае даже не заморачивается - за него все делает интерпретатор или компилятор. Но если говорить об управляемой многопоточности, то в тех языках, где она используется прямо, есть и общие хранилища, и средства избегания коллизий - семафоры, мьютексы, блокировки. По-сути, СУБД для 1С - это как раз механизм, с которым одновременно работает множество инстансов 1С (сеансов), которые коллективно конкурируют за ресурсы, в связи с этим так много внимания уделяется блокировкам и разделителям, уровням изоляции и прочим механизмам обеспечения непротиворечивости данных. Для самого языка таких механизмов нет, что создает определенные трудности реализации алгоритмов распараллеливания вычислений.
Если Вы запустили тягомотный процесс и передали контекст формы на сервер, то клиент может зависнуть.
Клиент точно зависнет, пока сервер не отработает. Но это не должно приводить к проблемам с формой (ошибка POST приводит к безоговорочному закрытию платформы).
По поводу интерпретации, то даже в PHP5 цикл работает быстрее, чем в 1С, не говоря уже о питоне или PHP7, в которых производительность выше.
По поводу многопоточности, что любой функциональный язык паралеллит процесс вычислений, так что можно сказать, что программист в этом случае даже не заморачивается - за него все делает интерпретатор или компилятор. Но если говорить об управляемой многопоточности, то в тех языках, где она используется прямо, есть и общие хранилища, и средства избегания коллизий - семафоры, мьютексы, блокировки. По-сути, СУБД для 1С - это как раз механизм, с которым одновременно работает множество инстансов 1С (сеансов), которые коллективно конкурируют за ресурсы, в связи с этим так много внимания уделяется блокировкам и разделителям, уровням изоляции и прочим механизмам обеспечения непротиворечивости данных. Для самого языка таких механизмов нет, что создает определенные трудности реализации алгоритмов распараллеливания вычислений.
(186) у меня к самой платформе в плане производительности "языкового" движка претензий нет.
>>что создает определенные трудности реализации алгоритмов распараллеливания вычислений
ИМХО, всё зависит от задач. Можно получить, например остатки и продажи параллельно, да еще и асинхронно, если оно того стОит.
>>что создает определенные трудности реализации алгоритмов распараллеливания вычислений
ИМХО, всё зависит от задач. Можно получить, например остатки и продажи параллельно, да еще и асинхронно, если оно того стОит.
(187)
у меня к самой платформе в плане производительности "языкового" движка претензий нет
Не поверите, но у меня тоже нет претензий, но есть сравнительная информация о том, что можно работать и на порядок быстрее. Вот, например, почему в файловой базе тест Гилева при режимах сбалансированной производительности и максимальной производительности не особо отличается (ИМХО, вообще не отличается), а в серверном варианте - в 1,5-2 раза (у меня на Ryzen 5 1600 в OnDemand - 24,5, а в Performance - 36,78)? Вроде одно дела делают, да?
(181)
(188)
если же возвратиться к обсуждению 1С:Эксперта и в частности к решаемой задаче, то осталось ощущение что правильней провести ревизию условий задачи, похоже что важные акценты при трансляции сюда были потеряны
Так зачем использовать 1С? Какая разница, на чем написать анализатор логов?
может быть потому что не надо писать, уже есть готовые обработки анализа логов
есть весьма много претензий к ней от специалистов, которые действительно разбираются в стеке технологий
ну если вы такой умный, устройтесь в фирму 1С, исправьте там все
конечно, те, кто в свое время остановился в развитии
на последнем инфостарте мы презентовали обработку, способную анализировать запросы на неоптимальности и выдавать готовые рекомендации по исправлению, фирма 1С и франчайзи пока к этому уровню не приблизились, может сначала догоните?
(188)
Вроде одно дела делают, да?
так разными способами в разной архитектурой да еще и с разным уровнем обеспечения возможности коллективной обработки данных
если же возвратиться к обсуждению 1С:Эксперта и в частности к решаемой задаче, то осталось ощущение что правильней провести ревизию условий задачи, похоже что важные акценты при трансляции сюда были потеряны
(190) дейстаительно, в задаче чтото не так, ибо без подмены запроса получить колво элементов за приемлемое время средствами 1с нереально.
А по поводу инструментов, которые уже есть - это хорошо. Но grep regexp написать в некотором количестве случаев будет банально быстрее. Ну и sed'ом изменить конфиг файлы тоже куда легче, чем открывать это в редакторе. А так - есть ЦУП, который много чего умеет, хоть и не так быстро.
А по поводу инструментов, которые уже есть - это хорошо. Но grep regexp написать в некотором количестве случаев будет банально быстрее. Ну и sed'ом изменить конфиг файлы тоже куда легче, чем открывать это в редакторе. А так - есть ЦУП, который много чего умеет, хоть и не так быстро.
(191) есть наши инструменты, которые бесплатно с приемлемой скоростью парсят ТЖ (быстрее не надо), но из-за "политики фирмы 1С" их не замечать усложняют жизнь специалистам на 1С:Эксперте
откуда это вообще взялось "быстрее обсчитать логи тж"? это ложная цель
есть два класса задач - оперативные для оценки ситуации
и аналитические для реализации решений
с учетом того что исправленный код надо сначала а) написать б) протестировать в копии в) найти технологическое окно вкатить изменения в продуктив - обсчитать логи за 3 минуты или 10 минут погоды не делает вообще, даже цуп может сгодится
ну а качественно решать аналитические задачи можно только если собирать логи круглосуточно для полностью репрезентативной картины производительности (кроме наших инструментов я альтернативы не знаю)
если же говорить про скорость обсчета логов, то во-первых победить в этой задачке сомнительный приз, так как это промежуточный этап, главное это воспользоваться результатом анализа логов и довести до реального ускорения, а не заниматься изучением всего и вся
мы в свое время пробовали использовать субд для ускорения обсчета, тоже вариант, однако это увеличивает организационные затраты - реальный опыт показывает, что нужно минимизировать охват разных механизмов, только в конкретных случаях, когда обычные подходы не решают задачу, уже идти в сторону и использовать хранимки и т.п.
не надо имхо на экзамене 1С:Эксперт требовать все больше и больше знаний (я то был на самом первом потоке) - это путь в никуда, в итоге получится специалист "по вершкам знаний", и ничего глубоко
откуда это вообще взялось "быстрее обсчитать логи тж"? это ложная цель
есть два класса задач - оперативные для оценки ситуации
и аналитические для реализации решений
с учетом того что исправленный код надо сначала а) написать б) протестировать в копии в) найти технологическое окно вкатить изменения в продуктив - обсчитать логи за 3 минуты или 10 минут погоды не делает вообще, даже цуп может сгодится
ну а качественно решать аналитические задачи можно только если собирать логи круглосуточно для полностью репрезентативной картины производительности (кроме наших инструментов я альтернативы не знаю)
если же говорить про скорость обсчета логов, то во-первых победить в этой задачке сомнительный приз, так как это промежуточный этап, главное это воспользоваться результатом анализа логов и довести до реального ускорения, а не заниматься изучением всего и вся
мы в свое время пробовали использовать субд для ускорения обсчета, тоже вариант, однако это увеличивает организационные затраты - реальный опыт показывает, что нужно минимизировать охват разных механизмов, только в конкретных случаях, когда обычные подходы не решают задачу, уже идти в сторону и использовать хранимки и т.п.
не надо имхо на экзамене 1С:Эксперт требовать все больше и больше знаний (я то был на самом первом потоке) - это путь в никуда, в итоге получится специалист "по вершкам знаний", и ничего глубоко
(194)
(194)
Как писали Стругацкие: "Инструкция - это для тех, кто не умеет". Вот те, кто не умеет, - пусть и пользуются средствами, которые это умеют за них. Но повышать уровень 1С-ников - задача необходимая, ибо какой эксперт может быть из человека, который в Linux ни в зуб ногой. А если уж разобрался, то и grep освоил.
даже цуп может сгодится
Точно!
(194)
если же говорить про скорость обсчета логов, то во-первых победить в этой задачке сомнительный приз, так как это промежуточный этап
А вот тут не совсем. Этот промежуточный этап вряд ли будет однократным, т.к. отладка одних механизмов выкидывает в топ другие, которые сейчас вот прямо пока не видны. Экономить 20 минут один раз и 20 минут 100 раз - несопоставимые цифры. Для экспресс-анализа как раз grep лучше всего, но уметь им пользоваться - личное дело специалиста. Не умеет - пусть покупает сервисы, умеет - может и бесплатно проанализировать с помощью подручных средств (да и быстрее).
Как писали Стругацкие: "Инструкция - это для тех, кто не умеет". Вот те, кто не умеет, - пусть и пользуются средствами, которые это умеют за них. Но повышать уровень 1С-ников - задача необходимая, ибо какой эксперт может быть из человека, который в Linux ни в зуб ногой. А если уж разобрался, то и grep освоил.
(195)
откуда такие цифры, что вы там сто раз делаете то?!! (в ужасе)
1. те кто покупают ничего не умеют -
и это ЛОЖЬ!
т.е. платные инструменты, которые автоматизируют разбор логов - это не экономия времени? т.е. лучше руками разбирать логи, на анализ которых вручную могут уйти месяца? или руками напишите скрипты, полностью покрывающие платный функционал за 20 минут?
2. хорошие сервисы не бывают бесплатными
и фирма 1С в своей книге 1С:Эксперт тоже подпевает
но и это ЛОЖЬ!
наши сервисы типа дублируют цуповский функционал БЕСПЛАТНО, уже 6й год как
Андрей Бурмистров для наших курсов сделал такую обработку - она мало того что бесплатна, так еще ваш grep такой экспресс-анализ не сможет сделать
"Инструкция - это для тех, кто не умеет"
ну и по поводу инструкций: чтобы делать не по инструкции, надо сначала научиться делать по инструкции
Экономить 20 минут один раз и 20 минут 100 раз - несопоставимые цифры.
откуда такие цифры, что вы там сто раз делаете то?!! (в ужасе)
Для экспресс-анализа как раз grep лучше всего,
т.е. лучше потратить время на написание чем воспользоваться готовым?
Не умеет - пусть покупает сервисы
тут сразу два ложных посыла:
1. те кто покупают ничего не умеют -
и это ЛОЖЬ!
т.е. платные инструменты, которые автоматизируют разбор логов - это не экономия времени? т.е. лучше руками разбирать логи, на анализ которых вручную могут уйти месяца? или руками напишите скрипты, полностью покрывающие платный функционал за 20 минут?
2. хорошие сервисы не бывают бесплатными
и фирма 1С в своей книге 1С:Эксперт тоже подпевает
но и это ЛОЖЬ!
наши сервисы типа дублируют цуповский функционал БЕСПЛАТНО, уже 6й год как
Андрей Бурмистров для наших курсов сделал такую обработку - она мало того что бесплатна, так еще ваш grep такой экспресс-анализ не сможет сделать
"Инструкция - это для тех, кто не умеет"
ну и по поводу инструкций: чтобы делать не по инструкции, надо сначала научиться делать по инструкции
ибо какой эксперт может быть из человека, который в Linux ни в зуб ногой
возможно эксперт в 1С-технологиях или эксперт по Windows-технологиям...
(196)
1. Откуда цифры? И это САМ Гилев меня спрашивает? Что, не в курсе про итерационный подход к решению проблем производительности? Есть запросы, который вываливается в ТОП 10. Он модифицируется так, чтобы работать быстрее. После этого в ТОП 10 могут оказаться другие запросы, которые вообще не входили в эту группу (полагаю, Вы в курсе, почему так, да?). В итоге весь анализ нужно еще раз произвести. И так далее до достижения того самого APDEX на уровне 0.98-0.99. Это не однократная работа по разору логов. И этот ТОП 10 запросов можно и дополнительными средствами разобрать, а можно и селектом к сохраненной профайлером в базе таблице длительности запросов.
2. Готовое анализирует что-то комплексно, создавая какое-то дерево представлений всего произошедшего, из которого нужно выковыривать данные. grep может сразу без дополнительного анализа по регулярному выражению отобрать нужные строки (например, запросы с включенной какой нибудь константой "МЕТКА_0001/2/3..."), получив их количество и общее влияние, если это необходимо. Да, научиться пользоваться регулярками несколько сложнее, чем ЦУП'ом, но оно того стоит. Кто не умеет, тот - редиска!
3. Бесплатно - это тоже не плохо, только зачем, если есть тот же ЦУП (раз уж занялись производительностью, то как без него, да?) Лень, конечно, никто не отменял, поэтому я не предлагаю отказываться от анализаторов запросов, предлагающих автоматически какие-то оптимизации, но это не касается архитектуры решения, в которой может быть проблема. Архитектурные вопросы такие механизмы не решают.
4. А инструкция - это в Вашем случае что?
1. Откуда цифры? И это САМ Гилев меня спрашивает? Что, не в курсе про итерационный подход к решению проблем производительности? Есть запросы, который вываливается в ТОП 10. Он модифицируется так, чтобы работать быстрее. После этого в ТОП 10 могут оказаться другие запросы, которые вообще не входили в эту группу (полагаю, Вы в курсе, почему так, да?). В итоге весь анализ нужно еще раз произвести. И так далее до достижения того самого APDEX на уровне 0.98-0.99. Это не однократная работа по разору логов. И этот ТОП 10 запросов можно и дополнительными средствами разобрать, а можно и селектом к сохраненной профайлером в базе таблице длительности запросов.
2. Готовое анализирует что-то комплексно, создавая какое-то дерево представлений всего произошедшего, из которого нужно выковыривать данные. grep может сразу без дополнительного анализа по регулярному выражению отобрать нужные строки (например, запросы с включенной какой нибудь константой "МЕТКА_0001/2/3..."), получив их количество и общее влияние, если это необходимо. Да, научиться пользоваться регулярками несколько сложнее, чем ЦУП'ом, но оно того стоит. Кто не умеет, тот - редиска!
3. Бесплатно - это тоже не плохо, только зачем, если есть тот же ЦУП (раз уж занялись производительностью, то как без него, да?) Лень, конечно, никто не отменял, поэтому я не предлагаю отказываться от анализаторов запросов, предлагающих автоматически какие-то оптимизации, но это не касается архитектуры решения, в которой может быть проблема. Архитектурные вопросы такие механизмы не решают.
4. А инструкция - это в Вашем случае что?
(198) не думаю что уловили суть
(197) делаю вывод что нашим инструментом вы просто не пользовались
а) бесплатно
б) настраиваются наши инструменты проще
в) анализируют быстрее и что важнее не создают рисков не стабильной работы продуктива
собственно мы пользовались ЦУП, выяснили недостатки и избежали их в своих инструментах
нам например при анализе на двух десятках серверов не надо постоянно переключаться между этими серверами, бегая в локальные базы по разным впн и т.п.
понимаю что Вам хочется почувствовать "Нео" в темных очках: "я знаю кунфу" ... но технологии должны помогать бизнесу решать его задачи, а не превращаться в игрушки в безответственных руках
мне тут один программист предложил переписать код конфигурации 1С на java, чтобы "работало быстрее", тоже "из ваших" - видимо можно объяснить все, но не всем...
(197) делаю вывод что нашим инструментом вы просто не пользовались
Бесплатно - это тоже не плохо, только зачем, если есть тот же ЦУП
может потому что:
а) бесплатно
б) настраиваются наши инструменты проще
в) анализируют быстрее и что важнее не создают рисков не стабильной работы продуктива
собственно мы пользовались ЦУП, выяснили недостатки и избежали их в своих инструментах
нам например при анализе на двух десятках серверов не надо постоянно переключаться между этими серверами, бегая в локальные базы по разным впн и т.п.
grep может сразу без дополнительного анализа по регулярному выражению отобрать нужные строки
вы думаете что проводите ликбез сейчас что ли? я вам показал обработку которую запустил и увидел блокировки практически сразу, не требуется тратить время на написание выражений и фильтров, если конечно понимаете что такое рентабельность работ
понимаю что Вам хочется почувствовать "Нео" в темных очках: "я знаю кунфу" ... но технологии должны помогать бизнесу решать его задачи, а не превращаться в игрушки в безответственных руках
мне тут один программист предложил переписать код конфигурации 1С на java, чтобы "работало быстрее", тоже "из ваших" - видимо можно объяснить все, но не всем...
(199)
1. Инструментами, действительно, не пользовался - это ленивым нужно, я не из них.
По поводу экономии времени, то ответьте честно, сколько времени тратится на работы по оптимизации в среднем? Для разработки нагрузочного тестирования только 1 человек-месяц, если писать полный сценарий, а именно на этом настаивают "жирные" клиенты. Им не нужен полуфабрикат чего-то оценочно-прекрасного. Я, кстати, предварительно как раз люблю пользоваться именно тестом Гилева, а не какими-то стандартными нагрузочными тестами с миллионом окошек от 1С - тут Ваш продукт однозначно выигрывает, позволяя получить некоторую синтетическую цифру. Не так давно Филиппов что-то подобное реализовал (по крайней мере о запуске 25к фоновых заданий).
2. Блокировки - это важно, конечно, но они тоже поменяются после произведенных изменений (Вы же не будете говорить о том, что после всех измерений мы ничего не поменяли, да?) При анализе собирается много данных, часть из них более важны, часть - менее. Какие-то данные можно получить grep'ом (думаю, все), какие-то - в окошках потыкавшись. Все дело в том, к какому подходу привык. Тем более я юзаю в основном Linux'овые ОСи и мне там привычнее пользоваться и elasticsearch, и прочими механизмами, для которых есть хорошие инструменты анализа.
3. Куда уж нам до темных очков - у нас и так глаза красные)))
один программист предложил переписать код конфигурации 1С на java, чтобы "работало быстрее"
Кое-что можно и на Java переписать.
1. Инструментами, действительно, не пользовался - это ленивым нужно, я не из них.
По поводу экономии времени, то ответьте честно, сколько времени тратится на работы по оптимизации в среднем? Для разработки нагрузочного тестирования только 1 человек-месяц, если писать полный сценарий, а именно на этом настаивают "жирные" клиенты. Им не нужен полуфабрикат чего-то оценочно-прекрасного. Я, кстати, предварительно как раз люблю пользоваться именно тестом Гилева, а не какими-то стандартными нагрузочными тестами с миллионом окошек от 1С - тут Ваш продукт однозначно выигрывает, позволяя получить некоторую синтетическую цифру. Не так давно Филиппов что-то подобное реализовал (по крайней мере о запуске 25к фоновых заданий).
2. Блокировки - это важно, конечно, но они тоже поменяются после произведенных изменений (Вы же не будете говорить о том, что после всех измерений мы ничего не поменяли, да?) При анализе собирается много данных, часть из них более важны, часть - менее. Какие-то данные можно получить grep'ом (думаю, все), какие-то - в окошках потыкавшись. Все дело в том, к какому подходу привык. Тем более я юзаю в основном Linux'овые ОСи и мне там привычнее пользоваться и elasticsearch, и прочими механизмами, для которых есть хорошие инструменты анализа.
3. Куда уж нам до темных очков - у нас и так глаза красные)))
(200)
По поводу экономии времени, то ответьте честно, сколько времени тратится на работы по оптимизации в среднем?
4 дня
Для разработки нагрузочного тестирования только 1 человек-месяц, если писать полный сценарий, а именно на этом настаивают "жирные" клиенты.
колоссальное количество денег на ветер
мне там привычнее
вот мы и выяснили настоящую причину требований преподавателя
(201)
4 дня - это хорошо. Я как-то работал в конторе, куда Вас приглашали. Не в курсе, сколько дней там ушло, но я особой разницы не заметил - все и так работало нормально. Но я в то время не занимался производительностью - я занимался математикой.
Нагрузочное тестирование - да, колоссальное количество денег с целью риск-менеджмента. Крупные конторы мыслят не так, как Вы лично - у них приличные бюджеты на это выделены. И если система не будет работать с заявленной производительностью, то они ее просто не купят, потратив 10% бюджета внедрения на оценку.
вот мы и выяснили настоящую причину требований преподавателя
А что не так? Кому-то привычнее одни инструменты, кому-то - другие. Кто-то к Linux'у привык и мастдай его бесит, кто-то - наоборот не может разобраться с Linux, предпочитая тыкание мышкой в окнах настройки командной строке. Для меня точно командная строка куда быстрее, чем тыкание в сотнях окон.
4 дня - это хорошо. Я как-то работал в конторе, куда Вас приглашали. Не в курсе, сколько дней там ушло, но я особой разницы не заметил - все и так работало нормально. Но я в то время не занимался производительностью - я занимался математикой.
Нагрузочное тестирование - да, колоссальное количество денег с целью риск-менеджмента. Крупные конторы мыслят не так, как Вы лично - у них приличные бюджеты на это выделены. И если система не будет работать с заявленной производительностью, то они ее просто не купят, потратив 10% бюджета внедрения на оценку.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот