SDS-Bastelstunde, zwei Fragen
Es macht immer wieder Spaß mit der Chain zu spielen, diesmal war meine Idee, mir Posts und Kommentare in Echtzeit anzeigen zu lassen. Herausgekommen ist ein Skript, dass genau dies macht, allerdings nur fast live, da SDS anscheinend ca. 60 Sekunden benötigt, um die Daten zur Verfügung zu stellen.
Ganz grob, wie das Skript aktuell funktioniert:
Zunächst wird der aktuelle Block gelesen und dann alle 3 Sekunden eine Abfrage gesendet. Der Wert ganz links im Bild sind die Millisekunden, die jeweils auf den nächsten Block gewartet werden. Es sind nicht ganz 3000ms, weil die Dauer der vorigen Abfrage abgezogen wird und so genau alle 3 Sekunden der nächste Block abgefragt wird.
Das Ganze sollte eigentlich rund laufen, tut es aber nicht! Manchmal ist der nächste Block noch nicht verfügbar und das Skript muss darauf warten. (Erster roter Pfeil)
Alle 20 Abfragen erfolgt deshalb ein Abgleich und es gibt ggf. keine Wartezeit auf den nächsten Block, so lange bis Chain und Skript wieder synchron laufen. (Zweiter roter Pfeil)
Welche SDS-Instanz sollte man verwenden?
Die Dev's unter uns wissen, es gibt sds0, sds1 und sds - aber welche Instanz sollte man für was verwenden?
Ich kenne dazu nur diese Info von @steemchiller:
...die sds1-Instanz sollte (solange ausreichend) vorzugsweise von externen Apps verwendet werden und sds (main) nur, falls Probleme auftreten sollten. sds0 kann weiterhin zum Testen genommen werden.
Zusammengefasst:
- sds0 Dev Server zum Testen
- sds1 für externe Apps
- sds externe Apps, falls Probleme mit sds1
Meine zwei Fragen:
1.) Passt das Skript so halbwegs oder gibt es eine elegantere Lösung?
2.) Stimmt das mit den SDS-Instanzen noch?
Die elegantere Lösung wäre, wenn ich in SDS eine Möglichkeit hinzufügen würde, die es erlaubt alle neuen Kommentare und/oder Posts ab einem bestimmten Zeitpunkt abzufragen. Ich habe aktuell mehr als genug auf meiner Liste... aber ich werde mal schauen, ob ich das noch in die bald kommende Version schieben kann.
Die 'blocks_api' liefert aus bestimmten Gründen nur die 'irreversible blocks', daher bekommst du damit nicht alles in Echtzeit, aber es wird in naher Zukunft alternative Methoden dafür geben. Hatte ich sowieso schon auf meinem Zettel ;)
Ja, also für Testzwecke oder auch generell für kleine Tools würde ich sds0 empfehlen. Für ernstere Geschichten empfehle ich sds1 zu nehmen, da neue Versionen immer zuerst auf sds0 laufen und erst nach erfolgreichen Tests auf sds1 übertragen werden.
0.00 SBD,
6.11 STEEM,
6.11 SP
Hab schon gehofft, dass du über meinen Post stolperst. Irgendwie konnte ich mir das mit den SDS-Instanzen nicht merken und hab mir schon öfter deinen alten Kommentar rausgesucht. Die grauen Zellen sind schon oft lustig, wenn ich es nachgelesen habe dachte ich immer, klar, jetzt weiß ich es, aber später war es dann doch wieder im Nirvana bzw. war ich unsicher. So, nach deiner Bestätigung steht es jetzt als Kommentar im Quellcode meiner SDS-Klasse, dann sollte das passen.
Das Script ist ja nur Spielerei, wegen mir musst du keinen neuen Punkt auf deine eh schon volle Liste setzen. Ich bin schon sehr gespannt, was du in der neuen Version für uns gezaubert hast!
0.00 SBD,
0.15 STEEM,
0.15 SP
Spiel bloß nicht zu viel und mach nichts kaputt :)
0.00 SBD,
0.59 STEEM,
0.59 SP
Ich sehe, dir liegt die Funktionsfähigkeit der Kette am Herzen :-D
Spaß beiseite: Es könnten allenfalls die Server durch die Abfragen zusätzlich belastet werden. Wobei Abfragen im Drei-Sekunden-Intervall von der Frequenz her nicht dramatisch sind. Wenn da in jeder Sekunde mehrere auflaufen, kann schon mehr passieren.
Ich bin bei meinen Servern immer wieder faszinierend, was die so für einen Durchsatz haben, ohne in die Knie zu gehen. Die steemnet.org-Domain hat etwa 500k Anfragen pro Tag, die moecki.online-Domain sogar fast 9M. Wahnsinn!
0.00 SBD,
0.85 STEEM,
0.85 SP
9M das ist aber echt heftig, sind nach meiner Rechnung gut 100 pro Sekunde. Ich weiß schon, da sind alle Zugriffe drin, Bilder, Scripte, CSS... Die Zahl wär pro Monat schon ein guter Wert, da können manche von Träumen. Ah, vielleicht sind die Nodes auch mit drin? Also nicht nur Aufrufe über http.
0.00 SBD,
1.36 STEEM,
1.36 SP
Ja, das ist alles, was an http-Traffic über die Domain geht. Anfragen an die Nodes sind darin enthalten, da die ja auch über http gehen. Finde es trotzdem sehr hoch.
Heute werden für die letzten 24 Stunden sogar 10M angezeigt.
Außerdem etwa 5k individuelle Besucher. Vornehmlich aus D und USA, danach Südkorea und Russland.
0.00 SBD,
0.28 STEEM,
0.28 SP
Ich glaube @steemchiller weiß genau was er tut.
Vielleicht kann man ja mal ein Tutorial zum Thema Blockchain aufsetzen damit Blockchain Analphabeten, wie ich auf die alten Tage damit basteln können...😉
0.00 SBD,
0.00 STEEM,
1.05 SP
Im Dienste der Wissenschaft muss man schon mit kleineren Schäden rechnen :-)
0.00 SBD,
0.10 STEEM,
0.10 SP
Doch, das Script scheint schon zu passen.
Echtzeit ist halt so ein Problem. Ich bin schon wegen der vielen Abfragen kein Freund von Echtzeit beim Steem. Außer es gibt zeitkritische Anwendungen, die ich außer bei der Chain selbst, aktuell nicht sehe.
Sogar Hivemind kommt manchmal aus dem Takt, was die drei Sekunden angeht. Dann muss auch dort auf den nächsten Block gewartet werden. Ist wohl irgendwie nicht zu vermeiden, wobei ich dir nicht sagen kann, warum das so ist.
Zu den Instanzen hast du ja schon die Antwort vom Chef persönlich bekommen. Ich nutze fast ausschließlich sds0 für meine Abfragen. Obwohl ich auch schon überlegt hatte, in manchen Anwendungen auf sds1 umzustellen, da manche Updates dann doch plötzlich auf dem sds0 erscheinen. Wenn das dann noch kritische Änderungen sind (neue Felder, geänderte Felder, etc.), kann das die Anwendung schon nachhaltig stören. Chiller gibt zwar meist vorher Bescheid, aber oft kann ich das gar nicht so schnell einschätzen, welche Abfragen ich nun nutze. Mittlerweile schreibe ich mir für jede verwendete Abfrage die jeweilige sds-Version als Kommentar in meinem Code dazu.
0.00 SBD,
0.40 STEEM,
0.40 SP
Danke, wenn du das sagst, dann bin ich beruhigt. Man könnte es auch als Basis für einen Bot hernehmen, der z.B. auf bestimmte Befehle reagiert. Aber da wüsste ich zur Zeit nicht, was man da nützliches machen könnte. Außerdem bin ich ja grundsätzlich ein Freund von selber machen ;-)
Meine Suche hatte ich auch auf sds0, vor ein paar Tagen habe ich aber auf sds1 umgestellt, es soll ja bald eine neue Version kommen. Da bin schon gespannt, was Chiller in seiner SDS-Küche für uns alles gebraten hat :-)
Keine schlechte Idee, ich hab auch nicht im Kopf, welche Abfragen ich nutze. Aber die starten bei mir alle mit
Sds::und das ist überschaubar, Netbeans spuckt mir das schön übersichtlich aus, drum werd ich das vorerst mal so lassen.0.00 SBD,
1.13 STEEM,
1.13 SP
Schön zusehen das du mal wieder Zeit hast zu scripten
0.00 SBD,
0.26 STEEM,
0.26 SP