Pokiaľ otváram MR u skorosvokry, kde mám slabší net, tak sa neviem dopracovať k posledným správam pri dlhších vláknach a ani pridať nový príspevok - načítanie stránky sa preruší a vidím len časť.

Ak s týmto problémom nie som sám, možno by stačilo zvýšiť timeout v php.ini. Stránka by sa síce načítavala aj tak dlho, ale mal by som šancu vidieť všetky príspevky.

Varianta B: možnosť nastaviť max. počet správ na stránku.

Mne to tiez robi pri slabom internete.

Plus uz dobrych par mesiacov rano medzi 7 - 8 je stranka najprv dole, potom bez obsahu, potom uz len bez diskusiiii.... niekde medzi tym chybaju sukromne spravy. Ak je to mejaka pravidelna naplanovana udrzba, restart(databazy).... nedalo by sa to naplanovat naprikla na rano medz 3. a 4.?

Tiez mam tento problem. NIekedy nenatiahne diskusiu do konca, tiez mi nacita napr. len 1/4 obrazku atd. Mozem refreshovat do nekonecna, aj tak nic.

U mna tiez, ale pomaha byt trpezlivy, ako pri zenach.
Neposuvam stranku az do uplneho nacitania + 3 sekundy este navrch.

50 prispevkov na stranku by tiez asi nebolo na skodu.

o tomto probléme som písal Awia ovi maily už dávno... poslal som mu aj print screen... ale nereagoval...

Dobré ráno, u mňa to isté a stáva sa to aj pri dobrom nete.

Príjemné prežitie vianoc,

apa

Ja mam problémy aj s obrázkami v článkoch, niekedy mi ich zobrazuje v nereálnych farbách ako sepia.

To nie je slabším netom , to je tým , že o túto stránku sa ľudia proste trhajú
Počet návštevníkov Včera: 182389

Voľakedy , keď niekto tvrdil nejakú nepravdu/lož ,. tak sa mu vyčítavo povedalo : Takto klamať , že ťa huba nebolí .
Tu by sa to dalo napríklad ohľadne tých klamstiev o počte návštevníkov tiež .

Voľakedy sa motoride na sviatky zamkýnal , aby sa ľudia aspoň cez Vianoce nevadili ...
už to zamkýnať netreba , veď na túto stránku už ľudia totálne kašlú , dlhodobá práca sa proste prejavila a v kontexte s tým je údaj o počte návštevníkov stránky už nie len malá lož , ale 100-násobná lož .

janoval , spomínal som tento tvoj poznatok už asi pred rokom aj pol , odpovede od tých pár členov , čo sem ešte sem tam prispievajú , zneli asi v tom zmysle , že si asi vymýšľam a že som asi ch.j a že vlastne trepem , tak neviem , či nie aj ty .

No , predstavme si modelovú situáciu , človek príde na siedmu do práce , zapne si net a prečíta , čo je na MR nové , ibaže ... táto cárašina práve v tom najexponovanejšom čase od cca 7,15 do cca 7,50 nefunguje , tak čo spraví občan ?
Začne študovať novinky a správy na iných serveroch a na tento už jednoducho je.e ... potom sa zjaví to klamstvo , že
Včera: 182389

A aby tu bol v niektorých diskusiách aspoň jeden prípevok , musí si ich Awia písať sám , aspoň sa falšuje , že to tu žije .

R.I.P. Motoride .

Re: brazel: netrep su vanoc3 tak by si aspon dnes nemusel... Pocitadlo dole je real pageviews, je tu od vzniku webu, komu sa nezda googel analytics... Dristas ze az... Tvojimi slovami: Ze ta huba neboli

A k teme, na slabom nete sa i mne stalo, sekne to volade... Dať 50 prispevkov na stranu, riesenie je aj zotriedenia fora od najnovsich..

awia mne sa uz 2x stalo ze mi nezobralo cely prispevok ale iba jeho cast a zvysok skratka useklo...

Re: HoGo80: to bude karma, asi by si nemal tak casto chodit ku svokre. Za to MR nemoze

5 príspevkov či 50, výsledok býva ten istý.

Re: imoto: je to presne ako píšeš.... možno by pomohlo radiť príspevky naopak... že na vrchu budú najnovšie...

Re: Campo: Zmenis to sám jediným kliknutím.... je to problém?

Re: Awia: to o com hovori on, sa mne bezne stava napr. aj pri nacitani titulky skrz VPNku z firmy, sem-tam sa nedonacitava nejake dlhsie forum a sem-tam mi pri citani clanku nenacita cely obrazok. tym sem-tam nemyslim, ze som to videl raz, alebo 2x. stava sa to pomerne pravidelne. neviem, kde to mate hostovane, ako to mate nastavene, ale predpokladam, ze MR backend vyzera tak isto, ako MR frontend - ze je hoooodne zastaraly.

kedze sa mi (pomerne dost casto) nacita iba cast stranky cca po zoznam clankov, predpokladam, ze za tych +- 14 rokov uz databazy nabobtnali natolko, ze bud timeoutuju SQL requesty do databazy, alebo timeoutuje http server pri skladani layoutu dohromady (alebo raz to a raz to). kazdopadne bude moj skromny tip (a asi nebude daleko od pravdy), ze SQL requesty sa robia pomedzi generovanie layoutu a nie na zaciatku, pred tym, nez je vobec vygenerovany prvy byte odpovede.

worst case scenario by bolo, ze po kazdom SQL requeste zavrete spojenie na databazu a pred dalsim requestom ho znova otvorite (bez prdele, toto som uz pri jednom nie uplne neznamom webe videl). taketo chovanie sa databazam moc nepaci a potom zvyknu spojenia bud dropovat, alebo vkladat latencie.

----
co sa tyka riesenia formou zotriedenia opacne. je to skaredy hnusny workaround. ak aplikacia pravidelne zlyhava pri generovani obsahu bolo by podla mna na zamyslenie taku aplikaciu opravit.
----
nechcem, aby toto vyznelo ako negativne zabrdanie. sam som taketo velke aplikacie uz spravoval a viem, ze niekedy sa s nimi bez pouzitia trhaviny a velkej spotreby casu pohnut neda. je mi jasne, ze redakcia MR nema vsetkych clenov znalych designu webovych aplikacii a ze tvorenie obsahu ma proste prioritu.

ventYl, ak si spravoval, tak vieš, že sql timeoutom to nebude, keď sa to deje len pri pomalom nete na strane klienta. Jedná sa o generovanie layoutu - timeout v PHP. Klient si nestihne stiahnuť všetok obsah a server side php sa na to po čase vybodne.

Re: HoGo80:
1. vidis to moc ciernobielo. transportny layer ma (pomerne dost velke) buffre, takze tak velka zavislost na tom, ci si klient vystup zoberie, alebo nie, nie je. v praxi byva skor problem nechat PHP blokovat na tom, ci si klient data prevzal, alebo nie, nez naopak.

2. ako obvykle riesime tu nepodstatnu volovinu ;) ci to skape na SQL timeoute, PHP timeoute, alebo zle riesene SQL sposobi PHP timeout je jedno. proste mnozstvo dat tej aplikacii prerasta cez hlavu. a lepsie to nebude, pretoze dat bude len pribudat.

pekne vianoce

Re: Martins: nie, je to to isté....

Re: Campo: Nič v zlom, nechcel som byť drzí, dokonca som to chcel sám navrhnúť a v tom som zbadal hore,, zotried od najnovších... ''

Re: Martins: ja to neberiem v zlom.... len keď to preklikneš, udeje sa to isté.... zase to nenačíta.

Re: Awia: Mne to ináč tiež píše počet návštevníkov dnes 168617 takže číslu ktoré udal brazel by som veril.

Re: Campo: To som nevedel. Tak potom posledný nech zhasne.

Najnovšie príspevky v diskusiách:
Zobrazujem príspevky 1 až 30 z cekového počtu: .

Ľutujem nenašiel som žiadne príspevky...

už pravidelná hláška každé ráno..

Pocitadlo je na pocet zobrazeni stranky. Analytics robi taku vec, ze ak ma niekto cely den zapnutu jednu stranku, aj ked sa na nu nediva, iba ju ma proste otvorenu, tak ju refreshuje a tym sa nabaluje pocet zobrazeni webstranky. Aspon ja tak viem, opravte ma ak to tak nie je.

predpokladam, ze to pocitadlo dole, kedze je z doby, ked este analyticsy neexistovali, je prachsproste pocitadlo pageviews. tak sa to vtedy robilo. cize to, ze ja som si teraz toto forum precital a na teba reagoval, pridalo na tom pocitadle +2... takym sposobom naozaj ale fakt naozaj nie je problem spravit take cisla, ake to ukazuje. ci tie cisla su skutocne, alebo nie vam 1) neprinalezi hodnotit, pretoze prd viete, co meraju 2) moze byt fuk. ci tam bude 600, 6000 alebo 60000, sekat sa vo fore budete stale rovnako.

dalsia vec: mizerne sa mi to nacitava aj na antikackom 100 megabite a na relativne modernom dvojjadrovom pocitaci. cize by som pomalu masinu aj pomalu linku vylucil (ako tu niekto skusal navrhovat). vsimol som si, ze to pri nacitani z vytuhne bud na pocte ludi v MR chate (proste to tak 20 sekund trva, nez to vygrcne tu nulu), alebo to vymrzne (v pripade titulky) na vypluvnuti zoznamu clankov.

stranka sa potom donacita, takze PHP timeout to nebude. skor flaky databazova schema, alebo odflaknute kvery.

Dôvod úpravy: edit hore

Upravené 1 krát. Naposledy upravil ventYl (04.01.2016 9:18)