🚀 go-pugleaf

On Sat, 28 Jan 2012 22:30:01 -0000, homar <marek.horodyski@gmail.com>  
wrote:

>> Connection: Keep-Alive
>> Keep-Alive: timeout=3600, max=1000
>
> O, to już coś, na pewno to wypróbuję ( to. Keep-Alive: timeout=3600,
> max=1000 w parze z podtrzymanym connection). Nie boli mnie to, że za
> szybko przeglądarka konczy polaczenie, ale to, że przy kolejnym
> wywolaniu po stronie serwea jest nowy socket. W slad za tym otwieram
> watek, a stary watek jest otwarty i ma przygotowaną odpowiedż na
> zapytanie do bazy. Teraz przesylam cale zapytania w postaci (nieraz)
> duzych tabel, a chcialbym wprowadzić stronicowane odpowiedzi po
> kilkadziesiat rekordów. Baza to Oracle, który nie wspiera tego tak jak
> np. MySql.

ZTCW w Oraclu robi się stronicowanie przez ROWNUM/ROWID. Jeżeli tego nie  
potrafi zoptymalizować jak MySQL, to może zrób upgrade do MySQL? ;) [albo  
lepiej Postgresql]


Ale pamiętaj, że w HTTP nie masz *żadnych* gwarancji, że klient (który  
może nawet nie być przeglądarką) ponownie użyje to samo połączenie. HTTP  
bazuje na zapytaniach, a nie na połączeniach. Utrzymywanie połączeń to  
tylko zupełnie opcjonalny detal optymalizacyjny. Podobnie jak samo IP jest  
oparte na pakietach, a nie połączeniach (odwrotnie niż np. BBS) i nie masz  
gwarancji jaką trasą pakiety przyjdą (mogą i gołębiami pocztowymi —  
http://www.ietf.org/rfc/rfc1149.txt).

Nie próbuj mieszać poziomów abstrakcji protokołów, bo z tego nie wyjdzie  
ci nic poza mizernymi i delikatnymi hackami. Będzie ci się wszystko ciągle  
sypało w zależności od rodzaju przeglądarki, prędkości połączenia i  
konfiguracji proxy po drodze.

Jeśli nie możesz współdzielić/przenosić danych między dowolną konfiguracją  
połączeń do serwera, to masz serwer do dupy i tyle. Naprawiaj serwer  
zamiast psuć HTTP — np. kosztowne zapytania wrzuca się w memcached i/lub  
sesje, a delikatne serwery/powolne aplikacje chroni się przez  
reverse/caching proxy jak Varnish.

-- 
regards, porneL