Was ist falsch an Umfragen?

https://stackoverflow.com/questions/320284

11-07-2019
|

Frage

Ich habe kürzlich einige Entwickler sagen hören, dass sie lediglich Dinge (Datenbanken, Dateien usw.) abfragen, um festzustellen, wann sich etwas geändert hat, und dann eine Aufgabe ausführen, beispielsweise einen Import.

Ich bin wirklich gegen diese Idee und habe das Gefühl, dass die Nutzung verfügbarer Technologien wie z Fernzugriff, WCF, usw.wäre weitaus besser als Umfragen.

Ich möchte jedoch die Gründe herausfinden, warum andere Menschen einen Ansatz dem anderen vorziehen, und, was noch wichtiger ist: Wie kann ich andere davon überzeugen, dass Umfragen heutzutage falsch sind?

Lösung

Umfragen sind als solche nicht „falsch“.

Viel hängt davon ab, wie und zu welchem Zweck es umgesetzt wird.Wenn Ihnen die sofortige Benachrichtigung über eine Änderung wirklich wichtig ist, ist dies sehr effizient.Ihr Code befindet sich in einer engen Schleife und fragt ständig eine Ressource ab, ob sie geändert/aktualisiert wurde.Das bedeutet, dass Sie schnellstmöglich benachrichtigt werden, wenn etwas anders ist.Aber Ihr Code macht nichts anderes und es entsteht ein Mehraufwand durch viele, viele Aufrufe des betreffenden Objekts.

Wenn Ihnen die sofortige Benachrichtigung weniger wichtig ist, können Sie das Intervall zwischen den Umfragen verlängern. Dies kann auch gut funktionieren, aber die Wahl des richtigen Intervalls kann schwierig sein.Zu lange und Sie verpassen möglicherweise wichtige Änderungen, zu kurz, und Sie kehren zu den Problemen der ersten Methode zurück.

Alternativen wie Interrupts oder Nachrichten usw.kann in diesen Situationen einen besseren Kompromiss bieten.Sie werden über eine Änderung benachrichtigt, sobald dies praktisch möglich ist. Diese Verzögerung liegt jedoch nicht in Ihrer Hand, sondern hängt davon ab, dass die Komponente selbst Zustandsänderungen rechtzeitig weitergibt.

Was ist „falsch“ an Umfragen?

Es kann ressourcenintensiv sein.
Es kann einschränkend sein (besonders, wenn Sie viele Dinge wissen möchten/umfragen).
Es kann übertrieben sein.

Aber...

Es ist nicht grundsätzlich falsch.
Es kann sehr effektiv sein.
Es ist sehr einfach.

Andere Tipps

Es gibt zwei Gründe, warum Polling durch Prinzip schlecht angesehen werden könnte.

Es ist eine Verschwendung von Ressourcen. Es ist sehr wahrscheinlich, dass Sie für eine Änderung überprüfen, während keine Änderung aufgetreten ist. Die CPU-Zyklen / Bandbreite Ausgaben für diese Aktion nicht zu einer Änderung führen und somit sonst besser Ausgaben für etwas gewesen sein könnte.
Polling wird auf einem bestimmten Intervall durchgeführt. Das bedeutet, dass Sie nicht wissen, dass eine Änderung bis zum nächsten Mal aufgetreten ist, dass das Intervall abgelaufen ist.

Es wäre besser, über Änderungen werden. Auf diese Weise sind Sie nicht die Abfrage von Veränderungen, die nicht stattgefunden haben, und Sie werden so bald eine Änderung wissen, wie Sie die Benachrichtigung erhalten.

Beispiele für Dinge, die Abfrage in der heutigen Zeit verwenden:

E-Mail-Clients Umfrage für neue Nachrichten (auch mit IMAP).
RSS-Reader für Änderungen Feeds abrufen.
Suchmaschinen-Umfrage für Änderungen an den Seiten, die sie Index.
Stackoverflow Benutzer Umfrage für neue Fragen, durch Schlagen 'Refresh'; -)
abfragen Bittorrent-Clients den Tracker (und sich gegenseitig, glaube ich, mit DHT) für Änderungen im Schwarm.
Spinlocks auf Multi-Core-Systemen kann die effizienteste Synchronisation zwischen den Kernen sein, in Fällen, in denen die Verzögerung zu kurz ist, denn es Zeit, um auf diesem Kern eines weiteren Thread zu planen, bevor der andere Kern tut, was wir warten auf .

Manchmal einfach gibt es keine Möglichkeit, asynchrone Benachrichtigungen zu erhalten: zum Beispiel RSS ersetzen mit einem Push-System, würde der Server über jeden wissen, wer den Feed liest und hat einen Weg, sie zu kontaktieren. Dies ist eine Mailing-Liste - genau eines der Dinge, RSS wurde entwickelt, zu vermeiden. Daraus ergibt sich die Tatsache, dass die meisten meiner Beispiele sind Netzwerk-Anwendungen, wo dies am wahrscheinlichsten ist, ein Problem sein.

Andere Zeiten, Polling ist billig genug, um selbst zu arbeiten, wo es Asynchron-Benachrichtigung ist.

Für eine lokale Datei, Benachrichtigung über Änderungen ist wahrscheinlich die bessere Option im Prinzip sein. Zum Beispiel könnten Sie (vielleicht) nach unten drücken die Scheibe Spinnen verhindern, wenn Sie für immer es Stossen, obwohl dann wieder die OS-Cache könnte. Und wenn Sie Polling sind jede Sekunde auf eine Datei, die nur einmal pro Stunde ändert, könnten Sie unnötig sein 0,001% einnehmen (oder was auch immer) Ihre Rechenleistung der Maschine. Das klingt winzig, aber was passiert, wenn es 100.000 Dateien müssen Sie abfragen?

In der Praxis allerdings ist der Aufwand wahrscheinlich vernachlässigbar sein je nachdem, was Sie tun, macht es schwer, sich aufzuregen über Code zu ändern, die derzeit arbeitet. Das Beste ist für bestimmte Probleme zu achten, dass die Abfrage auf dem System verursachen Sie ändern möchten - wenn Sie feststellen, jede dann diejenigen zu erhöhen anstatt zu versuchen, ein allgemeines Argument gegen alles Polling zu machen. Wenn Sie eine nicht finden, dann kann man nicht reparieren, was nicht kaputt ist ...

Polling ist einfach zu tun, sehr einfach, seine so einfach wie jeder prozeduralen Code. Nicht Polling bedeutet, dass Sie in die Welt der asynchronen Programmierung geben, die nicht als hirntot einfach ist, und könnte sogar werden manchmal herausfordernd.

Und wie bei allem in jedem System, der Weg des geringeren Widerstands ist in der Regel häufiger genommen, so wird es immer Programmierer seines Polling, auch große Programmierer, denn manchmal gibt es keine Notwendigkeit, die Dinge verkomplizieren mit asynchronen Mustern.

ich für eine gedeihen immer Polling zu vermeiden, aber manchmal Polling ich sowieso, vor allem, wenn die tatsächlichen Gewinne der asynchronen Handhabung sind nicht so groß, wie wenn gegen einige kleine lokale Daten handeln (natürlich bekommen Sie ein wenig schneller , aber die Benutzer nicht den Unterschied in einem Fall wie diesem) bemerken. So gibt es Raum für beide IMHO Methoden.

Client Polling nicht Maßstab sowie Server-Benachrichtigungen. Stellen Sie sich vor tausende Kunden fragen den Server „neue Daten?“ alle 5 Sekunden. Nun stellen Sie den Server eine Liste der Kunden zu halten von neuen Daten zu informieren. Server Benachrichtigung besser skaliert.

Ich denke, die Menschen sollten erkennen, dass zu einem gewissen Grad in den meisten Fällen Polling gibt es getan, auch in Veranstaltung oder angetrieben Situationen unterbrechen, aber Sie sind von dem eigentlichen Code tut das Polling isoliert. Wirklich, das ist die wünschenswerteste Situation ... isoliert sie von der implementaion, und nur mit dem Fall befassen. Selbst wenn Sie die Abfrage implementieren müssen sich, den Code schreiben, so dass es isoliert, und die Ergebnisse werden mit unabhängig von der Implementierung behandelt.

Es ist einfach - Polling ist schlecht - ineffizient, Verschwendung von Ressourcen, etc. Es gibt immer irgendeine Form der Konnektivität an Ort und Stelle, die ohnehin für ein Ereignis von einer Art Überwachung, auch wenn ‚Polling‘ nicht gewählt wird,

Also, warum geht die extra Meile und zusätzliche Abfrage in Stelle setzen.

Rückrufe sind die beste Option - brauchen nur den Rückruf kümmern zu binden etwa in mit Ihrem aktuellen Prozess. Zugrunde liegt, es geht um Abfrage zu sehen, auf daß die Verbindung trotzdem noch an seinem Platz ist.

Wenn Sie immer telefonieren / klingeln Ihre Freundin und shes nie Antworten, warum dann rufen halten? Nur eine Nachricht hinterlassen, und warten, bis sie ‚ruft zurück‘;)

ich Polling verwenden gelegentlich für bestimmte Situationen in einer Schleife, aber nie Polling, die nur funktioniert (zum Beispiel in einem Spiel, ich die Tastatur Zustand jeder Frame abfragen würde), sondern würde ich Polling als Kontrolle tun (hat Ressource X geändert? Wenn ja, etwas tun, sonst Prozess etwas anderes und prüfen Sie es später noch einmal). Generell sind aber gesagt, ich vermeiden Polling für asynchrone Benachrichtigungen.

Die Gründe sind, dass ich nicht verbringen Ressourcen (CPU-Zeit, was auch immer) auf etwas warten passieren (vor allem, wenn diese Ressourcen das Ding in erster Linie geschieht beschleunigen könnten). Die Fälle, in denen ich Polling verwenden, ich sitze nicht still und wartet, ich die Ressourcen an anderer Stelle, so ist es kein Thema (für mich zumindest).

Wenn Sie die Abfrage von Änderungen an einer Datei sind, dann stimme ich zu, dass Sie die Dateisystem-Benachrichtigungen verwenden sollten, die für die zur Verfügung stehen, wenn dies geschieht, die jetzt in den meisten Betriebssystemen zur Verfügung stehen.

In einer Datenbank, die Sie auf Update / Insert auslösen könnte und dann externen Code aufrufen, etwas zu tun. Allerdings könnte es nur sein, dass Sie keine Anforderung für sofortige Aktionen haben. Zum Beispiel müssen Sie nur Daten aus der Datenbank A zur Datenbank B in einem anderen Netzwerk innerhalb von 15 Minuten zu bekommen. Datenbank B von Datenbank A nicht zugänglich sein könnte, so dass man am Ende von der Abfrage tun, oder als ein eigenständiges Programm in der Nähe läuft, Datenbank B.

Auch Polling ist eine sehr einfache Sache zu programmieren. Es ist oft ein erster Schritt die Umsetzung erfolgt, wenn Zeitdruck kurz sind, und weil es gut genug funktioniert, bleibt es.

Die Sache über Polling ist, dass es funktioniert! Sein zuverlässige und einfach zu implementieren.

Die Kosten für Pooling können hoch sein - wenn Sie jede Minute eine Datenbank für Änderungen scannen, wenn es nur zwei Änderungen pro Tag Sie eine Menge von Ressourcen für ein sehr kleines Ergebnis verbrauchen

Doch das Problem mit jeder Meldung technoligy ist, dass sie viel komplexer sind nur zu implementieren und nicht können sie als unzuverlässig aber (und das ist ein großes ABER) man nicht einfach sagen können, wenn sie nicht arbeiten.

Also, wenn Ihnen die Abfrage von einem anderen technoligy fallen lassen sicherstellen, dass es durch die durchschnittlichen Programmierer verwendbar ist und ist extrem zuverlässig.

Ich sehe hier viele Antworten, aber ich denke, die einfachste Antwort die Antwort selbst ist:

Da ist (in der Regel) viel einfacher eine Abfrageschleife zu codieren, als die Infrastruktur für Rückrufe zu machen.

Dann erhalten Sie einfacher Code, der, wenn es später zu einem Engpass erweist sich leicht in etwas anderes verstanden und neu gestaltet / Refactoring werden.

Dies ist Ihre Frage nicht beantworten. Aber realistisch gesehen, vor allem in diesem „Tag und Alter“, wo Prozessorzyklen sind billig, und die Bandbreite ist groß, Polling ist eigentlich eine ziemlich gute Lösung für einige Aufgaben.

Die Vorteile sind:

Billige
Reliable
Prüfbar
Flexible

Ich bin damit einverstanden, dass die Abfrage zu vermeiden, ist eine gute Politik. In Bezug jedoch auf Robert Post , würde ich sagen, dass die Einfachheit der Wahl macht es einen besseren Ansatz in Fällen, wo die Probleme hier erwähnt werden, sind nicht so ein großes Problem dar, da der asynchrone Ansatz oft wesentlich weniger lesbar und schwieriger zu pflegen, nicht die Fehler zu erwähnen, die zu seiner Umsetzung einschleichen können.

Wie bei allem, es hängt davon ab. Ein großes High-Transaktionssystem I auf derzeit arbeite verwendet eine Benachrichtigung mit SQL (einer DLL in SQL Server geladen, die von einem erweiterten SP von Triggern auf bestimmte Tabellen genannt wird. Die DLL benachrichtigen dann andere Anwendungen, dass es Arbeit zu tun).

Doch wir ziehen weg von diesem, weil wir praktisch garantieren können, dass es Arbeit sein wird, kontinuierlich zu tun. Deshalb, um die Komplexität und die tatsächlich zu beschleunigen Dinge ein wenig zu reduzieren, werden die Anwendungen ihre Arbeit verarbeiten und sofort die DB abfragen wieder für neue Arbeit. Sollte es keine geben, es wird versuchen, wieder nach einer kleinen Pause.

Dies scheint schneller zu arbeiten und ist viel einfacher. ein anderer Teil der Anwendung jedoch die viel niedriger Lautstärke ist nicht von einer Geschwindigkeitserhöhung profitieren mit dieser Methode - es sei denn, das Abfrageintervall sehr klein ist, was zu Performance-Problemen. So sind wir es verlassen, wie für diesen Teil ist. Deshalb ist es eine gute Sache, wenn es angemessen ist, aber jedermanns Bedürfnisse unterschiedlich sind.

Hier ist eine gute Zusammenfassung der relativen Vorteile von Push-und Pull: https://stpeter.im /index.php/2007/12/14/push-and-pull-in-application-architectures/

Ich wünschte, ich es weiter in diese Antwort zusammenfassen könnte, aber einige Dinge sind am besten links ungekürzt.

Wenn man über SQL Abfrage zu denken, wieder in dem Tag von VB6 Sie in der Lage verwendet werden Cord-Sets erstellen das Schlüsselwort Withevents verwendet, die eine frühe Inkarnation von Asynchron war „Hören“.

Ich persönlich würde immer für eine Möglichkeit, ein Ereignisses der Verwendung vor der Wahl angetrieben Umsetzung. Gelingt das nicht eine manuelle Durchführung einer der folgenden Punkte helfen könnten:

SQL-Service-Broker / dependency Klasse
Eine Art Warteschlange Technologie (RabbitMQ oder ähnliches)
UDP-Broadcast - interessante Technik, die kann werden mit mehreren Knoten Hörer eingebaut. Nicht immer möglich, auf einigen Netzwerken aber.

Einige von ihnen können eine leichte Neugestaltung Ihres Projekts benötigen, aber in einer Unternehmens Welt könnte die bessere Route zu gehen, anstatt eine Abfrage-Service.

Agréée mit den meisten Antworten, die Async / Messaging ist in der Regel besser. Ich stimme absolut mit Robert Gould Antwort. Aber ich möchte noch einen Punkt hinzuzufügen.

Eine Ergänzung ist, dass die Abfrage zwei Fliegen mit einer Klappe schlagen. In einem besonderen Anwendungsfall, war ein Projekt, das ich mit den beteiligten eine Nachrichtenwarteschlange zwischen Datenbanken aber Abfrage von einem Anwendungsserver auf eine der Datenbanken verwendet. Da das Netzwerk von App-Server DB gelegentlich nach unten war, wurde Polling zusätzlich verwendet die App von Netzwerkproblemen zu informieren.

Am Ende verwenden, was macht am meisten Sinn für den Anwendungsfall mit Scale-Fähigkeit im Auge behalten.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow