eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingjsp vs phpRe: jsp vs php
  • X-Received: by 10.49.72.130 with SMTP id d2mr971821qev.42.1368086161934; Thu, 09 May
    2013 00:56:01 -0700 (PDT)
    X-Received: by 10.49.72.130 with SMTP id d2mr971821qev.42.1368086161934; Thu, 09 May
    2013 00:56:01 -0700 (PDT)
    Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!news.cyf-kr.edu.pl!news.nask
    .pl!news.nask.org.pl!news.unit0.net!news.glorb.com!m7no3780488qam.0!news-out.go
    ogle.com!y6ni20871qax.0!nntp.google.com!m7no3780481qam.0!postnews.google.com!gl
    egroupsg2000goo.googlegroups.com!not-for-mail
    Newsgroups: pl.comp.programming
    Date: Thu, 9 May 2013 00:56:01 -0700 (PDT)
    In-Reply-To: <d...@g...com>
    Complaints-To: g...@g...com
    Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=5.184.56.176;
    posting-account=Sb6m8goAAABbWsBL7gouk3bfLsuxwMgN
    NNTP-Posting-Host: 5.184.56.176
    References: <c...@g...com>
    <d...@g...com>
    <e...@g...com>
    <51874eb2$0$1250$65785112@news.neostrada.pl>
    <6...@g...com>
    <kmau09$ju5$1@speranza.aioe.org>
    <8...@g...com>
    <kmbgce$ile$1@speranza.aioe.org>
    <e...@g...com>
    <51895d09$0$1252$65785112@news.neostrada.pl>
    <f...@g...com>
    <518a01b5$0$1212$65785112@news.neostrada.pl>
    <6...@g...com>
    <518a831d$0$26699$65785112@news.neostrada.pl>
    <6...@g...com>
    <518aa18a$0$26685$65785112@news.neostrada.pl>
    <1...@g...com>
    <518aa797$0$26697$65785112@news.neostrada.pl>
    <0...@g...com>
    <518ac39f$0$1222$65785112@news.neostrada.pl>
    <d...@g...com>
    User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <a...@g...com>
    Subject: Re: jsp vs php
    From: firr kenobi <p...@g...com>
    Injection-Date: Thu, 09 May 2013 07:56:01 +0000
    Content-Type: text/plain; charset=ISO-8859-2
    Content-Transfer-Encoding: quoted-printable
    Xref: news-archive.icm.edu.pl pl.comp.programming:203279
    [ ukryj nagłówki ]

    W dniu czwartek, 9 maja 2013 02:10:02 UTC+2 użytkownik M.M. napisał:
    > W dniu środa, 8 maja 2013 23:29:02 UTC+2 użytkownik R.e.m.e.K napisał:
    >
    >
    >
    > > Ciagle nie wiem skad bierzesz te 10 sekund. Po piewsze to zalezy od
    >
    > > komputera, jesli na Twoim lapku trwa to 10 sekund to na serwerze z
    >
    > > prawdziwego zdarzenia moze trwac 0,1 s.
    >
    >
    >
    > Sprawdzam na lapku i na stacjonarnym, oba kompy sa dosc nowe, ale
    >
    > na pewno nie sa to serwery z prawdziwego zdarzenia. Czasami na lapku
    >
    > dziala szybciej. Domniemam ze wynika to z ulozenia danych w tabelach.
    >
    > Jesli na lapku dane sa obok siebie, to zapytanie bedzie dzialalo
    >
    > szybciej niz nawet na serwerze z prawdziwego zdarzenia - zaraz ktos mi
    >
    > zarzuci ze pisze oczywiste rzeczy :D
    >
    >
    >
    > Czy da sie z 10s zejsc do 0.1s tylko dzieki:
    >
    > 1) lepszej konfiguracji (np. indeksy, buforowanie w RAM)
    >
    > 2) zastosowaniu lepszego sprzetu
    >
    > 3) zastosowaniu wiekszej ilosci komputerow?
    >
    >
    >
    > AD1) powiedzmy ze indeksy juz mam dobre, a buforow RAM nie bede zwiekszal,
    >
    > bo w koncu i tak i tak zabraknie.
    >
    > AD2) nie mam pod reka dyskow SSD zeby sprawdzic.
    >
    > AD3) nie wiem jak sie zachowuje postgres uruchomiony na klastrze,
    >
    > zdaje sie ze jest taka mozliwosc, ale nigdy nie korzystalem z niej.
    >
    >
    >
    > > Po drugie jakie to zapytania sa?
    >
    >
    >
    > W pierszym lepszym zapytaniu slowo JOIN mam 11 razy. Docelowe
    >
    > rozmiary czterech najwieksych tabel z tego zapytania szacuje
    >
    > mniej/wiecej tak: 1mln, 10mln, 100mln i 1mld rekordow. Obecne
    >
    > rozmiary 135543, 135543, 12578310, 20573317. Pozostale tabele sa raczej
    >
    > male, do 50tys rekordow, raczej zmieszcza sie w boforze RAM.
    >
    > Kazda duza tabela jest laczona joinem tylko jeden raz. Jedna
    >
    > mala table wystepuje w zapytaniu dwa razy - ale to bez znaczenia.
    >
    >
    >
    > W tym zapytaniu wszystkie zlaczenia sa po klucz_glowy==klucz_obcy.
    >
    > Wszystkie klucze to biginty. W klazuli where jest:
    >
    > tabel1.klucz_glowy = stala_1 AND tabela2.klucz_glowny = stala_2;
    >
    >
    >
    > Zapytanie nie ma sortowania, ani grupowania. Wynikiem zapytania jest
    >
    > srednio 70tys rekordow.
    >
    >

    dla mnie jest to ciekawy watek, aczkolwiek
    nie znam sie na tym bo w praktyce nie zajmuje
    sie nie tylko bazami danych ale nawet
    nie bardzo pilkami (w temacie gier to ew
    straczy mi wiedza jak zbudowac plik .pak
    aby wczytanie danych bylo jak najszybsze)

    w kazdym razie mi wyglada to na problem
    z podsystemem cache miedzy bazą a programem
    (nie wiem na ile bazy taki cache obsluguja
    ale pewnie chyba obslugują, zapewne mozna
    scacheowac sobie wynik zapytania automatycznie
    (do ramu albo na dysk) zamiast samemu

    pozatym mozna przemyslec jak wyglada przeplyw
    tych danych miedzy wielka bazą a programem
    (ile funkcjonuje rozmaitych wynikow zapytan i
    ile razy powtarza sie ktory z nich) idealna sytuacja
    gdy funkcjonuje malo i powtarzaja sie czesto
    i tak wykombinowac podsystem cache by wysoki
    procent tych zapytan trafial w cache

    da sie cos takiego zrobic w twoim wypadku?

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: