8.х Вызов сервером обработчика события на клиенте

Тема в разделе "Конфигурирование на платформе "1С:Предприятие 8"", создана пользователем sobenko, 1 мар 2012.

  1. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Как Вы думаете, просто так 1С НЕ рекомендует создавать более одного рабочего процесса на сервере?
    Именно для того, что бы снизить издержки серверных задач. А Вы предлагает их увеличить (не забываем, что нужно будет синхронизировать все "подписки" между серверами)

    Для выписки - однозначно менять БП заказчика. Да Вы и сами, когда начнете копать - придете к этому.
    Своевременное оповещение - имеет очень размытое понятие. Почитайте договор типа SLA, например, вот там такое понятие регламентировано и пока Вы не поймете, что надо делать также - будете все время изобретать велосипед и ходить по граблям.

    Еще раз: что делать, если клент не в сети? Получаем, что при подключении клиент должен получить все события, которые произошли до момента подключения.
    Далее - временно утеряна связь (8.2 в режиме УП поддерживает такое) - что должно произойти при восстановлении связи?
    А если она не будет восстановлена?

    Нет. И это обусловнено особенностями ОС Windows, например.

    Да, буду. Есть из этого исключениея и они неоднократно были обмусолены на партнерском форуме.

    Не путайте работу по запросу и онлайн-информацию.

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

    И мы приходим к тому, что сервер будет также проверять, а надо ли что сделать? В чем отличие? :)))))
    Причем, сервер проверит, что ситуация изменилась -> отправил клиенту -> клиент отправил запрос на сервер, что надо получить свежие данные списка.
    Таким образом, мы получаем еще большую нагрузку.


    Сервер будет ТОЧНО ТАКЖЕ проверять (по описанному) - а надо ли ему что делать?
    Поэтому отличий ровно НОЛЬ. И даже хуже станет - придется синхронизировать весь этот зоопарк по всем кластерам.

    А зачем Вам список? Что Вы с его помощью делаете? ВЫ на бирже работаете? Так там вообще другие идеологию используются (там борьба за миллиметры провода идут!)
    Еще раз: читайте договор типа SLA - его не дураки придумали.

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

    Дальнейшую дисскусию без реального примера необходимости такого процесса буду считать оффтопиком.
    Обсуждать сферического коня в вакууме - это круто, но не имеет никакого пратического смысла. За время, которое тут обсуждали - я бы уже раз 20 написал нужные механизмы и донес до заказчика понимание понятий "своевременнно" и "организационно".
  2. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Мне надоело тратить свое время на доказательства почему 2*2=4. Вы прекрасно поняли идею технологии асинхронного обмена, которую я предлагаю. Область её применения также Вам понятна. Если нет- то Вам не на этом форуме надо оттачивать свое искусство бездоказательного опровержения идей. Лучше идти в политику! Там они с купленным средним и высшим образованием, с пеной у рта сначала доказывают что не надо переводить часы на летнее время, а через год- все наоборот!
    Вы несете уже какую-то чушь, по поводу критических ситуаций, игнорируя при этом мои вопросы о том как сейчас система отрабатывает аналогичные критические ситуации ("Что будет если клиент зашлет запрос на сервер и "отвалится"? Куда сервер вернет результат?"). Попробуйте ответить на вопрос а что будут делать клиенты и сервер, если на них упадет ядерная бомба или рухнет бетонный потолок? Надо ведь и такую ситуацию предвидеть! Ведь на Вас потолок 3 раза в день падает! Нет?!
    Причем к данной теме количество рабочих процессов на одном сервере?! Какие издержки?! Что синхронизировать? Читайте мои посты внимательно, там все написано и "вдалбливать" одно и то-же я не собираюсь. Если у кого-то "кривые" ручки и провалы в памяти, то тут ни одна супер-пупер платформа не поможет! Да, можно несколько серверов к одной базе, да можно несколько конфигураторов, но зачем?! Это админов, внедренцев и т.п. лечить надо, а не пытаться "запихнуть" контроль всех возможных самых идиотских ошибок псевдо-профессионалов в платформу 1С. Для того документация, курсы всякие, экзамены существуют, чтобы народ не творил чего-попало. Чего-то Вы у клиента предлагаете изменить критичные для него бизнес-процессы, а вот "криворукость" внедренцев и админов лечить не надо по Вашему?!
    Меня Вы абсолютно не убедили своими "не к селу, не к городу" аргументами. Я так и не увидел предоставленного расчета о количестве бесполезно потраченного кластером времени для обеспечения холостых циклов по запросам и их обработке для обеспечения обновления хотя-бы 1 списка на форме (или проверки появления новых задач) для 200 активных пользователей, с периодичностью 1 минута. Сделаю это за Вас! К примеру возьмем длительность анализируемого периода- 8 часов и за это время в системе к примеру появилось 1600 новых задач (по 1 задаче в час для каждого пользователя, в том числе и ненавистные Вами проведенные платежные поручения). Это что не аргумент, что за 8 часов сервер "прокрутит" 96 000 циклов, из которых только 1600 будут эффективными. Эффективность работы системы в таком режиме составит аж: 1600/96000*100=1,67%. А при уменьшении числа задач эффективность будет стремиться к НУЛЮ, в то время как эффективность работы системы с обработкой событий будет всегда практически 100%. Бесполезные циклы (запрос-обработка запроса) могут возникать только при старте системы на клиенте. В процессе работы бесполезных циклов вообще не будет существовать по определению! Да, всплески нагрузки на сервер будут наблюдаться после записи новой задачи (при проведении платежки, операций по согласованию документа и т.п.). Но этих всплесков в тысячи или даже миллионы раз будет меньше, нежели при периодическом опросе сервера кучей клиентов. И эти всплески будут абсолютно в 10-ку, а не в "молоко", как при синхронной технологии обмена.
  3. alexburn
    Offline

    alexburn Модераторы Команда форума Модератор

    Регистрация:
    5 янв 2009
    Сообщения:
    14.782
    Симпатии:
    509
    Баллы:
    204
    Зря вы так.
  4. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Зря что привожу конкретные цифры?! Или зря, что не вижу смысла обсуждать что должно происходить в случае если систему в крупном концерне установит 3-х летний ребенок системного администратора и начнет испытывать ее на прочность?
  5. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    С GoogleDocs знакомы? Там любимые Вами ВебСокеты используются. Запустите в один документ сотню пользователей и попросите писать что-то одновременно.
    Результат увидите сами.

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

    Не рассказывайте сказки. Именно после внедренцев, которые не показывают проблемы в процессах заказчика потом мне и платят большие деньги за исправления и наставление на путь истинный :)
    Проще говоря: клиент НЕ всегда прав. Чаще даже НЕ прав. И когда показываешь ему всю картину зависимостей и проблем, люди понимают и начинают думать, а не тупо кричать "все г..о", чем Вы сейчас занимаетесь.

    А зачем мне такой расчет? У меня задача решается другими способами и решается успешно, позволю заметить. Проблема-то у Вас и, вместо того, что бы ее решить, Вы пытатесь тут криком что-то достичь. Смешно.

    1. Приведите расчет для Вашей схемы
    2. КПД считается по другому, ибо, например, Вы не учитываете, что система выполняет запрос по "пустым" данным намного быстрее. Также, 96000 запросов за 8 часов - это смешно. Это простейшие запросы. У меня за час более сложные вопросы выполняются в большем количестве.


    Еще раз: если Вы хотите, что бы какая-то функционалось была реализована - требуется ее обоснование с точки зрения использования и выгодности. На текущий момент не было сказано ни про одно, ни про другое. Только какие-то теоритические высказывания.
  6. shurikvz
    Offline

    shurikvz Модераторы Команда форума Модератор

    Регистрация:
    1 окт 2009
    Сообщения:
    8.410
    Симпатии:
    316
    Баллы:
    104
    Конкретных цифр не было. Посчитанное вами количество вызовов сервера не является конкретными цифрами. Без реальных замеров по времени / нагрузке на сервер, это точно также пустые рассуждения.

    Upd:
    Уже написали.
  7. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Есть понятие теоретических расчетов, а есть практические замеры и одно с другим абсолютно всегда расходится на величину погрешности. Ни одному человеку или группе людей никогда не удавалось и не удастся априорно учесть все возможные факторы воплощения теории в реальном продукте. Пока речь идет о теоретических выкладках, а не практических замерах. Те цифры, что я привел для указанных мною условий в точности совпадут с теоретическими, т.к. я привожу расчеты числа холостых циклов, а не бесполезно потраченного времени сервера на обработку этих циклов.
  8. shurikvz
    Offline

    shurikvz Модераторы Команда форума Модератор

    Регистрация:
    1 окт 2009
    Сообщения:
    8.410
    Симпатии:
    316
    Баллы:
    104
    Понятно, что все учесть никому не удастся. Ок. Постараюсь донести мысль по другому: вы сейчас подошли к вопросу оптимизации клиент-серверного взаимодействия для определенного конкретного случая. Почему вы решили что это именно то место, которое следует оптимизировать? Теоретические выкладки здесь ничто. Нужен практический опыт. ТЕОРЕТИЧЕСКИ вы говорите, что стандартный вариант взаимодействия клиент-сервер, заложенный в 1С будет тормозить систему. А если вы произведете ПРАКТИЧЕСКИЕ замеры, и выяснится, что суммарная нагрузка на систему, вызванная реализацией оповещений на базе стандартного механизма не превышает 0,1% всей нагрузки на систему. Стоит ли тогда игра свеч? Смысл тогда оптимизировать? Возможно тогда следует обратить внимание на другие узкие места, не кажется ли вам так? Именно поэтому ПРАКТИЧЕСКИЕ результаты так важны. Даже если мы говорим о ТЕОРЕТИЧЕСКИХ результатах, где расчет, сколько занимают 96000 циклов, от всей нагрузки на систему?
  9. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Ну Вы сколько можно заниматься подменой сферы применения продукта на совершенно иную, для которой продукт изначально не рассчитан! Попробуйте на велосипед нагрузить столько-же, сколько тянет БелАЗ. Это только гомодурумы (а не гомосапиенсы) до такого додуматься могут.
    Я еще раз повторяю, что не предлагаю полностью заменить синхронный принцип обмена на асинхронный, а добавить механизм асинхронного обмена в дополнение к существующему синхронному! И Вы это уже должны были понять еще из первых постов.
    Очередное "про Фому, а не про Ерему"? Что, процессы в кластере проводят синхронизацию данных находящихся на SQL-сервере?!
    А Вы себя кем именуете, "Главным по тарелочкам"?! Вы что, не внедренец?! Тогда о чем мы с Вами вообще спорим?
    А результаты работы студентов-внедренцев я сам каждый день наблюдаю и исправляю. Разговор не о них, а о том что когда я действительно понимаю, что от определенного БП напрямую зависит конечный результат деятельности организации, то ломать такие БП только студенты, а не профессионалы будут.
    Я привел пример и указал условие, что это необходимо реализовать и точка. Я сомневаюсь что Вы спорили-бы на экзамене о целесообразности задачи, вместо ее решения (если Вы конечно сдавали экзамены).
    Ну конечно, о том, что будет "если начнется война" рассуждать можно, а конкретными цифрами оперировать- это уже не Ваше. Я не вел разговор о том, что задача не решается. Я писал с самого начала об оптимизации решения задачи, за счет исключения выполнения сервером бесполезной работы! Снова Вы уходите от ответа на конкретный вопрос. Так не спорят профессионалы, к коим Вы себя пречисляете.
    1. Схема описана, расчеты предоставлены. Учитесь читать.
    2. Я не о КПД, вероятности взрыва сверхновой или еще о чем либо. Я писал об ЭФФЕКТИВНОСТИ! Замечаете разницу в буквах слов ЭФФЕКТИВНОСТЬ и КПД?! Понятия где-то рядом "бегают", но эти слова не синонимы!!!
    Если для Вас конкретные задачи- не задачи, а конкретные цифры- не цифры, то Вы конкретно не профессионал, а так, пофлудить зашли.
  10. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Никак не совпадут. В зависимости от нагрузки на систему может буть выбран разный план запроса, в зависимости от структуры данных - разное время выполнения.
    Поэтому просто тупое количество запросов совершенно ни о чем не говорит.
    Посмотрите профайлером, сколько запросов выполняется в системе даже при работе "вхолостую".
    Поэтому реальный данные будут зависеть исключительно от того, как программа будет написана и как будет спроектирована база данных.
    Посмотрите, например, на расчет с/с в УТ11 или УПП, который в фоновом режиме выполняется. Там запросей будет ого-го какой и ничего - работает система.
  11. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    Причем тут SQL? Мы о чем вообще говорим? Кластер 1С может передать управление и данные "упавшего" процесса на другой кластер, например.

    1. Пример приведен синтетический.
    2. Задача на экзаменах синтетические.
    3. И то и другое решается текущими средствами.
    В чем проблема?

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

    Вы считаете количество запросов? Вы ДЕЙСТВИТЕЛЬНО думаете, что так рассчитывается КПД/эффективность системы? Интересно тогда Ваше мнение насчет двухуровнего кеша в процессорах и индекса в базе данных. То же ведь "лишние" запросы. :)

    Вот и опишите КОНКРЕТНУЮ зависимость деятельности организации НА КОНКРЕТНОЙ задаче.
    Вы описали две задачи: остатки, выписка. Обе задачи решены слету. В чем проблема? Прочитайте решение и, если оно непонятно, давайте его обсудим.
    Есть другая задача? Давайте обсудим ее.
    Все остатльно с этого момента будет удаляться, как не имеющее никакого отношения к теме.

    Это конкретный пример, какая высокая нагрузка возникает на сервера для таких задач.
    Это кокретный пример того, что даже Google с трудом вытягивает такое небольшое количество пользователей онлайн в таких задачах.
    А Вы все понять этого не хотите.
  12. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Я не спорю о том, что голая теория без практического подтверждения никому не нужна. Но и практические эксперименты без теории могут длиться годами и не дать ожидаемых результатов (к примеру опыты средневековых алхимиков по превращению свинца в золото. Знали-бы химию- такой ерундой не занимались-бы, т.к. при помощи химических реакций изменить состав ядер атомов невозможно). По этому в любой науке сначала появляется теория, а затем она проверяется на практике. Наоборот бывает раз в 100 лет по чистой случайности или невероятной талантливости экспериментатора.
    Если Вы до сих пор не поняли, то поясняю: я уже давно пишу не об оптимизации одного конкретного внедрения на платформе 1С, а о новом механизме взаимодействия между клиентами и сервером, который на мой взгляд позволил-бы существенно поднимать производительность определенных решений. Да, если использовать любой механизм где попало и как попало, то результаты будут соответствующие. К примеру бывают случаи что получение данных через объектную модель на порядки быстрее, чем через запрос, хотя 1С рекомендует получать данные именно через запрос. Но любое правило действует только при определенных условиях. Исключения из правила это дискретный набор условий, при которых правило не действительно.
    Предлагаемый механизм должен применяться не везде и всегда, а только в тех случаях, когда согласно реализуемому бизнес-процессу на клиенте необходимо обеспечить актуальность обновления информации действительно в реальном масштабе времени, при большом числе одновременно работающих пользователей. Именно для такого случая синхронная модель обмена будет иметь следующие недостатки: во-первых будет наблюдаться запаздывание на длительность интервала ожидания (актуальность ниже чем при асинхронной модели обмена), во-вторых если для повышения актуальности будет уменьшатся интервал ожидания, то будет падать производительность системы при большом числе одновременно работающих пользователей.
    Я ничего нового не изобретаю. Если вспомнить историю развития программирования, то можно увидеть, что появление идеологии объектного программирования и обработки событий обеспечило громадный скачек. Попробуйте написать сейчас программу, не используя обработку событий, "в сплошную" как писали лет 20-30 назад (я к слову сам так тогда писал, а Вы?). Удобно? Эффективно? А я предлагаю абсолютно тако-же механизм обработки событий, только с расширением круга их обработки с отдельно взятого клиента до пределов одного сетевого приложения.
  13. BabySG
    Offline

    BabySG Администраторы Команда форума Администратор

    Регистрация:
    10 июн 2007
    Сообщения:
    11.853
    Симпатии:
    12
    Баллы:
    29
    В первом предложении вы говорите, что голая теория никому не нужна и тут же пишите именно эту голую теорию.
    В таком виде ни один вменяемый разработчик не возьется реализовывать.
    Пример:
    - нужна машина на 6 колесах!
    - Зачем?
    - Как зачем? Ведь это лучше, чем 4!
    - Чем лучше, где будет использоваться?
    - Вы не понимаете? Это же лучше! Я смогу столько всякого делать!
    - Что делать? Конкректное использование?

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

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

    Вот в чем разница. Вы пока упорно настаиваете на первом варианте - что бы взяли и сделали не очень понимая, зачем.

    Собственно, сейчас тендеция идет к "сплошному", т.е. не объектному, а фукнциональному способу. История повторяетс по спирали, как обычно все :)
  14. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    SQL тут при том, что там тоже данные! Вопрос в том какие данные хранит процесс, а какие SQL. Вы забываете о том, что сам-же писали в предыдущих постах (http://www.1c-pro.ru/topic40148.html/page__view__findpost__p__201899 по поводу хранения списка подписок в служебной таблице базы). При падении процесс не выполняет передачу данных базы SQL другому процессу!
    В курсе, что одну и ту-же задачу можно решить несколькими способами и получит одно и то-же правильное решение. Просто одним способом задача решается долго и сложно, а другим быстро и эффективно.
    Аргументы я уже в цифрах привел, а Вам уже и цифры не аргументы. Это глупо отрицать очевидное.
    Я не думаю, что эффективность работы системы зависит ТОЛЬКО от количества запросов. Но я абсолютно уверен что определенное количество (даже пустых или безрезультатных) запросов по времени будут равны одному результативному запросу. И определенное число мелких запросов от разных клиентов могут "положить" любой, самый мощный сервер или кластер серверов. Эти виды атак практически проверены и применяются в Инете!
    Вот чего вам так припекла конкретная задача? В платформе 8.1 появился новые классы объектов "Бизнес-процессы" и "Задачи". Что, до этого на регистрах сведений нельзя было реализовать аналогичный механизм?! Можно, но "заточенный" под определенное назначение функционал всегда лучше, чем универсальные механизмы. Что, на MS-SQL+Delphi нельзя написать аналогичное УТ? Можно, но на платформе 1С быстрее и удобнее.
    Я тему поднял сначала с вопросом "Можно-ли реализовать штатными средствами?", а когда получил ответ "Нет", то с того момента пишу что механизм асинхронного обмена, реализованный на платформе было-бы удобно использовать при решении определенных задач.
    А удалять-то можно, если аргументировать нечем. Мои аргументы в цифрах, а Ваши в фразах зачастую совсем о другом.
    Повторяю еще раз, что каждая система разрабатывается для решения определенных задач в определенных условиях. Где Вы нашли что Google Documents должна обеспечивать одновременную работу 100 пользователей с одним документом?! Я нашел что с одной книгой Excel могут работать до 10 пользователей. Где написано, что система обеспечивает работу сотен пользователей с одним документов?! Вы еще напишите что 1С 7.7 в файловом варианте почему-то не работает, если с базой пытаются активно работать одновременно 100 пользователей. Да не рассчитана просто система на это! И это не проблема "слабоватого" протокола TCP/IP, ОС Windows или платформы 1С 7.7. Просто все необходимо использовать по назначению. Попробуйте сварить яйца в микроволновке или постирать собачку в стиральной машине. Вас удивит результат?
    Так что в приведенном Вами примере это не "слабость" протокола WebSocket, а применение его не по назначению!
  15. uza
    Offline

    uza 1С, VBA (EXCEL), VB (.NET + WEB)

    Регистрация:
    10 июл 2007
    Сообщения:
    1.845
    Симпатии:
    1
    Баллы:
    29
    Если вспомнить историю развития прогрммирования, то были и такие штуки как LISP, PROLOG. А давайте в 1С закатаем еще и поддержку нотации LISP'а. Оно никому конечно не нужно, но зато как круто то.
    А еще бы запилить реализацию логического программирования, типа PROLOG'а. Тоже ж круто!

    Да, настолько серьезным прорывом стало развитие ООП, что сегодня ~30% программеров НИХРЕНА его не понимают. Вот и Вы.
    Вы говорите "как писали 20-30 лет назад". Хм. Object Pascal - 1986 год (26 лет ужо), Clascal - что то там 1981 год (уже 31 год), начало перепиливания С под С++ в 1980г (1983 - С с поддержкой классов поименован в С++).
    Smalltalk 71 / 72 / 76 / 80 - ни о чем не говорит?
    Ну и собственно SIMULA 67 (год создания угадайте сами, хотя бы приблизительно).

    Написать программу без обработки событий? Хм. Смотря что вы имеете в виду под обработкой событий. BAT фалы - сойдут?
    Страховые калькуляторы, где обработка событий I/O - не принципиальны (просто обеспечение привычного интерфейса ввода/вывода) - сойдут?
    Хм, ПАК обсчета вероятных сценариев лесных пожаров - канает?

    К чему я это все? Да к тому, что существует огромное множество технологий. Но применять их нужно там, где нужно.
    А кипеть пеной ради внедрения сложных сценариев в простую бухгалтерию (бухгалтерия > РСБУ/МСФО, бухгалтерия = учет .(точка) )

    Ваша задача решается проще, стандартнее, понятнее, надежнее.
    Но Вам же, походу, важен сам спор, а не предмет спора.
  16. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    В курсе, что синтаксически мысль не ограничивается 1 предложением. Удосужитесь прочесть весь абзац.
    А вот в абзаце я пишу о том, что сначала теория, а потом практика. Наоборот- это в 99% случаев долго и зачастую безрезультатно.
    Область применения механизма асинхронного обмена я описал, описал его преимущество (хотя это и так очевидно, если попытаться не отвергать постоянно отыскивая отговорки, а понять).
    Понять в чем разница между принципом периодического получения данных и обработкой событий изменения определенных данных в состоянии и ребенок. Вот только Вы продолжаете приводить какие-то несуразные примеры с разработкой давно существующих автомобилей. Вопрос в том, для чего эту машину использовать. Если ездить за покупками в ближайший супермаркет, то достаточно 4-х колес, а если перевозить сразу пару десятков автомобилей, то и 6-ти колем может оказаться мало.
    А настаиваю я на том, что механизм асинхронного обмена нужен тогда, когда необходимо на клиенте обеспечить максимальную актуальность данных, без потерь на обработку пустых циклов запросов к серверу. Что тут не понятно?
    Т.е. платформа 1С, даже в режиме управляемого приложения уже никому не нужная "рухлядь"? А можно узнать как называется новейший язык или среда разработки, где отсутствует программирование по принципу событийной обработки?
  17. shurikvz
    Offline

    shurikvz Модераторы Команда форума Модератор

    Регистрация:
    1 окт 2009
    Сообщения:
    8.410
    Симпатии:
    316
    Баллы:
    104
    [off]
    Я заметил в вашей манере вести диалог, одну нехорошую на мой взгляд особенность - в процессе обсуждения предмета разговора вы переходите на личности. Да 20-30 лет назад я не писал, и если вы посмотрите на мой возраст, то поймете, что в принципе вряд-ли был способен на это лет 30 назад. К чему тогда был вопрос? Демонстрация превосходства над собеседником? Ммм... Меня как-то не задело...
    [/off]

    По остальному - похоже диалог заходит в тупик. Вы предлагаете новый функционал, но необходимость его применения указана вами только в теории. Причем с такой особенностью, что в теории, не подкрепленной опять таки даже теоретическими расчетами (повторюсь - количество вызовов - это не расчет). Вы пытаетесь доказать, что кругом одни школьники, которые близко ничего не понимают (включая разработчиков платформы), но при этом не приводя в свою очередь никаких доказательств обоснованности вашей теории (кроме "ТЕОРЕТИЧЕСКИ так было бы лучше, Я в этом уверен").
    У вас есть теория. Ни у кого (включая вас же) нет КОНКРЕТНЫХ данных об эффективности вашей теории или о неэффективности существующей. Так о чем разговор идет? Продолжаем переливать из пустого в порожнее.
  18. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    На сегодня не только 30% программеров, а и 99% политиков нихрена не понимают чего творят. И в других сферах тот-же недостаток реальных специалистов, а не с "красными корочками" купленными за пару кабанчиков, которых родители в селе выкармливали.
    Да, в Кембриджском университете может и преподавали выше перечисленные языки, причем с практическими занятиями на компьютерах. А вот в СССР в школах программирование начали преподавать только с 1985 года, да и то "на пальцах". Язык Рапира слыхали? Тогда даже программируемые калькуляторы только начали появляться в продаже, не говоря уже за компы. Это у нас дорогой Никита Сергеевич постарался. Так что я и на перфокартах дырочки пробивал и на ДВК-3 с объемом памяти 56 кБ, без винта и стандартном Паскале со своими библиотеками на Ассемблере писал. BAT и CMD-файлы и до сих пор пишу, когда надо.
    А вот по поводу "простой бухгалтерии" это Вы о чем?! Вы действительно думаете что платформа 1С 8.2 только для бухгалтерии предназначена?! А системы стандарта MRP-II это по Вашему просто бухгалтерия?!
  19. TopicStarter Overlay
    sobenko
    Offline

    sobenko

    Регистрация:
    1 мар 2012
    Сообщения:
    35
    Симпатии:
    0
    Баллы:
    1
    Как думаете строку "И опыт- сын ошибок трудных" написал глупец? Я не демонстрирую превосходство в возрасте, а демонстрирую наличие опыта программирования на тех языках. На сколько я понимаю процесс нашего обсуждения уже давно перешел в процесс спора. А спор- это словесное состязание при обсуждении чего-либо двумя или несколькими лицами, при котором каждая из сторон отстаивает свое мнение, правоту.
    Я отстаиваю свое мнение демонстрируя различные аргументы, касательно предмета спора.
    Я не вижу смысла тратить время на достаточно сложные теоретические расчеты, когда просто очевидно, что имея канал связи с сервером (или кластером), ограниченный по скорости и ограниченный по производительности сервер (кластер), увеличение числа запросов к серверу (даже самых крохотных) неизбежно ведет к росту загруженности сервера. Когда число бесполезных запросов превысит некоторый предел (для каждой системы свой), то система просто перестанет успевать отвечать. Кроме того, когда бесполезные (но необходимые для обеспечения решения поставленной задачи) запросы начнут нагружать сервер (кластер) на 20-30%, то это уже будет существенно. Вот именно в этом случае технология асинхронного обмена снизит практически до нуля нагрузку на сеть и кластер, при условии что частота оповещений о событиях значительно меньше частоты периодических запросов.
  20. shurikvz
    Offline

    shurikvz Модераторы Команда форума Модератор

    Регистрация:
    1 окт 2009
    Сообщения:
    8.410
    Симпатии:
    316
    Баллы:
    104
    Я думаю, точнее надеюсь, что мы на этом форуме не пиписьками мериться собрались. И не в искусстве риторики упражняться (по крайней мере не в этом разделе, для трепа "за жизнь" у нас есть отдельная замечательная ветка).
    Общая мысль ясна. Я понимаю что потребность демонстрации превосходства является одной из общенческих потребностей человека.
    В любом случае: неужели наличие опыта в программирование на рапире явным образом коррелирует с построением систем на базе платформы 1С?

    Начало фразы замечательное. Я хочу что-то предложить, у меня есть идея, но даже теоретически я не считаю нужным заниматься расчетами.


    Очевидно, но не на 100%. Поскольку вы в своем предположении о превосходстве вашего подхода, начисто выкидываете обращения от клиента к серверу (т.е. как бы плюс к преимуществам вашего метода), но при этом почему-то совершенно забываете учитывать минус (о том что нагрузка по оповещению клиентов полностью ложится теперь на сервер). И получается, сплошные плюсы, и никаких минусов.
    И опять таки, откуда взялось число 20-30%? На основании каких данных? Вы замерили нагрузку? Если бы был замер тогда вопроса бы не возникло, я бы признал, да действительно это проблема. А так, я в ответ спокойно могу сказать, что теоретически при 200 клиентах, да, лишняя нагрузка будет, но даже в самом худшем случае эта лишняя нагрузка на сервер не превысит 0,5%, поэтому смысла в реализации вашей идеи нет. Как опровергать будете?

Поделиться этой страницей