Dnia 2014-05-25 00:38, Użytkownik Marek napisał:

>> Danych.
>> W tym przypadku elementów jakiejś strony www.
>
>
> Jakoś tego doświadczenia nie podzielają autorzy np. ajaxa domyślnie
> ustawiając tryb przesyłania async, przeładuj dowolna stronę z ajaxem
> zawierającą kilka żądań i policz w ilu wątkach pójdą te żądania (i ile
> gniazd użyją).
>
Autorzy wielu przyśpieszaczy robią rzeczy świadczące o braku wiedzy
lub logiki. A tak naprawdę chodzi o napisanie czegoś na czym się
zarobi a nie na przyśpieszeniu komukolwiek czegokolwiek.
A tak z ciekawości sam sprawdziłeś. Napiszesz jaka była różnica
na jakiej stronie ina jakim łączu ?


Pozdrawiam

do góry

On Mon, 26 May 2014 18:06:11 +0200, RadoslawF <radoslawfl@spam_wp.pl>
wrote:
> A tak z ciekawości sam sprawdziłeś. Napiszesz jaka była różnica
> na jakiej stronie ina jakim łączu ?


Strona, która wymaga załadowania 10 parametrów (wartości liczbowe)
kontrolnych pewnego systemu w trybie async ładuje szybciej, w trybie
sync wolniej i wyraźnie wydać ładowanie pokolei zamiast efektu
załadowania "od razu". W tym przypadku nie ma wysycenia łącza ale
nawet zakładowanie kilkudziesięciu bajtów przez równolegle wątki i
połączenia jest szybsze niż w trybie async.

Test pobierania pliku 20MB po seci lokalnej 1GB (FreeBsd@2xamd64
1.7GHz)
Dwa procesy po kolei:

time -p sh -c 'wget -q   -O /dev/null 192.168.2.164/plik ; wget -q
-O /dev/null 192.168.2.164/plik '

real 0.51
user 0.04
sys 0.24

Dwa procesy równolegle:
time -p sh -c 'wget -q   -O /dev/null 192.168.2.164/plik & wget -q -O
/dev/null 192.168.2.164/plik '

real 0.37
user 0.02
sys 0.13

0.37 s vs. 0.51 s , równolegle wątki wyraźnie szybciej.

Dla równoległych 3 procesów daje czas pobierania 0.54s a po kolei
0.77 s.
Widać że FreeBSD całkiem liniowo się skaluje w smp :).

--
Marek

do góry

Dnia 2014-05-26 22:28, Użytkownik Marek napisał:
> On Mon, 26 May 2014 18:06:11 +0200, RadoslawF <radoslawfl@spam_wp.pl>
> wrote:
>> A tak z ciekawości sam sprawdziłeś. Napiszesz jaka była różnica
>> na jakiej stronie ina jakim łączu ?
>
>
> Strona, która wymaga załadowania 10 parametrów (wartości liczbowe)
> kontrolnych pewnego systemu w trybie async ładuje szybciej, w trybie
> sync wolniej i wyraźnie wydać ładowanie pokolei zamiast efektu
> załadowania "od razu". W tym przypadku nie ma wysycenia łącza ale nawet
> zakładowanie kilkudziesięciu bajtów przez równolegle wątki i połączenia
> jest szybsze niż w trybie async.
>
> Test pobierania pliku 20MB po seci lokalnej 1GB (FreeBsd@2xamd64 1.7GHz)
> Dwa procesy po kolei:
>
> time -p sh -c 'wget -q -O /dev/null 192.168.2.164/plik ; wget -q -O
> /dev/null 192.168.2.164/plik '
>
> real 0.51
> user 0.04
> sys 0.24
>
> Dwa procesy równolegle:
> time -p sh -c 'wget -q -O /dev/null 192.168.2.164/plik & wget -q -O
> /dev/null 192.168.2.164/plik '
>
> real 0.37
> user 0.02
> sys 0.13
> 0.37 s vs. 0.51 s , równolegle wątki wyraźnie szybciej.
>
> Dla równoległych 3 procesów daje czas pobierania 0.54s a po kolei 0.77 s.
> Widać że FreeBSD całkiem liniowo się skaluje w smp :).
>
Podsumowując wielowątkowe ściąganie jest wolniejsze od
jednowątkowego. Szybsze jest tylko dwu wątkowe. :-)


Pozdrawiam

do góry

On Tue, 27 May 2014 18:47:26 +0200, RadoslawF <radoslawfl@spam_wp.pl>
wrote:
> Podsumowując wielowątkowe ściąganie jest wolniejsze od
> jednowątkowego. Szybsze jest tylko dwu wątkowe. :-)

Nie wiem skąd taki wniosek, 3 równolegle procesy pobrały szybciej
(0.53s) niż 3 po kolei (0.77s). Gdyby testowana maszynka miała więcej
niż dwa rdzenie wynik byłby jeszcze lepszy. W tym przypadku wąskim
gardłem jest jedynie implenentacja fork/exec. W przypadku
przeglądarki i js, pobieranie sync po kolei jest jeszcze wolniejsze
bo wszystko się odbywa w interpreterze js, kolejne połączenie będzie
zestawione dopiero po zakończeniu poprzedniego. W przypadku
pobierania async (równoległego) poszczególne wątki nie muszą czekać
na zakończenie poprzedniej transmisji.

--
Marek

do góry

On 05/26/2014 10:28 PM, Marek wrote:
> Dwa procesy równolegle:
> time -p sh -c 'wget -q -O /dev/null 192.168.2.164/plik & wget -q -O
> /dev/null 192.168.2.164/plik '
>
> real 0.37
> user 0.02
> sys 0.13
> 0.37 s vs. 0.51 s , równolegle wątki wyraźnie szybciej.

Ale tak mierzysz tylko czas drugiego wgeta :-)

> Dla równoległych 3 procesów daje czas pobierania 0.54s a po kolei 0.77 s.

Wąskim gardłem w tym teście jest sieć, serwer po drugiej stronie lub za
mały plik i czas poświęcony na handshake+geta zanim dostanie się
prawdziwe dane, a nie system czy procesor. Przy takich testach procek
przestał być problemem w erze pentium I, a przy gigabicie w okolicach
Pentium III.
Co innego jak potrzebujesz coś policzyć. Ale wtedy żadne bsd nie pomoże
jak liczba wątków jest większa od liczby corów, a jeszcze gorzej jak
będą chciały mieszać dużo po wspólnym ramie w architekturze numa.

Akurat równoległe otwieranie socketów i czekanie na dane nie jest żadnym
obciążeniem i liczba cpu nie ma tu znaczenia.
Dopiero rendering tego co się dostanie wymaga cpu, ale tu przeglądarki
jakoś się nie skalują:-) Owszem, flasha odpali na drugim corze, sandboxy
też może porozrzucać, ale jak otwierasz tylko jedną stronę, to wiele Ci
nie da fefnaście corów.

> Widać że FreeBSD całkiem liniowo się skaluje w smp :).

Raczej widać, żeś fan FreeBSD.


Pozdrawiam

Marek
--
"If you want something done...do yourself!"
Jean-Baptiste Emmanuel Zorg

do góry

On Thu, 29 May 2014 00:28:14 +0200, Marek Wodzinski
<m...@O...mamy.to> wrote:
> Ale tak mierzysz tylko czas drugiego wgeta :-)

Bo tylko wystarczy czas drugiego pod warunkiem, że pierwszy będzie w
tle.Zwróć uwagę pod czego wątek się zaczął.

> Dopiero rendering tego co się dostanie wymaga cpu, ale tu
przeglądarki
> jakoś się nie skalują:-) Owszem, flasha odpali na drugim corze,
sandboxy
> też może porozrzucać, ale jak otwierasz tylko jedną stronę, to
wiele Ci
> nie da fefnaście corów.

Chyba w1993 :).
Teraz "jedna strona" może może mieć kilkanaście-dziesiąt reqestów do
kontentu na różnych serwerach (nawet jak jest keep alive to i tak
działa w obrębie jedengo połączenia) + ajax, przeglądarka pociągnie
to w osobnych wątkach.A to już daje teoretyczną szansę na rozłożenie
tego między "cory". Paradoxalnie to czasami jest problematyczne, bo
jak ma się serwer www embeded z 5kb ram i ograniczenia na dwa gniazda
"na raz" a przegladarka naraz chce w 6 połączeniach pobrać kontent to
4 jej się przyblokują zanim dwa możliwe się zwolnią. A wtedy tylko
ajax+sync pomaga kosztem czasu ładowania.


> Raczej widać, żeś fan FreeBSD.

W życiu, akurat był pod ręką.

--
Marek

do góry

On Fri, 30 May 2014, Marek wrote:

> On Thu, 29 May 2014 00:28:14 +0200, Marek Wodzinski
> <m...@O...mamy.to> wrote:
>> Ale tak mierzysz tylko czas drugiego wgeta :-)
>
> Bo tylko wystarczy czas drugiego pod warunkiem, że pierwszy będzie w
> tle.Zwróć uwagę pod czego wątek się zaczął.

No zaczął się od tego ile rdzeni potrzeba.
I od tego, że dałeś przykład niczego nie udowadniający w tej kwestii.
Na 10 wgetów w tle wystarczy 1 rdzeń, co w zasadzie pokazałeś wysycając
gigabit i pokazując, że on jest wąskim gardłem. Plus narzuty na handshake
itp. Nic co wymagałoby więcej niż jednego rdzenia w normalnym
wielozadaniowym systemie.

>> Dopiero rendering tego co się dostanie wymaga cpu, ale tu
> przeglądarki
>> jakoś się nie skalują:-) Owszem, flasha odpali na drugim corze,
> sandboxy
>> też może porozrzucać, ale jak otwierasz tylko jedną stronę, to
> wiele Ci
>> nie da fefnaście corów.
>
> Chyba w1993 :).
> Teraz "jedna strona" może może mieć kilkanaście-dziesiąt reqestów do kontentu
> na różnych serwerach (nawet jak jest keep alive to i tak działa w obrębie
> jedengo połączenia) + ajax, przeglądarka pociągnie to w osobnych wątkach.

Mylisz lub nie odróżniasz ściągania danych od ich renderowania. Przy
ściąganiu jest potrzebne bardzo mało cpu, w drugim wypadku ono się bardzo
przydaje.
Owszem, multitasking tak jak piszesz pomaga _ściągnąć_ dane szybciej (lub
nawet w pewnej preferowanej kolejności jeżeli chodzi o ajaxa), ale nie
wynika z tego, że potrzeba do tego ileśtam rdzeni.

Natomiast to co napisałem wyżej o fefnastu corach, to to, że przeglądarki
różnie radzą sobie z wykorzystaniem tych rdzeniu do renderingu. Oczywiste
i najprostsze rzeczy już ostały zrobione - czyli pluginy i zakładki w
osobnych procesach/wątkach, ale to co pozostało zaczyna być trudniejsze.
O ile Chrome sobie z tym radzi, to Firefox już średnio. Opera wcale.

> A to
> już daje teoretyczną szansę na rozłożenie tego między "cory".

Praktycznie, to i pół rdzenia by wystarczyło na sieć :-)
I nie zawsze uruchomienie wielu wątków na wielu rdzeniach daje oczekiwany
efekt, czasem szybciej całość chodzi w obrębie jednego o ile go nie
wysycamy.

> Paradoxalnie to
> czasami jest problematyczne, bo jak ma się serwer www embeded z 5kb ram i
> ograniczenia na dwa gniazda "na raz" a przegladarka naraz chce w 6
> połączeniach pobrać kontent to 4 jej się przyblokują zanim dwa możliwe się
> zwolnią. A wtedy tylko ajax+sync pomaga kosztem czasu ładowania.

Czyli tak jak pisałem - to nie cpu czy liczba rdzeni na kliencie jest
wąskim gardłem w _ściąganiu_ danych przez przeglądarkę.


Pozdrawiam

Marek
--
"If you want something done...do yourself!"
Jean-Baptiste Emmanuel Zorg

do góry

On Fri, 30 May 2014 12:52:00 +0200, Marek Wodzinski
<m...@O...mamy.to> wrote:
> No zaczął się od tego ile rdzeni potrzeba.

Nie , ktoś napisał że ściągając "po kolei" jest szybciej.niż
"równolegle", nie o renderowanie ( raczej generowanie) strony
chodziło, mój.komentarz był tylko do kwestii ściągania.

--
Marek

do góry

W dniu 2014-05-30 12:52, Marek Wodzinski pisze:
> On Fri, 30 May 2014, Marek wrote:
>
>> On Thu, 29 May 2014 00:28:14 +0200, Marek Wodzinski
>> <m...@O...mamy.to> wrote:
>>> Ale tak mierzysz tylko czas drugiego wgeta :-)
>>
>> Bo tylko wystarczy czas drugiego pod warunkiem, że pierwszy będzie w
>> tle.Zwróć uwagę pod czego wątek się zaczął.
>
> No zaczął się od tego ile rdzeni potrzeba.
> I od tego, że dałeś przykład niczego nie udowadniający w tej kwestii.
> Na 10 wgetów w tle wystarczy 1 rdzeń, co w zasadzie pokazałeś wysycając
> gigabit i pokazując, że on jest wąskim gardłem. Plus narzuty na handshake
> itp. Nic co wymagałoby więcej niż jednego rdzenia w normalnym
> wielozadaniowym systemie.
>
>>> Dopiero rendering tego co się dostanie wymaga cpu, ale tu
>> przeglądarki
>>> jakoś się nie skalują:-) Owszem, flasha odpali na drugim corze,
>> sandboxy
>>> też może porozrzucać, ale jak otwierasz tylko jedną stronę, to
>> wiele Ci
>>> nie da fefnaście corów.
>>
>> Chyba w1993 :).
>> Teraz "jedna strona" może może mieć kilkanaście-dziesiąt reqestów do kontentu
>> na różnych serwerach (nawet jak jest keep alive to i tak działa w obrębie
>> jedengo połączenia) + ajax, przeglądarka pociągnie to w osobnych wątkach.
>
> Mylisz lub nie odróżniasz ściągania danych od ich renderowania. Przy
> ściąganiu jest potrzebne bardzo mało cpu, w drugim wypadku ono się bardzo
> przydaje.
> Owszem, multitasking tak jak piszesz pomaga _ściągnąć_ dane szybciej (lub
> nawet w pewnej preferowanej kolejności jeżeli chodzi o ajaxa), ale nie
> wynika z tego, że potrzeba do tego ileśtam rdzeni.
>
> Natomiast to co napisałem wyżej o fefnastu corach, to to, że przeglądarki
> różnie radzą sobie z wykorzystaniem tych rdzeniu do renderingu. Oczywiste
> i najprostsze rzeczy już ostały zrobione - czyli pluginy i zakładki w
> osobnych procesach/wątkach, ale to co pozostało zaczyna być trudniejsze.
> O ile Chrome sobie z tym radzi, to Firefox już średnio. Opera wcale.
>
>> A to
>> już daje teoretyczną szansę na rozłożenie tego między "cory".
>
> Praktycznie, to i pół rdzenia by wystarczyło na sieć :-)
> I nie zawsze uruchomienie wielu wątków na wielu rdzeniach daje oczekiwany
> efekt, czasem szybciej całość chodzi w obrębie jednego o ile go nie
> wysycamy.
>
>> Paradoxalnie to
>> czasami jest problematyczne, bo jak ma się serwer www embeded z 5kb ram i
>> ograniczenia na dwa gniazda "na raz" a przegladarka naraz chce w 6
>> połączeniach pobrać kontent to 4 jej się przyblokują zanim dwa możliwe się
>> zwolnią. A wtedy tylko ajax+sync pomaga kosztem czasu ładowania.
>
> Czyli tak jak pisałem - to nie cpu czy liczba rdzeni na kliencie jest
> wąskim gardłem w _ściąganiu_ danych przez przeglądarkę.

Większe pliki można ściągać FlashGet-em. Jest on też rozszerzeniem w
Firefox.


--
animka

do góry