search

SeidChr / AutoTagger

Proof of Concept for a Instagram Best-Tag-Finder
1 stars 1 forks source link

Zahlen, bitte #10

Open DariosKrimsKrams opened 6 years ago

DariosKrimsKrams commented 6 years ago

Habe CrawlerV1 mal bisschen laufen lassen:

4:00 Std. lief Crawler (bis die DB ein 'Connect Timeout expired' zurückgab) ca. 4.000 Requests 15.000 Fotos 330.000 nicht-unique iTags 40.000 unique iTags durchschnittlich 3,6 Sek pro Requests durchschnittlich 3,75 Fotos pro Request durchschnittlich 22 iTags pro Foto

Habe ihn mit random Hashtags crawlen lassen. Er ist gefühlt durch alle Themen/Bereiche durch. Lustig: Einiges an Arabischem und Chinesischem ist dabei.

(in VS im Debug Mode laufen lassen, dort ist der Crawler fühlbar langsamer - im Nicht-Debug oder compiled kriegt man wahrscheinlich bessere Performance raus)

DariosKrimsKrams commented 6 years ago

Weitere: 4:02 h Crawling (inkl. AutoReconnect nach DB Connection Timeout) 14.000 Fotos 3.500 Fotos / Minute 300.000 nicht-unique iTags insgesamt 74.000 unique iTags in DB

(Wieder VC Debug Mode, Immer noch nicht geblockt wurden von Instagram)

DariosKrimsKrams commented 6 years ago

Als compiled Consolenapp nach 2 h: 2.200 Requests 9.500 Fotos 78 Fotos / Minute 4.700 Fotos / Std 1.100 Requests / Std durchschnittlich 3,2 Sek pro Requests insgesamt 90.000 unique iTags in DB insgesamt 860.000 nicht-unique iTags in DB

SeidChr commented 6 years ago

Nice. Wie schaut's bei dem anderen Crawler aus?

Ps: speichere nur unique tags. Alles andre macht keinerlei Sinn

DariosKrimsKrams commented 6 years ago
SeidChr commented 6 years ago

nur einmal am tag? hmm klingt grad nicht nach einer guten idee. Nicht db neu aufsetzen. mach die human tags zu einer unique spalte (ich geh davon aus du redest von deiner sql datenbank)

DariosKrimsKrams commented 6 years ago

was meinst du mit "einmal am tag"? glaube, wir haben aneinander vorbei geredet. Also vorher gab es ne 1:n beziehung. Sprich wenn tag "travel" von photo1 und photo2 benutzt wurde, gab es in tabelle "itags" zwei einträge.. ist natürlich kacke.. Daher der umbau auf n:n bez.

ja, relationale db. durch die n:n beziehung brauche ich jedoch eine "relation" tabelle photos-Table: id | url | ... photo-itag-relation-Table: id | photoId | itagId itags-Table: id | name | ... (also "neu aufsetzen" natürlich nicht, jedoch ne tabelle dazwischen klemmen und mein EntityFramework InsertOrUpdate bisschen umbasteln) siehe -> sql structure

SeidChr commented 6 years ago

Siehe slack..

DariosKrimsKrams commented 6 years ago

Mit besserer DB Struktur (+ DB geleert) und weiteren Bedinungen (um für relevant zu gelten):

Durchschnitt:

Bug 1: Was die Laufzeit angeht, gibt's iwo nen Bug, dass es mittendrin für 1 Minute, 10 Min oder 1 Std. pausiert und erst danach Requests und DB Speicherung weitermacht o.O Bug 2: Zu jedem ITag, bei dem er die Tags/Explode/{itagName} crawlt, speichert er die AmountOfPost. Dass es nur 750 sind, kann nicht sein.. Hier ist also auch noch iwo ein Käferchen

DariosKrimsKrams commented 6 years ago

7:30 h -> 5k Fotos... oder 5,5 Sek pro Foto, da muss noch mehr gehen durch Multithreading...

SeidChr commented 6 years ago

Bitte bau einen limiter ein der die anzahl von requests an einen server (z.B. Instagram) pro zeitraum einstellbar macht über eine config. Edit: das könnte ein größeres thema sein. wäre auf jeden fall gut wenn man das von außen tacken und ggf unterbrechen könnte wenn es zu viel wird.

DariosKrimsKrams commented 6 years ago

Hi :) Wieso die Sorge um zu viele Requests (pro Zeitraum) und warum ein größeres Thema? Edit: Meine Sorge ist eher, dass ich mehr Requests pro Sekunde haben will (durch Umbau auf Multithreading)

SeidChr commented 6 years ago

Damit wir nicht irgendwann in eine DDOS protection oder einen anderen Spam-Schutz laufen oder sonstwie auffällig werden. Das serverteam von Instagram wird sicher ein Auge darauf haben wenn so und so viele gleichartige requests pro Sekunde aus einer IP-Range kommen. Wenn wir die Crawler skalieren wollen um besser parallel zu arbeiten brauchen wir einen weg um die menge von Abfragen zu tunen um nicht aufzufallen.