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

Question

Я слышал, как несколько разработчиков недавно говорили, что они просто опрашивают материал (базы данных, файлы и т. Д.), Чтобы определить, что что-то изменилось, и затем запускают задачу, такую ​​как импорт.

Я действительно против этой идеи и чувствую, что использование доступных технологий, таких как Remoting , WCF и т. Д., Было бы намного лучше, чем опрос.

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

Answer 1

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

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

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

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

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

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

Но ...

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

Answer 2

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

1. Это пустая трата ресурсов. Весьма вероятно, что вы будете проверять изменения, пока они не произошли. Затраты циклов / пропускной способности ЦП на это действие не приводят к изменению и, следовательно, могли бы быть лучше потрачены на что-то другое.

2. Опрос производится через определенный интервал. Это означает, что вы не будете знать, что изменение произошло до следующего интервала.

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

Answer 7

Простой - опрос плохой - неэффективный, растрата ресурсов и т. Д. Всегда существует какая-то форма подключения, которая в любом случае отслеживает какое-либо событие, даже если «опрос» не выбран.

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

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

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

Answer 8

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

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

Answer 9

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

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

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

Answer 10

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

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

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