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?
  • Data: 2015-07-29 12:44:08
    Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
    Od: Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    W dniu 2015-07-29 12:35, M.M. pisze:
    > On Wednesday, July 29, 2015 at 12:10:56 PM UTC+2, Piotr Chamera wrote:
    >> a "ekstremalna sytuacja", to rzeczywisty efekt działania takiego
    >> nieprzemyślanego systemu, który obserwowaliśmy w praktyce podczas
    >> wyborów.
    > Rozmawiamy o jednym elemencie tego systemu: zbieranie danych.
    >
    >>> Zaczęli projektować i skopali, jakby po prostu zrobili
    >>
    >> to nie jest proste (albo może precyzyjniej byłoby powiedzieć, że to nie
    >> jest wielki system [czyli w pewnym sensie prosty], ale jednak kilka
    >> rzeczy wymaga przemyślenia i zaprojektowania).
    > Jak pisałem kilka postów wcześniej: nie dziwię się że padło jako
    > całość. Dziwię się, że stracili dane, że trzeba było wprowadzać od
    > nowa, że czekali aż tak długo... i nie wiem jakie tam jeszcze były problemy.
    >
    >>
    >>> 1) połączenie
    >>
    >> obsługujemy tylko jedno połączenie jednocześnie? czy więcej? jeśli
    >> więcej, to ile? wszystkie 2500 jednocześnie (bo tak też może się
    >> zdarzyć)? jeśli jedno, to co jeśli klient się połączył i nie przesyła
    >> danych, a inni czekają? jeśli pula połączeń jest ograniczona, to co
    >> robimy z nadmiarowymi? itd...
    > Co masz na myśli, pisząc 'itd'? Nie znam specyfikacji tegoż systemu.
    > Uczepiłem się tych 2500 paczek danych na 3600 sekund, co nie wydaje się
    > zbytnio trudne. Jaki średni rozmiar miała paczka? Jeśli mamy ograniczoną
    > pulę połączeń, to co jest złego w odrzuceniu?

    Nie paczek danych a połączeń, to jakby co innego. Paczki danych to jakby
    najmniejszy składnik całości, kwestia jest przyjąć właśnie te połączenia
    i obsłużyć, a nie ile danych trzeba przesłać.


    >> na dalszych etapach masz podobne wybory, które wpływają na przyjęte
    >> rozwiązania i musisz wybrać tak, aby żadna sekwencja możliwych zdarzeń
    >> nie prowadziła do awarii...
    > Zgodzę się, że zgranie każdego, w pobieżnej ocenie 'łatwego', systemu w
    > jedną niezawodną całość, może okazać się bardzo trudne. Ale żeby padło na
    > etapie zbierania danych i straciło spójność, jakoś wydaje mi się dziwne.

    A oprogramowywałeś jakieś większe bazy danych? Coś co musi trzymać
    spójność i dane dla bezpieczeństwa powinny być w kilku tabelach
    zapisane? Coś do czego dobija się więcej osób jednocześnie?


    --
    Kaczus
    http://kaczus.cba.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: