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-31 13:23:41
    Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
    Od: szemrany <s...@o...off> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On Fri, 31 Jul 2015 00:07:47 +0000 (UTC), Pit wrote:

    > Nadal to nie jest za darmo, a że nie Ty za to płacisz, tylko inni (na
    > przykład użytkownicy premium, albo muzycy chcący się wypromować czy

    Dżizas... co trzeba mieć za blokadę w głowie, żeby przez sekundę ponyśleć,
    że gdy piszę "za darmo" to mam na myśli koszt utrzymania! Chłopie, ogarnij
    się. Oczywiście, że piszę o cenie końcowej a nie o kosztach wytworzenia i
    utrzymania, to truizm. Nawet przejście 3 kroków generuje koszty
    energetyczne, więc... nie zaniżaj poziomu dyskusji :-P

    >> Dlaczego niby "każda zmiana dokonana przez każdego ze 100 członków zespołu
    >> była automatycznie dystrybuowana do wszystkich pozostałych"? Skoro
    >> "programiści to banki" to po cholerę bank X ma znać historię operacji
    >> wszystkich pozostałych banków?
    >
    > Przecież napisałem, o różnicach - nie ogarniasz więceju niż jednego zdania
    > na raz?

    Możesz bronić się teraz wymyślając ad hoc inne wersje wydarzeń, ale
    trzymajmy się faktów, Twoja analogia była trafiona jak porównanie kapusty
    do piłki koszykowej tylko dlatego, że obie okrągłe.

    >>> Różnica w zapotrzebowaniu na moc obliczeniową jest spora.
    >>
    >> W nietrafionej analogii...tak.
    >
    > W trafionej, tylko jej nie rozumiesz.

    Uhm... nie tylko ja. Ile jeszcze osób musi Ci napisać, że coś w niej nie
    tak, żebyś się pochylił i znalazł lepszą?

    >> Teraz wyobraź sobie sytuacje rzeczywistą, że jest 100 banków i KIR. Każdy z
    >> banków ma swój serwer REST oraz KIR ma swój serwer REST z bazą operacji
    >> wszystkich banków. W banku numer 45 klient wykonuje przelew do banku 56.
    >> Klika "Wykonaj". Serwer banku 45 wysyła requesta do serwera KIR i mówi mu:
    >> "bank 45 rachunek AAA przelew do banku 56 rachunek BBB, kwota X". Serwer
    >> KIRu zapisuje to do bazy prostym INSERTEM i wykonuje requesta do serwera
    >> banku 56 o takiej samej treści jaką przed chwilą otrzymał. Bank 56 zapisuje
    >> to do bazy i wykonuje requesta do serwera KIR: "OK, potwierdzam zapis".
    >> Serwer KIR zapisuje w bazie, w rekordzie, który poprzednio zainsertował
    >> status: "Potwierdzono" i wysyła requesta do serwera banku 45: "Wykonano".
    >> Bank 45 zapisuje do bazy przy wykonanym przelewie: "Potwierdzono'. Koniec.
    >> Liczby:
    >> - cztery lekkie requesty RESTowe
    >> - 3 inserty i 3 updaty w SQLu
    >>
    >> To oczywiście pewne uproszczenie, ale tak to może działać.
    >
    > Cytując Ciebie "w nietrafionym uproszczeniu... tak". Myślisz, że w takich
    > systemach najbardziej czasochłonne są inserty do bazy? Same cyfrowe podpisy
    > do tych requestów oraz ich weryfikowanie zajmuje znacznie więcej niż insert
    > do bazy, no ale pewnie i tak wiesz lepiej...

    Po pierwsze napisałem, że to wersja uproszczona. Po drugie weryfikacja może
    sobie trwać, to się nie musi odbywać w milisekundach i w real timie. Klient
    klika "Wykonaj" i robi swoje, a system w tle dopełnia reszty, może to
    zakolejkować i zrobić, gdy będzie miał zasoby.

    > Czy się nie da? Oczywiście że się da, w końcu Elixirem biega około 2
    > miliardy transakcji rocznie, czyli nic nadzwyczajnego, niecałe 7 milionów
    > transakcji dziennie uwzględniając tylko dni robocze, gdyby chodziło o samo
    > "insert into" to byłby to detal.

    To nadal jest detal. Jeśli sama obsługa komunikacji i baz to detal, a już
    obsługa uwierzytelniania i autoryzacji to kosmiczny wyczyn to ...cytując
    Ciebie... nie mam więcej pytań ;-)

    > Skoro się nabijasz, że w NBP (obsługującym SORBNET2) mają Odry, S/360 czy

    Ani słowem nie nabijałem się ze sprzętu w NBP, nie mam pojęcia co tam mają.

    > Bosman-8, to nie, w zeszłym roku mieli sprzęt klasy Delle PowerEdge R510 i
    > R710 oraz IBM-y x3650 i x3950 i w samym zeszłym roku dokupili co najmniej
    > 31 serwerów (po dwa procki 8-10 rdzeniowe każdy) - wiem, bo kumpel handluje
    > sprzętem i startował w przetargu zarówno na nowe serwery jak i na
    > serwisowanie już istniejących. Owszem, SPARC T5 (8 wątków na rdzeń co daje
    > 128 wątków na procesor) to to nie jest, ale "insert into" na mySQL-u
    > powinno uciągnąć, tylko byś musiał kilka godzin w weekend poświęcić i soft
    > napisać (to przecież banalne, trzy requesty na krzyż i gotowe, skrypt w
    > perlu czy pythonie trzaśniesz i będzie :D).

    Wyobraź sobie, że nie w weekend, ale na etacie "trzaskam" serwery RESTowe i
    zapieprzają aż miło. Mają też autoryzację i uwierzytelnianie, choć bez
    podpisów cyfrowych, nie ma takiej potrzeby. No i nie w Pythonie, ani innym
    języku skryptowym, są kompilowane do kodu natywnego maszyny.

    > Z mojej strony EOT. Uznajmy że Ty masz rację (a ja święty spokój) i
    > odwołuję wszystkie argumenty jakich użyłem w tym wątku.

    No uciekaj jeśli chcesz, a z racją jest jak z dupą... wiadomo.

    --
    howgh
    szemrany
    "Trzeba z żywymi naprzód iść, po życie sięgać nowe,
    a nie w uwiędłych laurów liść z uporem stroić głowę"

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: