W dniu 2015-07-29 o 10:19, M.M. pisze:
> On Wednesday, July 29, 2015 at 9:54:06 AM UTC+2, Piotr Chamera
> wrote:
>> W dniu 2015-07-29 o 09:42, M.M. pisze:
>>> On Wednesday, July 29, 2015 at 7:37:32 AM UTC+2, Tomasz
>>> Kaczanowski wrote:
>>>> 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.
>>> Ale po kiego tutaj jakoś szczególnie projektować? Nie było
>>> żadnej ekstremalnej sytuacji.
>>
>> Tak "pomyśleli", nie zaprojektowali i mieliśmy "ekstremalną
>> sytuację"...
> Przez 1s można trochę danych i siecią przesłać, i na dysku zapisać,
> nie wspomniawszy o zapisach w buforach RAM. Zapytań było 2500. Czas
> ktoś oszacował na 1h. Średnio wychodzi jedno zapytanie na 1s. Gdzie
> widzisz ekstremalną sytuację?

moje ,,pomyśleli", to np. twoje ,,Przez 1s można trochę danych i siecią
przesłać, i na dysku zapisać, nie wspomniawszy o zapisach w buforach
RAM. Zapytań było 2500. Czas ktoś oszacował na 1h. Średnio wychodzi
jedno zapytanie na 1s." więc robimy na pałę...

a ,,ekstremalna sytuacja", to rzeczywisty efekt działania takiego
nieprzemyślanego systemu, który obserwowaliśmy w praktyce podczas
wyborów.

> 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).

> 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...

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...