skamilinux.hu

Helló, itt egy tesztverzió i686, GTK2.
http://oscomp.hu/depot/ytfe18dev.xz

Ebben van persistent connection-ra lehetőség, a Prefs/Other alatt; kíváncsi vagyok, hogy ez így lejjebb viszi-e a csatlakozások miatti időt váltáskor. Ha megkérlek, kipróbálod, hogy gyorsabb lett-e a videók közti váltás bekapcsolt persistent connectionnel?

Nincs változás, nem gyorsabb ha kipipálom.

Fura. Valamennyit gyorsulnia kellett volna. Direkt megnéztem, még 5 perc után is alive a kapcsolat, szóval elvileg váltáskor nem kell újra felépítenie. Mondjuk, ha cache-ből jönnek neked ezek a page-ek, akkor nem is birizgálja a netet, de akkor meg végképp nem értem, miért tart 10 másodpercig a váltás, még úgy is, hogy ebből kb. 4-et a player eszik meg.

Megtennéd, hogy bekapcsolod a loggolást, elindítod a playlistet, megvárod, míg lejátssza az első videót, átlép a következőre és elkezdi azt is lejátszani, majd a /tmp/ytfe.log fájlt feltöltöd valahova, vagy elküldöd nekem?

3-4 videót néztem. A .gz hamis nevezd vissza.

ytfe.log.gz: (32.96 KiB) Letöltve 327 alkalommal.

Mindegyik page lekérés (amik az egész feldolgozás első lekérései) kb 2.5-3 sec volt.

Megnéztem a page-query idejét is: 12104 ms volt a teljes lekérési procedúra, ebből az első GET (a page) volt 3043 ms, a második (a player.js) 5317. A maradék 3744 a többi (JSON processing, signature deciphering, formátumlista felépítése) együtt.

Raktam még több logging entry-t a kódba, hogy lássuk, mi lassú ennyire.

Link ugyanaz: http://oscomp.hu/depot/ytfe18dev.xz

Most arra kérnélek, hogy mindkét esetet vizsgáljuk meg, azaz:

- Logging off
- Persistent connection off
- /tmp/ytfe.log törlése
- Cache törlése
- Logging on
- Valamelyik playlisted lejátszása pár videó elejéig
- Logging off
- tmp/ytfe.log backupolása mondjuk ytfe_pc0.log néven
- Persistent connection on
- /tmp/ytfe.log törlése
- Cache törlése
- Logging on
- Ugyanaz a playlisted lejátszása ugyanannyi videó elejéig
- Logging off
- tmp/ytfe.log backupolása mondjuk ytfe_pc1.log néven
- ytfe_pc0.log és ytfe_pc1.log feltöltése, vagy elküldése nekem

Így most már látni fogjuk, hogy melyik feldolgozási szakasz és melyik lekérés mennyit eszik és hogy mennyit segít ezen a persistent connection...

Köszi, hogy segítesz debuggolni. : )

Nálam a log fájlok a /var/log mappában keletkeztek.
Küldöm a két fájlt:

ytfe_pc0.log.gz: (57.68 KiB) Letöltve 330 alkalommal.

ytfe_pc1.log.gz: (61.97 KiB) Letöltve 331 alkalommal.

Köszönöm szépen. Kielemeztem az egyik query-t, hogy miből áll össze mindkét oldalon:

Kód: Egész kijelölése

pc0 total           62239-49078=13161
- init              49084-49078=6
- get page*         53266-49084=4182
- html parse        53487-53288=199
- iterating scripts 60198-53487=6711
- - paging json     59442-53494=5948
- - - find json     54021-53494=527
- - - get player*   59377-54021=5356
- - - processing    59442-59377=65
- - format json     59498-59449=49
- - - find json     59488-59449=39
- - - processing    59498-59488=10
- - find page json  60197-59505=692
- process page json 60228-60198=30
- prepare n-sig     60385-60328=57
- decipher n-sig*   62201-60385=1816
- finalize          62239-62201=38

total internal: 1851
iterating internal: 1355
finding jsons: 1258

===

pc1 total           69665-54577=15088
- init              54579-54577=2
- get page*         58272-54579=3693
- html parse        58448-58294=154
- iterating scripts 67407-58450=8957
- - paging json     66647-58460=8187
- - - find json     58905-58460=445
- - - get player*   66590-58905=7685
- - - processing    66647-66590=57
- - format json     66717-66654=63
- - - find json     66707-66654=53
- - - processing    66717-66707=10
- - find page json  67406-66726=680
- process page json 67439-67407=32
- prepare n-sig     67593-67439=154
- decipher n-sig*   69652-67593=2059
- finalize          69665-69652=13

total internal: 1651
iterating internal: 1272
finding jsons: 1178

Ebből kiviláglik, hogy a program belső folyamatai kb. 1.6-1.8 másodpercet vesznek igénybe (éreztem én, hogy azért nem ehet meg maga a program 3 másodpercet), a többit maguk a GET kérések, ill. az N-signature JS interpretereses decipherelése (ezeket csillaggal jelöltem) csinálja; ez utóbbi, akár 2 másodpercig is eltarthat.
Ezeken sajnos nem nagyon tudok segíteni, a JS interpretert nem én írtam, a GET kéréseknek meg szemmel láthatólag nem nagyon számít a persistent connection, teljesen véletlenszerű, hogy mikor melyik mennyi ideig tart, élő kapcsolat ide, vagy oda. (Ami furcsa, de ez van.)

Ami a belső folyamatokból sokat eszik, az a JSON-ok megtalálása, azok teszik ki a legnagyobb részét. Azon talán tudok segíteni, valami optimálisabb megközelítéssel, de azon max. pár tizedmásodpercet nyerünk...persze ki a kicsit nem becsüli...

Asszem majd rakok a HuntForJSON() függvénybe is pár log entry-t, hogy lássam, mi mennyit zabál, aztán ha van, ami kilóg, akkor talán lehet rajta gyorsítani.

Köszi még egyszer a segítséget.

Az EndOfJSON() függvényben tényleg volt némi optimalizálnivaló (failed search után ne mindig 0-ról kezdje, ha egy részét már megtalálta, mind1, részletkérdés), de ennek ellenére is úgy látom, hogy - nálam - a parse-álás az, ami a sok időt viszi, amit pedig a FreePascal GetJSON() függvénye intéz, szóval, ha az a lassú, akkor ezzel sincs mit kezdeni.

Felkérhetlek még egy utolsó tesztre? : )
Itt az új tesztbináris: http://oscomp.hu/depot/ytfe18dev.xz
Cachetörlés és a loggolás bekapcsolása után ki kéne nyitni egyetlen videót, aztán a logot ismét feldobni valahova.
Előre is köszi.

Akkor ez nem playlista, hanem az ytfe böngészőjében rákattintok egy videóra, előkeresi, majd manuálisan elindítom a lejátszást.
Kétszer csináltam, a másodiknál „persistent connection“ on .

ytfe_pc3.log.gz: (19.12 KiB) Letöltve 366 alkalommal.

ytfe_pc4.log.gz: (18.71 KiB) Letöltve 341 alkalommal.

Köszi.

Az EndOfJSON() 12, 3 és 6 ms-t tett ki az egyikben és 7, 2 és 5 ms-t a másikban. Nem az a ludas.

Ezzel szemben a JSON parse-olását végző GetJSON() az 473, 37 és 171 ms-t tett ki az egyikben és 562, 51 és 235 ms-t a másikban. Egyszóval az a lassú, azzal meg nem tudok mit kezdeni, az a FreePascal egyik libjében van. (És lehet, hogy egyébként nem is lassú, csak tényleg ekkora adathalmot kap a YT-tól.)

Szóval abból az 1.6-1.8 másodpercből, ami a program sara kb. 1.1-1.2 másodpercet a JSON parsing visz el, a maradék 0.4-0.7 másodperc az én kódom futásideje.

Én itt sajna többet nem tudok tenni. : (

Köszi, hogy segítettél mérni.

skamilinux.hu

YTFE

Re: YTFE

Re: YTFE

Re: YTFE

Re: YTFE

Re: YTFE

Re: YTFE

Re: YTFE

Re: YTFE

Re: YTFE

Re: YTFE