Что не так с опросом?

Ответ 1

Опрос не является "неправильным" как таковым.

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

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

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

Что такое "неправильно" при опросе?

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

Но...

• Это не является по своей сути неправильным.
• Это может быть очень эффективно.
• Это очень просто.

Ответ 2

Есть две причины, по которым опрос может считаться неудачным по принципу.

• Это пустая трата ресурсов. Очень вероятно, что вы проверите изменения, пока никаких изменений не произошло. Циклы CPU/пропускная способность трассировки на это действие не приводят к изменению и, следовательно, лучше потратить на что-то еще.

• Опрос выполняется на определенном интервале. Это означает, что вы не знаете, что произошло изменение до следующего раза, когда этот интервал прошел.

Лучше быть уведомленным об изменениях. Таким образом, вы не проверяете изменения, которые произошли, и вы узнаете об изменениях, как только получите уведомление.

Ответ 3

Примеры вещей, которые используют опрос в этот день и возраст:

• Опрос клиентов по электронной почте для новых сообщений (даже с IMAP).
• Опрос читателей RSS для изменений в каналах.
• Опрос поисковых систем для изменений на страницах, которые они индексируют.
• Опрос пользователей StackOverflow для новых вопросов, нажав 'refresh'; -)
• Клиенты Bittorrent опросили трекер (и друг друга, я думаю, с DHT) для изменений в рое.
• Spinlocks на многоядерных системах могут быть наиболее эффективной синхронизацией между ядрами, в тех случаях, когда задержка слишком короткая, чтобы время было запланировано для другого потока на этом ядре, прежде чем другое ядро ​​сделает все, что мы ожидаем.

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

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

Для локального файла уведомление об изменениях, скорее всего, будет лучшим вариантом в принципе. Например, вы могли бы (возможно) предотвратить дисковое вращение вниз, если вы навсегда его подталкиваете, хотя тогда ОС может кэшировать. И если вы каждый месяц прогоняете файл, который меняется только один раз в час, вы можете без необходимости занимать 0,001% (или что-то еще) от мощности вашей машины. Это звучит крошечно, но что происходит, когда есть 100 000 файлов, которые вам нужно опросить?

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

Ответ 4

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

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

Я всегда стараюсь избегать опроса, но иногда я делаю опрос в любом случае, особенно когда фактические прибыли от асинхронной обработки не так уж велики, например, когда действуют против небольших локальных данных (конечно, вы получаете немного быстрее, но пользователи не заметят разницы в таком случае). Так что есть место для обеих методологий ИМХО.

Ответ 5

Опрос клиентов не масштабируется, а также уведомления о сервере. Представьте, что тысячи клиентов спрашивают у сервера "какие-либо новые данные?" каждые 5 секунд. Теперь представьте, что сервер хранит список клиентов для уведомления о новых данных. Предупреждение сервера лучше масштабируется.

Ответ 6

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

Ответ 7

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

Так зачем идти лишней милей и ставить дополнительный опрос на место.

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

Если вы продолжаете звонить или звонить своей девушке, а shes никогда не отвечает, то зачем звонить? Просто оставьте сообщение и подождите, пока она "перезвонит";)

Ответ 8

Я иногда использую опрос для определенных ситуаций (например, в игре я бы опросил состояние клавиатуры каждый кадр), но никогда в цикле, который ТОЛЬКО делает опрос, скорее я бы сделал опрос как проверку (имеет ресурс X изменилось? Если да, сделайте что-нибудь, иначе обработайте что-нибудь еще и еще раз проверьте позже). Вообще говоря, я избегаю опроса в пользу асинхронных уведомлений.

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

Ответ 9

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

В базе данных вы можете запускать обновление/вставку, а затем вызывать внешний код для чего-то. Однако может быть просто, что у вас нет требования к мгновенным действиям. Например, вам может потребоваться только получить данные из базы данных A в базу данных B в другой сети в течение 15 минут. База данных B может быть недоступна из базы данных A, поэтому вы в конечном итоге выполняете опрос или в качестве автономной программы, находящейся рядом с базой данных B.

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

Ответ 10

Дело в том, что он работает! Его надежный и простой в реализации.

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

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

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

Ответ 11

Здесь я вижу много ответов, но я думаю, что самый простой ответ - это сам ответ:

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

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

Ответ 12

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

Преимущества:

• Дешевые
• Надёжный
• Testable
• Гибкая

Ответ 13

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

Ответ 14

Как и во всем, это зависит. В большой системе с высокой транзакцией, в которой я работаю, в настоящее время используется уведомление с SQL (DLL, загружаемая в SQL Server, который вызывается расширенным SP из триггеров в определенных таблицах. DLL затем уведомляет другие приложения, которые есть над ними).

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

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

Ответ 15

Вот хорошее резюме относительных достоинств push и pull:  https://stpeter.im/index.php/2007/12/14/push-and-pull-in-application-architectures/

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

Ответ 16

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

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

• sql service broker/dependency class
• Некоторая технология очереди (RabbitMQ или аналогичная)
• UDP broadcast - интересная техника, которая может быть построено с несколькими слушателями node. Не всегда возможно на некоторых сетевых работах.

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

Ответ 17

Согласитесь с большинством ответов, что Async/Messaging обычно лучше. Я абсолютно согласен с Робертом Гулдом. Но я хотел бы добавить еще один пункт.

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

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