🚀 go-pugleaf

Dnia Mon, 29 Jun 2015 07:42:30 -0700 (PDT), M.M. napisał(a):

> Po czasie pliki zapisywane na dysku zrobiły się duże.
> Myślę sobie, że i tak i tak będę musiał do czegoś innego
> używać memcached, więc przerobię doraźną samoróbkę na 
> profesjonalne rozwiązanie. Niestety po teście wyszedł zonk, 
> samoróbka działa 10 razy szybciej niż profesjonalne 
> rozwiązanie.
> 
> Czyżby memcached mialo taki ogromny narzut?

Nie powinno mieć przy takim zastosowaniu jak opisujesz. Ale za mało
szczegółów podałeś, by móc powiedzieć coś więcej. "Duże pliki" są jakiej
wielkości? I czy przypadkiem OS Ci ich jakoś nie buforuje?

Samych zapytań nie da się zoptymalizować?

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On Wednesday, July 1, 2015 at 7:47:36 PM UTC+2, Borys Pogoreło wrote:
> > Czyżby memcached mialo taki ogromny narzut?
> 
> Nie powinno mieć przy takim zastosowaniu jak opisujesz. 
Widocznie ma spory narzut. Albo nie umiem czegoś skonfigurować.

> Ale za mało szczegółów podałeś, by móc powiedzieć coś więcej. 
Dużo bym musiał się napisać. Czy można jakoś obliczyć czas
przetwarzania danych w oparciu o memcached? Ile czasu trwa
jedno zapytanie w zależności od warunków?


> "Duże pliki" są jakiej wielkości? I czy przypadkiem OS Ci 
> ich jakoś nie buforuje?
Na pewno buforuje je OS i na pewno są wczytywane sekwencyjnie
przy starcie skryptu. Ale to zawsze operacje dyskowe plus
parsowanie PHP (metoda unserialize). Rozmiar rzędu 30MB.


> Samych zapytań nie da się zoptymalizować?
Dużo małych insertów i selektów do bazy, rzędu 10tys w jednym
update bazy.

Pozdrawiam

W dniu 2015-06-29 o 16:42, M.M. pisze:
> Miałem doraźny problem z wydajnością zapytań SQL. Na szybko
> napisałem swój bufor w PHP. W odpowiednim destruktorze
> bufor jest zapisywany na dysku, a w konstruktorze jest
> z tegoż dysku wyczytywany. Jeśli coś jest w buforze, to
> nie trzeba pytać bazy - metoda prosta jak imadło.
>
> Po czasie pliki zapisywane na dysku zrobiły się duże.
> Myślę sobie, że i tak i tak będę musiał do czegoś innego
> używać memcached, więc przerobię doraźną samoróbkę na
> profesjonalne rozwiązanie. Niestety po teście wyszedł zonk,
> samoróbka działa 10 razy szybciej niż profesjonalne
> rozwiązanie.
>
> Czyżby memcached mialo taki ogromny narzut?
>
wygląda to na bloga. masz pretensje do samego siebie. ntg pomijam. nie ma 
podanego silnika bd. nie ma podanych zapytań. zwykłe gadanie - sobie a muzom.


-- 
Artur

On Wednesday, July 1, 2015 at 11:46:32 PM UTC+2, artiun wrote:
> W dniu 2015-06-29 o 16:42, M.M. pisze:
> > Miałem doraźny problem z wydajnością zapytań SQL. Na szybko
> > napisałem swój bufor w PHP. W odpowiednim destruktorze
> > bufor jest zapisywany na dysku, a w konstruktorze jest
> > z tegoż dysku wyczytywany. Jeśli coś jest w buforze, to
> > nie trzeba pytać bazy - metoda prosta jak imadło.
> >
> > Po czasie pliki zapisywane na dysku zrobiły się duże.
> > Myślę sobie, że i tak i tak będę musiał do czegoś innego
> > używać memcached, więc przerobię doraźną samoróbkę na
> > profesjonalne rozwiązanie. Niestety po teście wyszedł zonk,
> > samoróbka działa 10 razy szybciej niż profesjonalne
> > rozwiązanie.
> >
> > Czyżby memcached mialo taki ogromny narzut?
> >
> wygląda to na bloga. masz pretensje do samego siebie. ntg pomijam. nie ma 
> podanego silnika bd. nie ma podanych zapytań. zwykłe gadanie - sobie a muzom.

Ja mam pretensje? 

Dnia Wed, 1 Jul 2015 13:36:32 -0700 (PDT), M.M. napisał(a):

>> Ale za mało szczegółów podałeś, by móc powiedzieć coś więcej. 
>
> Dużo bym musiał się napisać. Czy można jakoś obliczyć czas
> przetwarzania danych w oparciu o memcached? Ile czasu trwa
> jedno zapytanie w zależności od warunków?

Napisz prosty skrypt z pseudo-profilerem - microtime(true) + zapis pliku do
memcached + microtime(true) + odczyt pliku z memcached + microtime(true) +
prosta arytmetyka. To samo z metodą plikową, najlepiej po restarcie
procesów serwera. Od razu będzie widać co ile trwa.

> Na pewno buforuje je OS i na pewno są wczytywane sekwencyjnie
> przy starcie skryptu. Ale to zawsze operacje dyskowe plus
> parsowanie PHP (metoda unserialize). Rozmiar rzędu 30MB.

Lekka masakra, naprawdę tego nie da się zoptymalizować? To jest coś, nad
czym warto posiedzieć i zrobić lepiej.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On Monday, July 6, 2015 at 12:42:06 AM UTC+2, Borys Pogoreło wrote:
> Dnia Wed, 1 Jul 2015 13:36:32 -0700 (PDT), M.M. napisał(a):
> 
> >> Ale za mało szczegółów podałeś, by móc powiedzieć coś więcej. 
> >
> > Dużo bym musiał się napisać. Czy można jakoś obliczyć czas
> > przetwarzania danych w oparciu o memcached? Ile czasu trwa
> > jedno zapytanie w zależności od warunków?
> 
> Napisz prosty skrypt z pseudo-profilerem - microtime(true) + zapis pliku do
> memcached + microtime(true) + odczyt pliku z memcached + microtime(true) +
> prosta arytmetyka. To samo z metodą plikową, najlepiej po restarcie
> procesów serwera. Od razu będzie widać co ile trwa.
Jeśli nie będę miał innego wyjścia, zrobię tak jak powyżej zaproponowałeś.
Zastanawiam się, czy można w miarę dokładnie oszacować ten czas, bez
pisania skryptów. 

Ile czasu powinno trwać pobranie z memcached jednej małej 
porcji danych? Weźmy np. taki scenariusz:
1) Mamy bardzo wydaje środowisko, np. program skompilowany w C++ - odpowiednik
   Twojej arytmetyki.
2) Łączymy się z serwerem.
3) Milion razy pobieramy  np. 1kb danych na podstawie klucza.
  a) serwer jest na tym samym komputerze
  b) serwer jest na innym komputerze w sieci lokalnej.
4) Rozłączamy się z serwerem.

Jakiego czasu należy się spodziewać, na dobrym sprzęcie i na dobrze
skonfigurowanym serwerze?


> > Na pewno buforuje je OS i na pewno są wczytywane sekwencyjnie
> > przy starcie skryptu. Ale to zawsze operacje dyskowe plus
> > parsowanie PHP (metoda unserialize). Rozmiar rzędu 30MB.
> 
> Lekka masakra, naprawdę tego nie da się zoptymalizować? To jest coś, nad
> czym warto posiedzieć i zrobić lepiej.

Czy da się bazę sql dyskową zoptymalizować? Raczej nie, chyba żeby włączyć
buforowanie zapisu w RAM.

Pozdrawiam

Dnia Mon, 6 Jul 2015 05:41:46 -0700 (PDT), M.M. napisał(a):

> Jeśli nie będę miał innego wyjścia, zrobię tak jak powyżej zaproponowałeś.
> Zastanawiam się, czy można w miarę dokładnie oszacować ten czas, bez
> pisania skryptów. 

Oczywiście, np. xdebug + kcachegrind, ale ja za nim nie przepadam. Choć do
szukania wąskich gardeł w większym kodzie to jedyny sensowny sposób.

> Jakiego czasu należy się spodziewać, na dobrym sprzęcie i na dobrze
> skonfigurowanym serwerze?

Jakiego dokładnie to Ci nie napiszę, ale przy milionie to zawsze będzie
zauważalne. Milion to nie jest też skala zwykłej aplikacji webowej.

Zrobiłem szybki test takim kodem:

$rand = openssl_random_pseudo_bytes(1024);
$t = microtime(true);

$m = new Memcache();
$m->addServer('localhost', 11211);
$m->set('test', $rand);

for ($i = 0; $i < 1000000; $i++)
{
    $val = $m->get('test');
}

printf('%.2f', microtime(true) - $t);

Wynik u mnie to 25.28 s. (php 5.6.10, windows)

> Czy da się bazę sql dyskową zoptymalizować? Raczej nie, chyba żeby włączyć
> buforowanie zapisu w RAM.

Zoptymalizować same zapytania. Albo przemyśleć architekturę aplikacji czy
na pewno trzeba pobierać tysiąc razy jakiś zasób - może da się pobrać
dziesięć razy dopełnienie zbioru i wyliczyć resztę? Albo zawrzeć to
wszystko w 10 zapytaniach, a resztą zajmie się baza? Itp. itd.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On 2015-07-06 15:33, Borys Pogoreło wrote:
>
>> Jakiego czasu należy się spodziewać, na dobrym sprzęcie i na dobrze
>> skonfigurowanym serwerze?
> Jakiego dokładnie to Ci nie napiszę, ale przy milionie to zawsze będzie
> zauważalne. Milion to nie jest też skala zwykłej aplikacji webowej.
>
> Zrobiłem szybki test takim kodem:
>
> $rand = openssl_random_pseudo_bytes(1024);
> $t = microtime(true);
>
> $m = new Memcache();
>
Czy mi się wydaje czy memcache a memcacheD to nie to samo ?

Dnia Mon, 06 Jul 2015 19:33:24 +0200, ww napisał(a):

>> $rand = openssl_random_pseudo_bytes(1024);
>> $t = microtime(true);
>>
>> $m = new Memcache();
>>
> Czy mi się wydaje czy memcache a memcacheD to nie to samo ?

Nie to samo w znaczeniu różne rozszerzenia PHP (memcached to wrapper na
libmemcached), ale to ten sam protokół. W omawianej sytuacji praktycznie
bez znaczenia. Róznica jest, jeśli potrzebujesz bardziej zaawansowanych
funkcji, wtedy memcached.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu 2015-07-06 o 21:06, Borys Pogoreło pisze:
> Dnia Mon, 06 Jul 2015 19:33:24 +0200, ww napisał(a):
>
>>> $rand = openssl_random_pseudo_bytes(1024);
>>> $t = microtime(true);
>>>
>>> $m = new Memcache();
>>>
>> Czy mi się wydaje czy memcache a memcacheD to nie to samo ?
>
> Nie to samo w znaczeniu różne rozszerzenia PHP (memcached to wrapper na
> libmemcached), ale to ten sam protokół.

Racja.

> W omawianej sytuacji praktycznie
> bez znaczenia.

No może. Chociaż szczerze mówiąc nie wiem czemu ma służyć test z 1 
zapisem i milionem odczytów.

Przetestujcie może REDIS:

http://redis.io/
https://systoilet.files.wordpress.com/2010/08/redis_mc_keylen_mget.jpeg

Dnia Tue, 07 Jul 2015 08:13:12 +0200, ww napisał(a):

> No może. Chociaż szczerze mówiąc nie wiem czemu ma służyć test z 1 
> zapisem i milionem odczytów.

Też nie wiem, ale takie było założenie, albo źle zrozumiałem ;)

> Przetestujcie może REDIS:

Nawet Redis przy tej skali może nie pomóc. Ale wydaje mi się, że autor ma
jakiś problem z samą implementacją, a nie wydajnością cache.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On Tuesday, July 7, 2015 at 6:17:46 PM UTC+2, Borys Pogoreło wrote:
> Dnia Tue, 07 Jul 2015 08:13:12 +0200, ww napisał(a):
> 
> > No może. Chociaż szczerze mówiąc nie wiem czemu ma służyć test z 1 
> > zapisem i milionem odczytów.
> 
> Też nie wiem, ale takie było założenie, albo źle zrozumiałem ;)
Trudno mierzyć pomiar jednego odczytu, lepiej milion i uśrednić.

> 
> > Przetestujcie może REDIS:
> 
> Nawet Redis przy tej skali może nie pomóc. Ale wydaje mi się, że autor ma
> jakiś problem z samą implementacją, a nie wydajnością cache.
Z konfiguracją mam problem. Twój przykład działa na moim systemie wiele 
razy wolniej. Odpisałem na prv.