Miért van kevesebb?!? A HUP haldoklik?!?

Ugyan egyesek szeretnék hinni, de a valóság ennél egy kicsit prózaibb. Az új motor máshogy számol és jelenít meg néhány dolgot. Például a "Jelenlévő felhasználók" blokkban már nem jeleníti meg az online, de anonymous (nem bejelentkezett) felhasználókat. A cikkek olvasottságánál pedig nem veszi figyelembe azokat a kattintásokat, amelyeket olyan látogatók végeznek, akik explicite tiltják a JavaScript-et vagy bizonyos blocker böngésző-kiegészítőket használnak.

Tehát: természetesen a HUP haldoklik, de a valódi ok fent olvasható.

( p2pking | 2019. 11. 14., cs – 10:41 )

Mint a Rock & Roll ugy 60 eve... lol :D

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

( TCH | 2019. 11. 14., cs – 10:41 )

> A cikkek olvasottságánál pedig nem veszi figyelembe azokat a kattintásokat, amelyeket olyan látogatók végeznek, akik explicite tiltják a JavaScript-et vagy bizonyos blocker böngésző-kiegészítőket használnak. Ezt hogy? Ha kinyitok egy aloldalt, akkor mindenképpen látja a szerver, hogy lekértem, ennyi erővel már akkor lehet inkrementálni az olvasottságszámlálót; miért kell ehhez külön JS?
Oldschool Computer - http://oscomp.hu

miért kell ehhez külön JS?

Hogy ez jó így, nem jó így, hogy ez bug, vagy tervezett feature, azt én nem vizsgáltam. Leírtam egy többször felmerült kérdésre azt, amit én jelenleg tapasztalok. Másnál kijöhet más eredmény is. Ha bug, felírom a listára. Ha feature, akkor ez van. Jelenlegi infóim szerint ez feature. 

trey @ gépház

A szerverig el kell, hogy jusson a kérés, mert valamit kapunk vissza. Azt, hogy a visszaküldentő eredményt a gyorsítótárból húzza elő, az nem gátolja meg abban, hogy a DB felé küldjön egy aszinkron kérést. Mit értesz egyáltalán az alatt, hogy "külső gyorsítótár"?
Oldschool Computer - http://oscomp.hu

Ha mondjuk Varnish van az oldal előtt, akkor beállítható úgy, hogy csak akkor jusson el a kérés a Drupalhoz, ha változott valami az oldalon, egyébként pedig kiszolgálja a Varnish, mintha statikus weboldal lenne. Az nginx is képes erre, vagy másik példa a Drupal Boost modulja, ami statikus fájlként letárolja a weboldalt és ha nem változott semmi a anonymous látogatóknak, akkor azt adja vissza.

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

A Varnish tudja forwardolni cache-hit esetén a requestet a backend felé, tehát Varnishnál megoldható szerveroldalon. NGinx esetén is van megoldás arra, hogy szerveroldalon frissítsük a számlálót, mondjuk ez a logparsing nem biztos, hogy a legoptimálisabb; egy NGinx gurut kéne megkérdezni, hogy van-e request forward-ra lehetőség NGinx cacheing esetén. A Boost pedig a Drupal része. Gondolom így sem egy vanilla Drupal hajtja az oldalt; bele lehetne írni tíz sort a Boost kódjába, ami egy aszinkron DB kérést megereszt a cache-hit-ek esetén.
Oldschool Computer - http://oscomp.hu

Nem azt mondtam, hogy a Varnish vagy nginx nem tudja ezt kezelni, mint ahogy a modullal is megoldható. Azt mondtam, hogy közel sem biztos az, hogy a kérés eljut a Drupalig.

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

Viszont akkor ez egy irreleváns információ volt, hogy eljut-e a Drupalig a lekérés, vagy sem, hiszen, ha a számlálót a Drupal megkerülésével is lehet frissíteni, akkor érdektelen, hogy a Drupal látta-e, vagy sem. A lényeg, hogy megoldható szerveroldalon; szükségtelen a kliens felől egy újabb lekérés, ami csak egy hit-countert léptet, így ugyanis mindkét oldalon (meg magán a hálózaton is) csak nagyobb lesz az overhead, mert két lekérés lesz egy helyett, úgy, hogy szerveroldalon az érintett DB kérést nem spóroltuk meg, csak egy második lekérés fogja végrehajtatni, viszont kliensoldalon megint van egy pluszban futó JS kódszegmens. Lose-lose.
Oldschool Computer - http://oscomp.hu

Viszont a Javascript tiltás leginkább a botokat érinti, azokat beleszámolni pedig felesleges. Viszont arra ritkább esetben tud az átlag ügyfél hatni, hogy egy külső gyorsítótár hogyan van beállítva.

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

Általános megoldás alatt azt értem, ami nem csak a HUP-pal, hanem általában bármilyen működő Drupal 8-al képes együtt működni, lehetőleg függetlenül az általa használt gyorstárazási megoldástól.

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

Ez így nem mond semmit. Nincs 100% általános megoldás. Mit érek azzal, ha pl. adok egy PHP-t, aminek akár shell-ből, akár HTTP kérésből át lehet adni URL-t, vagy content ID-t, hogy ennek a viewcountját kell inkrementálni, ha aztán közlöd, hogy nem lehet illeszteni a backendhez, mert nem tud PHP-t meghívni sem így, sem úgy. Csak úgy mondom, hogy az sem általános megoldás, ami most van, hisz letiltott kliensoldali JS mellett nem működik.
Oldschool Computer - http://oscomp.hu
Látod erre mondtam, hogy aki konstruktívan állna hozzá és nem az a célja, hogy téged cseszegessen, az sem kap érdemi választ. Most akkor van egy JS alapú megoldás, ami nem csak, hogy felesleges overheadet csinál mindenütt, de ráadásul a jelek szerint nem is működik rendesen, továbbá ki is kerülhető. Oké, csinálja meg a szerveroldalit, aki annyira akarja, de specifikáció nélkül implementáció sincsen; általános megoldás nincs és nem is kell: az egyik cacheing technológia ezt tudja, a másik meg azt, ennek megfelelően egy a hupon futó szerveroldali viewcount incrementernek a hupon használt cacheing technológiával kellene mennie, amit viszont nem voltál hajlandó elárulni, hogy mit használtok - elvárnád, hogy az ember vaktában dolgozzon. De marad a "remek" és "általános" JS-alapú megoldás, csak azért, hogy JS legyen.
Oldschool Computer - http://oscomp.hu

Nézd, én teljesen konstruktívan állok hozzá.

A jelenlegi megoldás ugyan Javascriptet használ, viszont mivel joggal feltételezzük, hogy a látogatók jelentős része engedélyezi a javascriptet a böngészőjében, ez igazából csak plusz egy lekérést jelent. Ha ez valakinek nem fér bele, akkor ott már más problémák is vannak.
Cserében viszont nem fogunk egyedi, senki által nem tesztelt és vizsgált megoldást alkalmazni csak azért, mert valaki ódzkodik a Javascripttől és a plusz egy lekéréstől. Ezért mondtam, hogyha neked a jelenlegi megoldás problémás, akkor írd meg általánosan és tedd közzé „több szem többet lát alapon”. Mivel a HUP kezdettől fogva igyekszik minél közelebb lenni az eredeti kódbázishoz, ezért biztosan nem fogunk „csak úgy” egy egyedi PHP-t betenni, amiről nem tudjuk, hogy milyen egyéb mellékhatást okoz. Ráadásul úgy, hogy az abban előforduló esetleges biztonsági hibákért nem a megoldás készítője lesz a felelős.
Majd ha a HUP tulajdonosa és üzemeltetője másik megoldást kér, akkor keresünk másik megoldást. De addig én biztosan nem fogom szorgalmazni ezt.

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

Ez nem egyszerűen "plusz egy lekérést" jelent, hanem oldallekérésenként plusz egy lekérést, tkp. megduplázod az oldal HTTP query forgalmát. Hány oldallekérés van a hupon naponta? Biztos nem kevés. Ez nem arról szól, hogy a látogatónak "nem fér bele plusz egy lekérés", ennek a szerver és a sávszél sem örül. Az pedig, hogy írjam meg általánosan, az nem specifikáció. Jó lenne tudni pl. hogy hogy lesz meghívva a kiegészítés. Nagyon szívesen beleásom magam és adok egy interface pointot, ha tudom, hogy hogyan fog csatlakozni a cacheing a backendhez és mit fog átadni.
Oldschool Computer - http://oscomp.hu

Arra próbált nevergone utalni, hogy oké, hogy lehetne egyénileg fejleszteni valamit, de nem szeretnénk eltérni a Drupal közösség által karbantartott dolgoktól. Tehát, ha van valami, ami bekerül a hivatalos Drupal kódbázisba, vagy hivatalos és karbantartott modulja lesz, azt meg lehet fontolni. De saját fejlesztés a hivatalos forrásfán kívül vagy egyén által fejlesztett kód használata nem célravezető.

Én régóta ezt az elvet vallom, szoptam én eleget olyan dolgokkal, aminek egyszer csak megszűnt a fejlesztése, a fejlesztő eltűnt, se biztonsági követése, se semmi nem volt.

trey @ gépház

Én ezt értem, csak így nem tudom hova tenni a "küldj patchet" felhívást, amikor valaki valaminek a hiányát, vagy feleslegességét reklamálja az oldalon. Hova küldjön patchet a delikvens? A Drupal kódbázisba? Szerinted mennyi eséllyel merge-elnek valamit, ha beküldöm, hogy "általános interface point viewcount inkrementálásra"? És nem is arról van szó, hogy a látogatók szívják meg főként. Aki akarja, egy mozdulattal tiltja a JS-t és nem fogja zavarni, ha nem látja a hup; a ti szervereteket terhelik ezek a felesleges kérések.
Oldschool Computer - http://oscomp.hu

Én ezt értem, csak így nem tudom hova tenni a "küldj patchet" felhívást

Az általunk kedvelt nyílt forráskódú világban azért ez nem ördögtől való ...

Hova küldjön patchet a delikvens? A Drupal kódbázisba?

Például. 

Szerinted mennyi eséllyel merge-elnek valamit, ha beküldöm, hogy "általános interface point viewcount inkrementálásra"?

Nem tudom, mert nekem ez kínaiul van. Ebből kifolyólag nekem bizonygathatod, hogy milyen jó lenne, nem tudnám szakmailag megítélni. Ezért vannak az ilyen projekteknél a karbantartók, akik fel tudják mérni. Arról, hogy miért nem célszerű forkolni a hivatalos kódot, már feljebb írtam.

trey @ gépház

Tegyük fel, hogy megírom és beküldöm. Ehhez még mindig tudnom kéne, hogy itt milyen cacheing megoldás van, hogy tudjam hozzá illeszteni. Egy "általános" megoldás kb. kimerül egy DB kapcsolódásban és egy aszinkron kérésben, ill. ha az URL-ből kell kihámozni a content ID-t, akkor még annyi. De hogyan fogja ezt bármi meghívni?
Oldschool Computer - http://oscomp.hu
Szó szerint azt kérdezted, hogy mi van, ha el se jut a Drupalig a kérés, külső cacheingre hivatkoztál, felsoroltál háromféle cacheinget, aztán meg általános megközelítésről beszéltél...pontosan azt a látszatot keltetted egész végig, hogy itt valami Drupal-independent cacheing megoldás van alkalmazva.
Oldschool Computer - http://oscomp.hu

Innen olvass megint újra: https://hup.hu/comment/2405739#comment-2405739


Arról én nem tehetek, hogy félreértelmezted. Leírtam, hogy általános, HUP-tól független megoldás kell, ami minden Drupal 8-al működik. Te jöttél hozzáféréssel, meg „mi fogja meghívni”, meg „adsz egy PHP-t” stb.

Persze, ha netán megírod, az sem garantálja, hogy használni fogjuk, de ezt is leírtam korábban és az okait is trey-jel együtt.

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

Akkor még egyszer: - Először azt kérdezted, hogy "Akkor is látnia kellene a szervernek, ha a kérés el sem jut hozzá, mert egy külső gyorsítótár szolgálja ki a kérést?" - Aztán a Varnishra, az NGinx cacheingre és a Drupal Boostra hivatkoztál. - Aztán megint azt mondtad, hogy "közel sem biztos az, hogy a kérés eljut a Drupalig." - Utána pedig végig ragaszkodtál az "általánossághoz", konkrét válasz nélkül, mostanáig. Ezt nem én értettem félre, hanem te vezettél félre. > Persze, ha netán megírod, az sem garantálja, hogy használni fogjuk, de ezt is leírtam korábban és az okait is trey-jel együtt. Akkor sem, ha a Drupal project beolvasztja? Akkor minek csináljam?
Oldschool Computer - http://oscomp.hu

Szinte biztos, hogy a Drupal projekt nem fogja beolvasztani, ezért kell a teljes, külső modul. A válaszaim pedig végig egy HUP-tól független, általános helyzetről szóltak, mivel egy HUP-specifikus megoldás senkinek sem áll érdekében. De ezt is leírtuk fentebb trey-jel.

Azért írtam a Varnish-t, Nginx-et, Boost modult, hogy szemléltessem neked: nem minden esetben jut el az oldalkérés a Drupalig, de a Javascript akkor is lefut. Sehol nem írtam, hogy mi ezek közül akár bármelyiket is használnánk jelenleg, bár ez nem zárja ki a jövőbeli használhatóságukat.

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

> legyen az "általános, teljes külső modul"

Valamit megint félreértettél. Az általános külső modul egy sima contrib Drupal modul, amit a Drupal Core sosem fog beolvasztani, hiszen ez külső, tőle független módon létrejött - és remélhetőleg karbantartott - modul, a Core-hoz semmi köze, a Drupal team pedig maximum security oldalról nézi majd a modult, meg szól, ha már nagyon outdated vagy, de amúgy that's all. 

Az oldalban való felhasználáshoz meg szerintem kellene valami biztosíték, hogy ezt te karban is fogod tartani, meg figyelsz az issue requestekre, akkor talán Nevergone-ék is megfontolják az oldalban való felhasználást. De pusztán attól, hogy egy HUP tag csinálta, nem fogják berakni az oldalba, még ha nagyon szépen is kéred. Ezt az oldalt rajtad kívül nézik párezren, emiatt nagyon jó lenne, ha a stabilitása szabad szemmel is jól láthatóan jobb lenne, mint mondjuk a játszótéri libikókáé. Pont ezért nem talált nyitott fülekre az, hogy "küldök egy PHP-t", a problémáknak ilyen jellegű megoldása már vagy 10+ éve kiment a divatból, és senki nem várja vissza. Nézd át kérlek, hogy működik mostanában a Drupal community és a Drupalhoz történő fejlesztés, és probálj meg az alapján működni te is. Akkor sokkal jobb helyzetből beszélgethetsz az oldal fejlesztőivel erről a kérdéskörről.

Nem bántani akarlak, de ha izomból és dühből kommunikálsz, anélkül, hogy megpróbálnád megérteni a túloldalt, azzal csak saját magadnak ártasz.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

> Nem bántani akarlak, de ha izomból és dühből kommunikálsz, anélkül, hogy megpróbálnád megérteni a túloldalt, azzal csak saját magadnak ártasz. Szerintem te itt valamit nagyon benéztél. Én végig konstruktívan álltam hozzá, nem szóltam be egyszer sem. Idézd be, hogy szerinted mi volt itt dühből, meg izomból történő kommunikáció.
Oldschool Computer - http://oscomp.hu

> Általánosságban meg nem lehet megvalósítani semmit.

Dehogynem. A probléma, amit leírsz, általános, több mint valószínű, hogy nem csak a HUP-ot érinti. Erre kell egy általános megoldást adni. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Azért ez már kezd egy kicsit sok lenni. Én nem csinálok semmiféle hangulatot. Azok közé az emberek közé tartozom, akik nem csak beszóltak, vagy nem csak benyaltak, hanem próbáltak konstruktívan hozzáállni. Érdemi választ szinte egyszer sem kaptam, terelést, mellébeszélést, azt annál többet. Így semmi értelme az egésznek. Amit meg mt9-cel írtunk, az általánosságban is áll, JS-sel nem lehet normálisan kiszűrni a botokat.
Oldschool Computer - http://oscomp.hu

Oké, ezt a kört akkor engedjük el, jobb lesz mindenkinek. Kérlek ha ennyire fontos neked, akkor írd meg a modulodat és tedd közzé a drupal.org-on.
További szép estét!

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

Miután nagyjából 100%-ig biztos vagyok benne, hogy majd a saját kis eldugott vendégkönyvedbe fogsz majd derpegni azon, hogy biiiiztos megint provokálni akarlak, így sok értelmét nem látom a kérdés feltevésének, viszont most az egyszer azért érdekelne, hogy mit csinálsz ott, ahol még van egy 3rd party CDN (pl. cloudflare, aws cloudfront, akármi) van még a saját webszervered és a kliens között?

( neutrino v | 2019. 11. 14., cs – 10:41 )

" A cikkek olvasottságánál pedig nem veszi figyelembe azokat a kattintásokat, amelyeket olyan látogatók végeznek, akik explicite tiltják a JavaScript-et vagy bizonyos blocker böngésző-kiegészítőket használnak. "

Ez bizonyitott, vagy csak szeretnétek ezt hinni? Gondolok itt arra, hogy sima logban realizálódnak-e a találatok és csak a Drupal nem kapja el?

1904.04.08.
RIP Jákub.
neut @

Nem szeretnék hinni semmit, nem a templomban vagyunk. Tiltsd le a JavaScript-et a böngésződben. Keress egy cikket, amit már nem nagyon olvasnak, hogy más ne zavarjon be a tesztbe. Kattintsd le, figyeld a számlálót. Majd próbáld meg engedélyezett JavaScript-tel.

Növekszik, nem növekszik, mikor növekszik? Az eredményt majd oszd meg itt. Thx!

trey @ gépház

( persicsb | 2019. 11. 18., h – 15:27 )

Így, hogy nem valósak a Drupal viewcountok, mennyiben változik meg a HUP értékesíthetősége? Hiszen a reklámozók számára kellenének a valós forgalmi adatok, hogy tudják, mennyit ér a HUP. A HWSW-t tájékoztattátok, hogy mostantól kezdve nincsenek a valósággal jól korreláló látogatottsági statisztikák?

Így, hogy nem valósak a Drupal viewcountok, mennyiben változik meg a HUP értékesíthetősége?

Szerintem semennyire. A GA mérései a mérvadók. Ezek a számlálók max. nekem adnak visszajelzést.

Hiszen a reklámozók számára kellenének a valós forgalmi adatok, hogy tudják, mennyit ér a HUP.

Független méréseket illik adni. Lásd: Google Analytics.

A HWSW-t tájékoztattátok, hogy mostantól kezdve nincsenek a valósággal jól korreláló látogatottsági statisztikák?

A HWSW-nek semmi köze hozzá, akinek van, az pedig tud róla. 

trey @ gépház