eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programming[OT] Duża kasa i kiepski wynik - dlaczego?Re: [OT] Duża kasa i kiepski wynik - dlaczego?
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!newsfeed.fsmpi.
    rwth-aachen.de!newsfeed.straub-nv.de!feed.xsnews.nl!fbe002.ams.xsnews.nl!ecngs!
    feeder.ecngs.de!81.171.118.63.MISMATCH!peer03.fr7!news.highwinds-media.com!news
    feed.neostrada.pl!unt-exc-02.news.neostrada.pl!unt-spo-a-02.news.neostrada.pl!n
    ews.neostrada.pl.POSTED!not-for-mail
    Date: Wed, 29 Jul 2015 07:37:30 +0200
    From: Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl>
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.24) Gecko/20100228
    Thunderbird/2.0.0.24 Mnenhy/0.7.6.0
    MIME-Version: 1.0
    Newsgroups: pl.comp.programming
    Subject: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
    References: <mosvh7$bpl$1@node1.news.atman.pl>
    <55b21285$0$27508$65785112@news.neostrada.pl>
    <mot44o$gd5$1@node1.news.atman.pl>
    <55b2155e$0$27524$65785112@news.neostrada.pl>
    <X...@1...0.0.1>
    <55b71c91$0$2196$65785112@news.neostrada.pl>
    <X...@1...0.0.1>
    In-Reply-To: <X...@1...0.0.1>
    Content-Type: text/plain; charset=ISO-8859-2; format=flowed
    Content-Transfer-Encoding: 8bit
    Lines: 62
    Message-ID: <55b8669a$0$27509$65785112@news.neostrada.pl>
    Organization: Telekomunikacja Polska
    NNTP-Posting-Host: 79.187.17.90
    X-Trace: 1438148250 unt-rea-a-02.news.neostrada.pl 27509 79.187.17.90:44597
    X-Complaints-To: a...@n...neostrada.pl
    X-Received-Bytes: 4197
    X-Received-Body-CRC: 1854097201
    Xref: news-archive.icm.edu.pl pl.comp.programming:207928
    [ ukryj nagłówki ]

    W dniu 2015-07-28 17:00, Budzik pisze:
    >>> Wysłanie protokołów z komisji wyborczych (mało danych, stosunkowo
    >>> mało zapytań) to jest jakieś poważne obciążenie?
    >>> Hmm...
    >>
    >> 1) zależy jak to zaprojektowano
    >
    > No to trzeba dobrze zaprojektowac - sugerujesz ze wysyłano pliki bmp
    > zamiast spakowanego tekstu?

    Nie nie to co wysyłano, tylko jak zaprojektowano to wewnątrz- sorki,
    robiłeś cos większego niż jakieś strony na mysql-u?

    >> 2) tak - bo wszystko jak napisałem odbywa się w tym samym czasie-
    >> większość komisji wysyła w tym samym czasie - masz takiego ddosa. I
    >> tego nie przewidziano.
    >
    > Ale to i tak nie jest duzy ruch.
    > Poza tym nie przesadzajmy ze w tym samym czasie - moze w ciagu 2-3 godzin
    > ale to dla komputerów nie jest przeciez ten sam czas.

    Chyba nie pracowałeś w komisji - ok 80-90% komisji będzie próbowało
    połączyć się w tej samej godzinie. Mamy ok 3tys komisji (z tego co
    pamiętam) wiec trzeba spodziewać się ok 2.5 tysiąca requestów, najpierw
    prostsza rzecz, czyli identyfikacja i logowanie certyfikatem, później
    przesłanie danych, ich walidacja i zapis do bazy - wszystkich razem oraz
    zwrócenie informacji. Wszystko wygląda prosto i jest do zrobienia, ale
    jak sobie policzysz czas na obsłużenie większości zapytań, to wiesz
    czemu były problemy z połączeniem się. Źle zaprojektowano zapis danych -
    przez co się rozjechały, a może zrobiono to właśnie jakiś geniusz użył
    do tego mysql-a z transakcjami nie do końca dobrze działającymi. Albo w
    ogóle o tym nie pomyślał. Albo zaprojektował to tak, że się
    zakleszczyły? Z łączenia 2 systemów działających na tej samej bazie,
    które musiały mieć jedną tabelę wspólna, a jednocześnie pracujące na
    innych rodzajach transakcji pamiętam, że można było takie coś nawet
    działające w laboratorium mieć, jednak, gdy testowaliśmy to w
    rzeczywistości, okazało się, że wpływ miało też jakość połączenia, które
    mogło dłużej jakiś zasób przetrzymać i nie nie musiały być wysyłane duże
    dane. I przy dużo mniejszym obciążeniu niz w warunkach laboratoryjnych
    system się wywalał.

    >
    >> I nie nie tylko jest potrzebna szybka obsługa zapytania, ale i problem
    >> zachowania spójności - bo o ile - można przyciąć łącze i odrzucić
    >> niektóre zapytania, to w tym wypadku geniusze nie zadbali o spójność
    >> danych i te które zeszły częściowo zniszczyły cala resztę. Sorki, ale
    >> ten kto to projektował nie miał pojęcia o bazach danych większego niż
    >> proste strony www.
    >>
    > Ok, to wszystko kwestia złego oprogramowania.
    > Ale wczesniej pisałes, ze tu była potrzebna baza do duzych obciazen.
    > Wiec ponawiam pytanie: jakie duze obciazenia, skoro sam piszesz, ze
    > problemem było złe oprogramowanie a nie brak wydajnosci bazy.

    Jeśli źle zaprojektowano bazę, to właśnie nie wytrzymała obciążenia i
    dodatkowo nie potrafiła sobie poradzić z sytuacją ekstremalną i dane
    były niespójne.


    --
    Kaczus
    http://kaczus.ppa.pl

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: