[Techinfo] weboldal eleresi gond

Somogyi László somogyi at drgall.t-online.hu
2016. Nov. 29., K, 17:34:20 CET


Csatlakozva az előttem szóló Ádámhoz:
Az alkalmazást futtató szerver nem ad választ időben a webszervernek, az 
meg dob valamit a kliensnek, ez az 504. Egyébként más üzi lenne.
Ráadásul ezt az azonosításnál teszi, itt kell keresni valamit, ami ezt 
végzi.
Tehát a kapcsolat rendben, a webszerver kiadja a kezdőoldalt, feldobja 
az azonosítást, valószínűleg a webszerver meg is kapja a belépési 
adatokat, át is adja az adatbázis/alkalmazás szervernek, de az meg 
valamit várni kezd, de mit? Vagy másképp működik ez ott? Ha igen, hogyan?
Nyilván lehet benne, kell lennie benne valami specifikus internet 
szolgáltatói valami, ami megfekteti az alkalmazást, ezt innen nem látjuk.
De lehet még sok minden más is... hány tesztet tudtál végezni a rossz 
szolgáltatótól? (mire alapozol?)
Sőt azt sem látjuk, miféle a webszerver és miféle az alkalmazás szerver, 
kettő ez vagy egy, ha kettő, akkor köztük minden rendben?
vagy valami dokumentált/nem dokumentált szerver szoftver hibába fut bele 
a dolog a kiszolgálói oldalon?
én arrafelé is keresgélnék

A fentitől függetlenül:
Nem látom még teljesen bizonyítva az alkalmazás hibát.
Péter! Nincs lehetőséged  totál ugyanazzal a laptoppal tesztelni egy 
működő helyről és egy nem működőről?
Talán egy ethereal-lel végzett csomagvizsgálat mutatna különbséget, 
működő és nem működő helyek között, ha úgy is fennáll a helyzet, hogy 
tulajdonképpen mi jön meg, mi megy el?
Láttunk már olyat, hogy a TCP kapcsolat kiépül, handshake megvan, de 
útközben valami dobálja az értékes adatot tartalmazó csomagot, nem 
mindet, de túl sokat. Akkor is timeout lesz. Mindenki csak vár, aztán 
egyik megunja... hibaüzi.

Szokták javasolni, hogy DNS szervert kell váltani a kliensen. Mi lenne, 
ha egy olyan helyen, ahol nem működik jól, DNS-t váltanál a kliensen, 
mondjuk a sulinetesre. Azok régen elérhetőek voltak más szolgáltatótól 
is, kívülről, nem tudom most hogy van, de mindenképpen működő 
szolgáltató DNS-ére.
Tudom, ez nem oldja meg a problémát hosszútávon, de hibakeresésnek.

Huh, ez az  egyik legnehezebb hiba ám, azt tudod? :)

sl

2016.11.29. 16:12 keltezéssel, ka at mayten.sch.bme.hu írta:
> On 2016-11-29 14:13, Peter Molnar wrote:
>> Hello!
>>
>> Belso halorol belepes 1-2 masodperc
>> Sulinetes vonalrol 1-2 masodperc
>> Barhonnan 1-2 masodperc
>> Egyetlen 1 szolgaltatotol: 60 masodperc.
>> Csak a szolgaltato mas.
>> Nem tudok olyan webszerver beallitasrol, ami kiszurna 1 szolgaltatot,
>> s timeout-ra futna.
>> Eleg nehez tesztelnem, de a webszerver logjait debud-ra allitom,
>> hatha...
>>
>
> Szerintem rosszul kozelited meg a problemat.  Probalom maskepp 
> fogalmazni, mert ez nyersen hangzik, de oszinten ugy gondolom, hogy 
> nem jol allsz hozza.
>
> Ne azt vizsgald, hogy mi tortenik az elotet szerver es a kliens 
> kozott, azt nezd, mi tortenik az alkalmazasban.  Mint irtam nem 
> ismerem, de eltoltottem par evet olyan kornyezetben, ahol ilyen 
> jellegu hibakat vizsgaltam.  Ne egy kapcsolatra fokuszalj, hanem a 
> folyamat egeszere.
>
> Lehet, nincs igazam, orommel latnam, ha tenyekkel megcafolnal. 
> Szamtalan olyan alkalmazast lattam mar, ahol bizonyos konstellacio 
> eseten valami lassan, vagy nem mukodott.  Az alkalmazast vizsgald, 
> hogy az melyik lepesben mit csinal, ki kapcsolodik kihez, miert es 
> honnan kapja ezt az informaciot.
>
> Az gondolom egyertelmu, hogy az azonositast vegzi valami, majd utana 
> az adatot masvalaki szolgaltatja, legalabbis en a korabbi leveleidbol 
> igy ertelmeztem a leirtakat.  Azt kell megvizsgalnod, hogy ebben a 
> masodik lepesben mi milyen sorrendben tortenik. Siman elkepzelheto, 
> hogy valahol a hatterben peldaul tortenik egy nevfeloldas, naplozasi 
> cellal (pl. nem csak IP cimet de hostnevet is loggolni akar valaki).
>
> Mit ad isten, a leveledben korabban irt IP cim (a szolgaltatoe, tehat 
> nem az, amin a kliens latszik, tehat a 79.120.209.1) nem oldhato fel, 
> timeout-ra fut.  Lehet, hogy az a cim, amin a kliens latszodik, sem 
> oldhato fel (nem tudjuk, mert nem irtad meg mi az).  El tudom 
> kepzelni, hogy egy webalkalmazas, ami ragaszkodik a nevfeloldashoz, 
> kitartoan probalkozik es ez kesleltetest okoz.
>
> Halozati problema?  Nem.  Ez alkalmazas problema.  Specifikus egy 
> szolgaltatora nezve?  Igen.  Konnyu hibas kovetkeztetesre jutni, ha 
> csak egy pontot vizsgalsz, nem pedig az egesz folyamatot egeszben, 
> ezert irtam, hogy szerintem forditva ulsz a lovon, mivel meg mindig 
> webszerver beallitasrol es szuresrol beszelsz, szerintem ez komplexebb 
> ennel.  Nem halozati es nem OS beallitas, hanem alkalmazasi.
>
> Ebben a konkret esetben en nem latom a jelentoseget annak, hogy 
> barhonnan mashonnan jol mukodik.  Kit erdekel?  Azt kell vizsgalni, a 
> nem mukodo esetben mi zajlik a hatterben.
>
> udv
> adam
>
> _______________________________________________
> Techinfo mailing list
> Techinfo at lista.sulinet.hu
> Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo
> Illemtan: http://www.szag.hu/illemtan.html
> Ügyfélszolgálat FAQ: http://sulinet.niif.hu/
>



További információk a(z) Techinfo levelezőlistáról