Сообщение Re[87]: MS забило на дотнет. Питону - да, сишарпу - нет? от 28.09.2021 2:47
Изменено 28.09.2021 2:50 vdimas
Re[87]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Serginio1, Вы писали:
V>>Нет в 1С локального кеширования, будет просить удаленный сервак на каждый чих.
V>>Отсюда видимые тормоза при открытии форм.
S>На самом деле есть. Во всяком случае на сервере приложений полученные данные кэшируются
Наверно разница в том, что сервер приложений (это для веба?) один для всех подключённых клиентов, т.е. про актуальность кеша можно делать хоть какие-то предположения.
Другое дело когда каждый клиент независимо коннектится к SQL-серваку как оно есть в традиционном использовании 1С в связке с MS SQL.
Тогда в отсутствии специального механизма поддержки актуальности кеша попытка кешировать данные вредна.
А такого механизма заведомо нет, я смотрел схемы таблиц, которые создаёт на серваке 1С — в таблицах нет служебного поля для целей поддержки когерентности клиентских кешей.
Сама схема обычно проста:
— в целевую таблицу/таблицы, описывающие некую сущность, вводится служебное поле — токен синхронизации, целое число некоей ширины;
— для данной сущности при каждом её изменении этот токен инкрементируется, при переполнении токена он сбрасывается у всех записей таблицы;
(например, текущий токен был равен 42, обновили в одной транзакции несколько строк в таблице, у обновлённых строк токен стал 43)
— клиенту возвращается некий ответ на прикладной запрос, в котором рядом с внешним ключом идёт токен синхронизации сущности, на которую ссылается внешний ключ.
— при обнаружении превышения значения токена синхронизации, клиент запрашивает требуемые сущности (или "точечно" для участвующих в запросе, или последние обновления для всего справочника через простое условие select * from SomeEnity where SyncToken > @ClientToken); клиент обновляет свой кеш справочника, вычленяя max(SyncToken) по ходу обновления, это и будет текущий его токен синхронизации.
Что в этой схеме хорошо — это отсутствие трафика зеркалирования данных.
Например, пришёл новый товар, заводятся куча новых карточек, но товар еще на склад не поступил.
И пока эти карточки заводятся и многократно редактируются — будет изменяться их токен синхронизации.
Но т.к. новые карточки еще нигде на операторских местах продавцов не фигурируют — ПО продавцов эти ненужные им данные и не запрашивает.
Назавтра продавцы включили свои терминалы, зачитали ненулевые регистры товаров на складе, зачитали соотв. справочники — и огонь торговать.
S>Считанные данные будут находиться в кеше до тех пор, пока не наступит одно из следующих событий:
S>считанные данные будут вытеснены из кеша другими считанными данными других объектов (переполнение кеша);
S>при очередном обращении к кешу окажется, что считанные данные были изменены в базе данных;
S>закончится интервал времени в 20 минут.
S>Все считанные данные помещаются в последовательную очередь, и, поскольку объем кеша ограничен, наиболее старые данные будут вытесняться из кеша последними считанными.
Насколько я понял из описания, у них один кеш на все сущности, а сам кеш не является точным-актуальным, т.к. реализован через набор допущений.
Объективно если — это неуд.
(если к базе можно подключаться мимо сервера приложений)
S>Если обращение к данным происходит в рамках транзакции, то оно переадресуется транзакционному кешу. В рамках транзакции в «1С:Предприятии» выполняются все операции, приводящие к изменению данных в базе данных. Например, в рамках транзакции выполняется обработка проведения документа.
Ну...
У меня код проводки документа жил на стороне БД, ес-но.
Поэтому и работал раз в 100 быстрее.
(если не больше)
На клиенте таблица непроведенных документов, можно просто мышкой нажать на строку и провести вниз-вверх (с прокруткой) не отпуская, выделяя сколько требуется, потом нажать "Провести" и куча складских документов мгновенно проводилась. Это недостижимые для 1С космические технологии. ))
V>>Нет в 1С локального кеширования, будет просить удаленный сервак на каждый чих.
V>>Отсюда видимые тормоза при открытии форм.
S>На самом деле есть. Во всяком случае на сервере приложений полученные данные кэшируются
Наверно разница в том, что сервер приложений (это для веба?) один для всех подключённых клиентов, т.е. про актуальность кеша можно делать хоть какие-то предположения.
Другое дело когда каждый клиент независимо коннектится к SQL-серваку как оно есть в традиционном использовании 1С в связке с MS SQL.
Тогда в отсутствии специального механизма поддержки актуальности кеша попытка кешировать данные вредна.
А такого механизма заведомо нет, я смотрел схемы таблиц, которые создаёт на серваке 1С — в таблицах нет служебного поля для целей поддержки когерентности клиентских кешей.
Сама схема обычно проста:
— в целевую таблицу/таблицы, описывающие некую сущность, вводится служебное поле — токен синхронизации, целое число некоей ширины;
— для данной сущности при каждом её изменении этот токен инкрементируется, при переполнении токена он сбрасывается у всех записей таблицы;
(например, текущий токен был равен 42, обновили в одной транзакции несколько строк в таблице, у обновлённых строк токен стал 43)
— клиенту возвращается некий ответ на прикладной запрос, в котором рядом с внешним ключом идёт токен синхронизации сущности, на которую ссылается внешний ключ.
— при обнаружении превышения значения токена синхронизации, клиент запрашивает требуемые сущности (или "точечно" для участвующих в запросе, или последние обновления для всего справочника через простое условие select * from SomeEnity where SyncToken > @ClientToken); клиент обновляет свой кеш справочника, вычленяя max(SyncToken) по ходу обновления, это и будет текущий его токен синхронизации.
Что в этой схеме хорошо — это отсутствие трафика зеркалирования данных.
Например, пришёл новый товар, заводятся куча новых карточек, но товар еще на склад не поступил.
И пока эти карточки заводятся и многократно редактируются — будет изменяться их токен синхронизации.
Но т.к. новые карточки еще нигде на операторских местах продавцов не фигурируют — ПО продавцов эти ненужные им данные и не запрашивает.
Назавтра продавцы включили свои терминалы, зачитали ненулевые регистры товаров на складе, зачитали соотв. справочники — и огонь торговать.
S>Считанные данные будут находиться в кеше до тех пор, пока не наступит одно из следующих событий:
S>считанные данные будут вытеснены из кеша другими считанными данными других объектов (переполнение кеша);
S>при очередном обращении к кешу окажется, что считанные данные были изменены в базе данных;
S>закончится интервал времени в 20 минут.
S>Все считанные данные помещаются в последовательную очередь, и, поскольку объем кеша ограничен, наиболее старые данные будут вытесняться из кеша последними считанными.
Насколько я понял из описания, у них один кеш на все сущности, а сам кеш не является точным-актуальным, т.к. реализован через набор допущений.
Объективно если — это неуд.
(если к базе можно подключаться мимо сервера приложений)
S>Если обращение к данным происходит в рамках транзакции, то оно переадресуется транзакционному кешу. В рамках транзакции в «1С:Предприятии» выполняются все операции, приводящие к изменению данных в базе данных. Например, в рамках транзакции выполняется обработка проведения документа.
Ну...
У меня код проводки документа жил на стороне БД, ес-но.
Поэтому и работал раз в 100 быстрее.
(если не больше)
На клиенте таблица непроведенных документов, можно просто мышкой нажать на строку и провести вниз-вверх (с прокруткой) не отпуская, выделяя сколько требуется, потом нажать "Провести" и куча складских документов мгновенно проводилась. Это недостижимые для 1С космические технологии. ))
Re[87]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Serginio1, Вы писали:
V>>Нет в 1С локального кеширования, будет просить удаленный сервак на каждый чих.
V>>Отсюда видимые тормоза при открытии форм.
S>На самом деле есть. Во всяком случае на сервере приложений полученные данные кэшируются
Наверно разница в том, что сервер приложений (это для веба?) один для всех подключённых клиентов, т.е. про актуальность кеша можно делать хоть какие-то предположения.
Другое дело когда каждый клиент независимо коннектится к SQL-серваку как оно есть в традиционном использовании 1С в связке с MS SQL.
Тогда в отсутствии специального механизма поддержки актуальности кеша попытка кешировать данные вредна.
А такого механизма заведомо нет, я смотрел схемы таблиц, которые создаёт на серваке 1С — в таблицах нет служебного поля для целей поддержки когерентности клиентских кешей.
Сама схема обычно проста:
— в целевую таблицу/таблицы, описывающие некую сущность, вводится служебное поле — токен синхронизации, целое число некоей ширины;
— для данной сущности при каждом её изменении этот токен инкрементируется, при переполнении токена он сбрасывается у всех записей таблицы;
(например, текущий токен был равен 42, обновили в одной транзакции несколько строк в таблице, у обновлённых строк токен стал 43)
— клиенту возвращается некий ответ на прикладной запрос, в котором рядом с внешним ключом идёт токен синхронизации сущности, на которую ссылается внешний ключ.
— при обнаружении превышения значения токена синхронизации, клиент запрашивает требуемые сущности (или "точечно" для участвующих в запросе, или последние обновления для всего справочника через простое условие select * from SomeEnity where SyncToken > @ClientToken); клиент обновляет свой кеш справочника, вычленяя max(SyncToken) по ходу обновления, это и будет текущий его токен синхронизации.
Что в этой схеме хорошо — это отсутствие трафика зеркалирования данных.
Например, пришёл новый товар, заводятся куча новых карточек, но товар еще на склад не поступил.
И пока эти карточки заводятся и многократно редактируются — будет изменяться их токен синхронизации.
Но т.к. новые карточки еще нигде на операторских местах продавцов не фигурируют — ПО продавцов эти ненужные им обновляемые справочные данные и не запрашивает.
Назавтра продавцы включили свои терминалы, зачитали ненулевые регистры товаров на складе, зачитали соотв. справочники — и огонь торговать.
S>Считанные данные будут находиться в кеше до тех пор, пока не наступит одно из следующих событий:
S>считанные данные будут вытеснены из кеша другими считанными данными других объектов (переполнение кеша);
S>при очередном обращении к кешу окажется, что считанные данные были изменены в базе данных;
S>закончится интервал времени в 20 минут.
S>Все считанные данные помещаются в последовательную очередь, и, поскольку объем кеша ограничен, наиболее старые данные будут вытесняться из кеша последними считанными.
Насколько я понял из описания, у них один кеш на все сущности, а сам кеш не является точным-актуальным, т.к. реализован через набор допущений.
Объективно если — это неуд.
(если к базе можно подключаться мимо сервера приложений)
S>Если обращение к данным происходит в рамках транзакции, то оно переадресуется транзакционному кешу. В рамках транзакции в «1С:Предприятии» выполняются все операции, приводящие к изменению данных в базе данных. Например, в рамках транзакции выполняется обработка проведения документа.
Ну...
У меня код проводки документа жил на стороне БД, ес-но.
Поэтому и работал раз в 100 быстрее.
(если не больше)
На клиенте таблица непроведенных документов, можно просто мышкой нажать на строку и провести вниз-вверх (с прокруткой) не отпуская, выделяя сколько требуется, потом нажать "Провести" и куча складских документов мгновенно проводилась. Это недостижимые для 1С космические технологии. ))
V>>Нет в 1С локального кеширования, будет просить удаленный сервак на каждый чих.
V>>Отсюда видимые тормоза при открытии форм.
S>На самом деле есть. Во всяком случае на сервере приложений полученные данные кэшируются
Наверно разница в том, что сервер приложений (это для веба?) один для всех подключённых клиентов, т.е. про актуальность кеша можно делать хоть какие-то предположения.
Другое дело когда каждый клиент независимо коннектится к SQL-серваку как оно есть в традиционном использовании 1С в связке с MS SQL.
Тогда в отсутствии специального механизма поддержки актуальности кеша попытка кешировать данные вредна.
А такого механизма заведомо нет, я смотрел схемы таблиц, которые создаёт на серваке 1С — в таблицах нет служебного поля для целей поддержки когерентности клиентских кешей.
Сама схема обычно проста:
— в целевую таблицу/таблицы, описывающие некую сущность, вводится служебное поле — токен синхронизации, целое число некоей ширины;
— для данной сущности при каждом её изменении этот токен инкрементируется, при переполнении токена он сбрасывается у всех записей таблицы;
(например, текущий токен был равен 42, обновили в одной транзакции несколько строк в таблице, у обновлённых строк токен стал 43)
— клиенту возвращается некий ответ на прикладной запрос, в котором рядом с внешним ключом идёт токен синхронизации сущности, на которую ссылается внешний ключ.
— при обнаружении превышения значения токена синхронизации, клиент запрашивает требуемые сущности (или "точечно" для участвующих в запросе, или последние обновления для всего справочника через простое условие select * from SomeEnity where SyncToken > @ClientToken); клиент обновляет свой кеш справочника, вычленяя max(SyncToken) по ходу обновления, это и будет текущий его токен синхронизации.
Что в этой схеме хорошо — это отсутствие трафика зеркалирования данных.
Например, пришёл новый товар, заводятся куча новых карточек, но товар еще на склад не поступил.
И пока эти карточки заводятся и многократно редактируются — будет изменяться их токен синхронизации.
Но т.к. новые карточки еще нигде на операторских местах продавцов не фигурируют — ПО продавцов эти ненужные им обновляемые справочные данные и не запрашивает.
Назавтра продавцы включили свои терминалы, зачитали ненулевые регистры товаров на складе, зачитали соотв. справочники — и огонь торговать.
S>Считанные данные будут находиться в кеше до тех пор, пока не наступит одно из следующих событий:
S>считанные данные будут вытеснены из кеша другими считанными данными других объектов (переполнение кеша);
S>при очередном обращении к кешу окажется, что считанные данные были изменены в базе данных;
S>закончится интервал времени в 20 минут.
S>Все считанные данные помещаются в последовательную очередь, и, поскольку объем кеша ограничен, наиболее старые данные будут вытесняться из кеша последними считанными.
Насколько я понял из описания, у них один кеш на все сущности, а сам кеш не является точным-актуальным, т.к. реализован через набор допущений.
Объективно если — это неуд.
(если к базе можно подключаться мимо сервера приложений)
S>Если обращение к данным происходит в рамках транзакции, то оно переадресуется транзакционному кешу. В рамках транзакции в «1С:Предприятии» выполняются все операции, приводящие к изменению данных в базе данных. Например, в рамках транзакции выполняется обработка проведения документа.
Ну...
У меня код проводки документа жил на стороне БД, ес-но.
Поэтому и работал раз в 100 быстрее.
(если не больше)
На клиенте таблица непроведенных документов, можно просто мышкой нажать на строку и провести вниз-вверх (с прокруткой) не отпуская, выделяя сколько требуется, потом нажать "Провести" и куча складских документов мгновенно проводилась. Это недостижимые для 1С космические технологии. ))