Jump to content
aro

Optymalizacja CCC oraz memcache

Recommended Posts

Pytanie do osób, które korzystały z funkcjonalności CCC:

 

Na ile Waszym zdaniem przyspieszyło to sklep? Gdybyście mogli to ocenić procentowo? Może prócz prędkości są jeszcze inne zalety?

Nie korzystam jeszcze z CCC, tylko ze względu na sprzeczne opinie - jedni chwalą, inni zgłaszają problemy. Czy po włączeniu CCC i stwierdzeniu, że nie ma zmian na plus można bez problemu wrócić do standardowych ustawień - wyłączamy opcję i po sprawie, czy trzeba jakieś pliki przywrócić z backupu? Na jakie aspekty należy zwrócić uwagę korzystając z CCC? Pytania dotyczą PS1.4.x oraz PS1.5.x ze standardowym core.

 

Druga sprawa: memcache

Jakie tu odnotowaliście przyspieszenie? Jest wiele opinii, że korzystanie z tej pamięci wręcz spowolniło sklep, aczkolwiek często winy doszukiwano się w samym hostingu.

 

Kto z Was korzystał z CCC i memcache w linuxpl.com i z CCC na nazwa.pl (memcache w nazwa.pl nie ma)? Generalnie chodzi o polski hosting.

 

p.s. cache do plików - CacheFS - generuje ogrom plików w filesystemie - jeżeli nie mamy memcache, to do jakiej głębokości stosować według Waszego doświadczenia i czy to w ogóle zdaje egzamin?

Share this post


Link to post
Share on other sites

Cześć.

Zadałeś bardzo ciekawe pytania. Osobiście uważam, że włączenie CCC i dla CSS i JavaScript jest absolutną koniecznością na serwerze produkcyjnym. Modułowa budowa Prestashop powoduje, że w stanie zaraz po instalacji są przesyłane 23 pliki CSS i 11 plików JS, włączając CCC będą tylko 2. Do tego włączam "Optymalizację Apache" która dodaje do pliku .htaccess dyrektywy wykorzystujące mod_deflate na serwerze co zmniejsza ilość przesyłanych danych tekstowych (html, css, js niestety zdjęcia się nie łapią) o ponad 70%.

Zastanawiały mnie opcje minifikacji HTML i kompresji JS umieszczonego w HTML, słyszałem, że mogą się okazać nieprzyjazne dla wyszukiwarek. Zrobiłem kilka pomiarów by sprawdzić czy zyski są warte ryzyka, ale okazało się, że w Prestashop w stanie zaraz po instalacji te dwie opcje oszczędzają tylko 1KB. Więc na mój użytek i przy themie którego będę używał na pewno te dwie opcje wyłączę.

23llgky.jpg

Jak widać włączając CCC i dla CSS i JS oraz Optymalizację Apache, można zjechać z przesyłania 35 plików do 3 i z 310KB do 70KB.

Edited by Piotr Kaczor (see edit history)
  • Like 3

Share this post


Link to post
Share on other sites

PS1.4.10.0

Potestowałem CCC i u mnie zeszło w dół o ponad 20kb, czas wczytywania strony jest krótszy - ogólnie warto włączyć.

 

CacheFS (gdy nie mamy memcache) - testowałem z głębokością katalogów do "1". Subiektywnie nie zauważyłem, aby strony wczytywały się szybciej, może nawet tak samo lub wolniej. Nie wiem też, czym to realnie zmierzyć (jakim monitorem, w jaki sposób przeprowadzić symulację)? Jak rozumiem, przy CacheFS tworzone są pliki dla każdego możliwego odnośnika/podstrony w sklepie? Np: 100 podstron/linków to 100 plików przy parametrze CacheFS = 1? Głębiej nie ustawiałem, bo już raz zapchałem system przez setki tysięcy wygenerowanych plików dla CacheFS.

 

p.s. Czy korzystacie w swoich rozwiązaniach ze sprite'ów CSS?

Share this post


Link to post
Share on other sites

Piotrek - super opracownie. Sam to ogarnąłeś?

Share this post


Link to post
Share on other sites

@aro z tego co zrozumiałem, CacheFS zajmuje się przechowywaniem danych otrzymanych od serwera MySQL, czytałem że otwarcie jednego pliku CacheFS jest szybsze niż nawiązanie połączenia z bazą danych. Ale w momencie gdy PrestaShop wyświetla stronę główną (w stanie po instalacji) wykonuje około 300 zapytań do bazy, z czego 113 jest oznaczonych jako NO_CACHE. Wydaje się więc, że nawiązanie jednego połączenia z bazą, będzie szybsze niż otwarcie kilku set plików CacheFS.

Niestety też nie jestem w stanie wykonać dokładnych pomiarów. Co więcej mam teraz więcej niejasności niż przedtem, bo przy wyłączonym CacheFS mój serwer testowy (pewnie nie jest skonfigurowany odpowiednio do użycia Cache) odbiera 300 zapytań, po włączeniu CacheFS nadal odbiera 300 zapytań i także po włączeniu APC wciąż odbiera 300 zapytań do bazy.

 

@vekia Tak, pomyślałem by wrzucić notatki do Excel'a, może komuś pomogą lub rozwieją wątpliwości.

  • Like 2

Share this post


Link to post
Share on other sites

Wykupiłem sobie serwer memcached 64mb - w parametrach presty jako "waga" wpisać rozmiar serwera?

Share this post


Link to post
Share on other sites

Wykupiłem sobie serwer memcached 64mb - w parametrach presty jako "waga" wpisać rozmiar serwera?

 

1. Też tego nie wiem, może ktoś podpowie?

2. Czy stosując memcache zauważę dużą różnicę w szybkości wczytywania sklepu?

Share this post


Link to post
Share on other sites

Przeważnie ustawia się na:

 

Adres IP 127.0.0.1 Port 11211 Waga = 1

 

Chyba że twój dostawca memcached da ci inne ustawienia.

 

 

Co do prędkości to zależy to od wersji prestashop 1.4 czy 1.5

 

Przy nie obciążonym sklepie strony będą się otwierały:

 

1.4 - wolniej ( ? )

 

1.4.11 - troszeczkę wolniej (można używać)

 

1.5 - wolniej (nie używam czekam na poprawki)

 

Włączone ccc – wolniej (polecam w1.4)

 

Włączone ccc zaoszczędzimy na transferze danych strony mniejsze 25%-30%

 

Włączenie w prestashop 1.5 CCC dla JavaScript, Kompresuj JavaScript powoduje złe wyświetlanie szablonu mobilnego. (polecam włączenie CCC dla CSS, minifikuj HTML)

 

Przy obciążonym sklepie nie testowałem.

Edited by karolwild (see edit history)

Share this post


Link to post
Share on other sites

Memcache różnie z nim bywa. CacheFs jest fany jak nie masz za duzego sklepu.

Co do APC i Memcache zawsze beda 2 obozy ;) Wynika to z samej ideologi działania jednego i drugiego za niedługo dostarcze testy :)

Ja stosuje można by powiedzieć obydwa na raz...

Sklep po instalcji defaultowo zabiera mi niecałe 400 ms na nginxie z czego zapytania do bazy sa na poziomie do 100 ms

Share this post


Link to post
Share on other sites

Czy to możliwe że przy włączonym memcached sklep działa wolniej? Testowałem tools.pingdom i za każdym razem sklep zwalnia. Hosting to biznes-host.

Share this post


Link to post
Share on other sites

gdzieś pojawiły się wpisy na polskim forum, że źle skonfigurowany memcached potrafi wyraźnie zwolnić sklep.

Nawet w tym wątku jest krótkie info o tym, że przy nie obciążonym serwerze będzie działac wolniej

Share this post


Link to post
Share on other sites

tak źle skonfgurowane mem cache i wyraźne przeciązenie serwera np RAM zachodzi na swap działa jak killer dla memcache dodatkowo moze być tak ze jest zła ilość pamieći przydziona dla niego.

I jesli jest za mało pamięci i zbyt dużo zapytań jest memcache może się za czesto przełoadowywać. 

Dlatego też memcache fajnie gdy 1 jest na tym samym serwerze co frontend i dodatkowo konfiguracja memcache użyteczna dla więcej niż 1 serwera. Dlatego niejednokrotnie lepiej wybrać APC który działa obiektowo. Lub jeśli masz php 5.5 to masz OPC ale jego dopiero testuje :)

Share this post


Link to post
Share on other sites

Tak jak napisał kolega u góry, APC to dobra sprawa, nawet na blogu PrestaShop było pokazane jak wielki skok wydajnościowy zaoferował, jeśli chodzi o CacheFS to ten system jest nieporozumieniem w połączeniu z shared hostingiem. 

 

Minifikacja HTML i JS inline nie za wiele daje, CCC to konieczność, oczywiście do tego wyłączenie kompilacji Smarty oraz używanie z głową hook oraz własnych modułów które niejednokrotnie potrafią nieźle spowolnić sklep przez brak obsługi cache'owania.

Share this post


Link to post
Share on other sites

 

Minifikacja HTML i JS inline nie za wiele daje, CCC to konieczność, oczywiście do tego wyłączenie kompilacji Smarty

 

Powiem tak że Minifikacja HTML może nawet spowolnić preste oraz powodować wyskakiwanie białych ekranów. Wszystko związane jest z tym że koledzy francuzi nie użyli najszybszych instrukcji do Minifikacji w klasie i czasami timeouty w pliku php.ini nie wystarczają a dodatkowo do tego fragmentacja jeśli macie za mało przydzielonej pamięci w php itd itd Wtajemniczeni wiedzą :ph34r:

Share this post


Link to post
Share on other sites

Jednak memcache coś daje :)

~30% zyskałem -> świeży mały sklepik w jeszcze na etapie konfuracji z CDN i bajerami daje wynik 568 ms z memcache bez niego ~980ms Ciekawe czy da się jeszcze bardziej to skrócić. 

Share this post


Link to post
Share on other sites

może to dzięki temu, że masz serwer dobrze postawiony :D

ja pamietam, że mi zamulało, różnica nawet do 600ms, nie wnikałem nigdy w przyczynę problemu, po prostu to wyłączyłem :P

Share this post


Link to post
Share on other sites

Zna może ktoś jakiś sposób aby sprawdzić czy memcached działa
czy plik są ładowane z pamięci memcached czy serwera ile jest trafień.
Bo po szybkości działania wychodzi mi prawie identycznie. Nie widzę żadnych korzyści
Testowałem na prescie 1.5.5.0 widzę niewielkie spowolnienie prawie niezauważalne
(w poprzednich było dużo większe).

Share this post


Link to post
Share on other sites

phpMemcachedAdmin wszstkie informacje podstawowe dostaniesz :)

Ja mam hitrate na 99.5% :)

Wychodzi na to że 64 Mb to dużo dla preste :huh:

Chyba widze ze mysql dostanie wiecej pamięci :D
 

Jedyna kwestią która mnie zastanawia to jak zmiejszyć czas inicjacji w prescie bo to zabiera najwiecej czasu

Edited by tczaude (see edit history)

Share this post


Link to post
Share on other sites

Piotr Kaczor wkleil tabelke w ktorej kazda opcja jest ladnie porownana, pytalem o to w jaki sposob dokonywal testow tak zeby moc sobie samemu porownac dla swojego sklepu

Share this post


Link to post
Share on other sites

Witam serdecznie, od niedawna korzystam z prestashop 1.5.6 , mam takie pytanie , chcę zmienić szablon ze standardowego , na ten który zakupiłam , ale za każdym razem dostaje taki komunikat    "Niepoprawny plik konfiguracyjny"   plik jest w formacie Zip , i nie bardzo wiem jak sobie poradzić

Share this post


Link to post
Share on other sites

zdecydowanie nie ten wątek ;) spróbuj przepakować archiwum tj. rozpakuj je i zapakuj raz jeszcze, a w razie problemów kontynuj temat w nowym wątku :)

Share this post


Link to post
Share on other sites

A ja po wielu wieeelu próbach doszedłem chyba do optymalnego rozwiązania. APC, wyłączone keszowanie i wyłączone CCC i najważniejsze - mod pagespeed od googla na serwerze https://developers.google.com/speed/pagespeed/module jest trochę zabawy z konfiguracją ale efekt super. Polecam również konsole smartów do śledzenia lagujących wtyczek.

Share this post


Link to post
Share on other sites

Testowałem trochę załączenie wszystkich i poszczególnych modułów CCC u siebie za każdym razem sprawdzając google speed test i najlepszy efekt uzyskałem gdy wszystkie CCC mam wyłączone ( najwyższy wynik testu 88 ), dla wszystkich włączonych 85 (żadnych dodatkowych zmian nie przeprowadzałem w międzyczasie.  :)

Share this post


Link to post
Share on other sites

Co prawda wtyczki nie testowałem o dziwo ciągle jakoś to odkładam to ze względu drogi jaka trzeba przejść na gentoo do tego :/

Cachowanie opc + memcache.

Optymalizacje agregacje na "on" wszystkie.

Jeżeli po włączeniu spada wydajność to masz coś nie tak z serwerem.

Owszem można zauważyć momenty w których minifkacja html obniża wydajność ale głownie chodzi o ilość atrybutów i sklepów i samo wykorzystanie samej funkcji. Minifikacja html odbywa się w prescie w kodzie php podczas wykonywania jeżeli masz mało pamięci dla php to wydajność będzie spadać dla 196 mb uzyskałem wynik zadowalający dla klienta sklep poniżej 2 sec obniżony z 12 sec na apache przy produktach po 100 atrybutów i kolo 10 multistorów ale oczywiście zależy to od działających modułów.

Swoja droga fajnie by bylo pomyslec nad modulem httpr tak jak to ma miejsce w np drupalu.

Swoja droga mam jeszcze 1 pomysł na preste i memcache chodzi o to by trzymać html i css w memcache a nie tylko na poziomie presta <-> memcache ale już na poziomie serwera www ale muszę podnieść ilość produktów i wtedy zobaczę wyniki :)

Share this post


Link to post
Share on other sites

Tak jak napisał kolega u góry, APC to dobra sprawa, nawet na blogu PrestaShop było pokazane jak wielki skok wydajnościowy zaoferował...

Jak wyżej, APC działa Ok ale należy skorygować przydzieloną pamięć. Domyślnie jest 32M i gdy zaczyna jej brakować moduł czyści całość i efekt jest odwrotny ;) .

Najlepiej po włączeniu APC w Prestashop po kilku godzinach (dniach) działania sklepu sprawdzić czy wystarcza pamięci (fotka - na czerwono) - jeśli wartość jest inna niż zero to należy zwiększyć do 64 lub najbezpieczniej 128, tyle powinno wystarczyć dla przeciętnego sklepu...

Zmiana: "apc.shm_size = 32 na 64 lub 128"

z1ccsfo.png

Share this post


Link to post
Share on other sites

Czy mając 512MB RAM dostepne na VPS warto włączyć APC (Memcached spowolnił mi sklep)? Czy lepiej dokupić przydział ram i dopiero włączyć APC z 128 MB?

Share this post


Link to post
Share on other sites

mało informacji podajesz

ile Ci mysql ciagnie ramu

Ile masz klientów na powiedzmy 1 minute

 

Ile bierze http

czy dzial cos jeszcze najlepiej podaj print screena z jakiegoś htopa albo coś w tym stylu

Osobiscie odpaliłem cos takiego ale warunek nie zaduza baza powiedzmy do 200 produktów i ruch maly i da się ale trzeba sie nakombinowac

Ale jesli memcache Ci spowalnia to juz masz ostrzeżenie że źle zarzadzasz pamięcią lub masz jej za mało

Share this post


Link to post
Share on other sites

Czy mając 512MB RAM dostepne na VPS warto włączyć APC (Memcached spowolnił mi sklep)? Czy lepiej dokupić przydział ram i dopiero włączyć APC z 128 MB?

512 całego ramu? czy wolne po zainstalowaniu systemu? (dokupić? - ram chyba najwięcej kosztuje?). 

Według mnie warto włączyć, testowałem to na VPS 1G ramu z tym, że zainstalowany jest Apeche 64bity na nim Prestashop, ISPConfig i jedna aplikacja SEO Panel - Pamięć prawie cały czas jest na limicie (750 - 1024) używane, czyli 80-100% zajętości i wszystko nieźle śmiga. 

W sklepie 250 produktów, ruch z robotami 7-8 tysięcy na dobę, prawdziwych wizyt 600 - 750, w SEO Panel włączonych kilka bzdur i przy konfiguracji APC 128MB wszystko płynnie działa.

Jeśli włączysz APC i przydzielisz mu 128 ramu to zawsze to 128 będzie tylko dla niego, nie skorzysta z niego inna aplikacja. Musisz przetestować. Na początek możesz przydzielić 64 i potem sprawdzić czy wystarcza...

Edited by PMaster (see edit history)

Share this post


Link to post
Share on other sites

Ale jesli memcache Ci spowalnia to juz masz ostrzeżenie że źle zarzadzasz pamięcią lub masz jej za mało

Tu masz dużo racji, ale problem jest chyba nie w zarządzaniu pamięcią ale w poprawnej konfiguracji modułu Memcache lub Memcached.

Samo zainstalowanie i włączenie go to pikuś  :D, w sklepie da się go włączyć i wydaje się, że wszystko jest ok - a tu lipa :( i on wcale poprawnie nie działa.

W domyślnej konfiguracji nie dało się zalogować się do ISPConfig, dodatkowo w logach pojawiło się sporo błędów i dałem spokój. Niby wszystko w/g instrukcji na stronach Apache ale skutki opłakane...

Edited by PMaster (see edit history)

Share this post


Link to post
Share on other sites

Wiesz ogolnie ja widze 1 problem u korzeni wiele ludzi nie rozróznia róznicy w działaniu memcache vs APC czy opcache.

I troche testów i praktyki potwierdza to a mianowicie, APC (Opcache) przechwuje obiekty memcache juz nie. 

Idac dalej jeśli masz słaba wydajność php to apc bedzie lepszy jeli masz dobry serwer i nie masz iowaita na poziomie 15% ;) i troche mocy obliczeniowej to memcache pobije apc. 

Idac dalej warto wziąść jeszcze 1 element wiszace "niedobitki" przez które serwer bedzie Ci swapował. Nie wiem jakiego masz mpm w apache ale presta działa lepiej na preforku niż na workerze czy event wlesnie przez kwestie ja minimalizowałem ten efekt poprzez statyczne wkompilowanie php do apache i jesli proces zanikał apacha to "proces" php automatycznie też . Ale teraz widze na przykladzie nginxa gdzie nistety tak sie nie da zrobić działam w ten sposób ze poprzez crona robie reload php-fpm. Dzieki temu wydajność jest zapewniona optymalna oczywiście trzeba jeszcze pogrzebać w jajku zeby korzystał w prawie 100% tylko z ramu i da sie zrobić wszystko kwestia tylko jak czesto bedziesz musiał robić reloada php ja robie co 30 minut ale widziałem ze w innych rozwizaniach szczególnie na lighthhtpd robią nawet co 2 minuty taki zabieg. 

Dlaczego o tym piszę bo jesli nie dopilnujesz tego mysql bedzie Ci zabierał RAM przez co znów wyladujesz na swapie i serwer bedzie mulił. i kolo sie zamyka

 

Powiem tak teraz przerzucam drobnice na 1 serwer 

8x drupal 

2x prestashop

postfix 

courier-imap

nginx memcache + opcache 

i srednie użycie ramu na poziomie 700-800 mb 

czas ładowania stron srednio na poziomie 1 sec

 

Jedynie nie wiem jeszcze 1 czy presta kompresuje memcache czy nie i jesli nie czy da sie to włączyć czas to posrawdzać :)

Share this post


Link to post
Share on other sites

A ja po wielu wieeelu próbach doszedłem chyba do optymalnego rozwiązania. APC, wyłączone keszowanie i wyłączone CCC i najważniejsze - mod pagespeed od googla na serwerze https://developers.google.com/speed/pagespeed/module jest trochę zabawy z konfiguracją ale efekt super. Polecam również konsole smartów do śledzenia lagujących wtyczek.

Tu masz sporo racji... :) Dodatkowo, gdy na serwerze masz inne strony Drupala itp. to przy okazji pagespeed też je "ogarnie" :D .

Z tym, że po wyłączeniu całej optymalizacji w sklepie bardzo obciążony jest procesor serwera. Testowałem wczoraj Twoje ustawienia i przy każdym otwarciu strony obciążenie skacze do 90% (chwilowo, ale przy dużym ruchu może być z tym problem /procesor 2.7 jeden rdzeń/).

Gdy w sklepie włączone  jest CCC dla CSS i Javy, a resztę robi moduł - obciążenie procesora spada o  połowę a efekt jest taki sam.

Wydaje mi się, że takie rozwiązanie jest bezpieczniejsze, no chyba że ma się do dyspozycji silny procesor... ;)  

Share this post


Link to post
Share on other sites

Ja tam tym pagespeedem narazie sie nie przejmuje z pomoca przychodza mi inne usługi CDN :)

Tak jak mówisz obciązenie cpu masz nagły skok mega w górę. Dlatego przywiazuje wagę do szybkiej odpowiedzi na serwerze. 

jak ten skok bedziesz miał w miare krótki to bedzie miodzio gorzej gdy tenskok zawiera wiecej czasu ale tutaj wracamy do tego ile masz RAM-u.

Jedynie zastanaia mnie jedno proces optymalizacji przebiega z obserwacji scalanie -> minifikacja html ciekawe czy nie wydajniej było by odwrócić ten proces wiecej małych pliczków do minifikcji swoja drogą najlepiej było by robić minifikację po shellu i jeszcze bez przesyłania nagłowków. Ale chyba za bardzo chiałbym stosować drupalowe praktyki ;)

Share this post


Link to post
Share on other sites

Ja nie zagłębiam się bardzo w szczegóły, zawsze staram się tylko aby każdy sklep miał wynik w pagespeed powyżej "85" i każda metoda aby to osiągnąć mnie zadowala - to dla Googla jest OK (a w/g mnie to dla nich właśnie ta zabawa). 

Klient czy zobaczy stronę po 1 sekundzie czy po 1,3 sekundy to chyba nie robi mu różnicy, a Googloooowi już tak. ;)

Share this post


Link to post
Share on other sites

Przeczytałem w necie, że stworzenie subdomen dla plików Javascript i CSS:

tzn. 2 subdomen dla js. kierujących do folderu /js/ i folderu /theme/mojtheme/js oraz 2 dla css. kierujacych do folderu /css/ i /theme/mojtheme/css/ może przyspieszyć ładowanie.

 

Te cztery subdomeny pozwolą odwiedzającym ładować więcej plików jednocześnie. Przeglądarka jest ograniczona do 8 jednoczesnych pobierań z jednej strony – każda subdomena dodaje 8 do równoległych pobierań. Pełna liczba równoległych pobierań, zamiast 8, będzie wynosiła 40.

 

Czy macie jakieś doświadczenia z tym tematem i jak to praktycznie zrobić?

Share this post


Link to post
Share on other sites

pliki sa na tyle małe ze ja osbiście nie widze potrzeby. A ilośc requestów nie przeklada sie na wydajność zawsze czasmi odwrotnie.

Ja uzywam głownie technologi CDN. gzipowanie daje duz lepszy efekt w postaci 1 pliku. Jedynie efekt moze okazać się znaczacy dla obrazków ale biorąc pod uwagę łacza konsumenckie nie ma sensu ale to moja opinia lepsi niech sie wypowiedza :)

A jesli rozdzielasz na subdomeny to wtedy przegladarka puści Ciebie. 

Ja jeszcze sprawdzam 1 rozwiazanie minifikacja perlem po stronie web serwera vs ta po stronie presty zobaczymy co  wygra :)

Share this post


Link to post
Share on other sites

CDN jest ok przy dużym, najczęściej skokowym ruchu (zapobiegając "zarżnięciu serwera") i bardzo rozproszonym geograficznie trafficu. Z tego co się orientuje mało firm ma też hosty w PL. Do małych i średnich sklepów w większości sytuacji nie ma sensu go pakować bo zamiast przyspieszać zwalnia sklep ładując statyczne treści z dziwnych lokalizacji. tczaude - polecam Ci przetestowanie pagespeeda właśnie do CDN :) - ModPagespeedMapRewriteDomain. Dużo duużo szybciej to działa niż Prestowe Media servers. Testowane z 1.4 i 1.5. Pozdrawiam.

Share this post


Link to post
Share on other sites

Koledzy może dacie link do działającego sklepu po zastosowanych zmianach.

Będzie się można przekonać na ile zmiany przyspieszają sklep.

Te dostępne zaprzeczają temu co piszecie.

Share this post


Link to post
Share on other sites

Koledzy może dacie link do działającego sklepu po zastosowanych zmianach.

Będzie się można przekonać na ile zmiany przyspieszają sklep.

Te dostępne zaprzeczają temu co piszecie.

iwos.pl PS 1.5.6.2. Templejt niestety jest słabo zoptymalizowany, trzeba go jeszcze ulepszyć. I najważniejsza rzecz - exeptions w modułach jeszcze nie jest do końca zrobione. Jak się ktoś chce cdn pobawić to tutaj - http://www.cdn.net/ jest darmowy 1 miesiąc i tera trafficu. Nie trzeba karty kredytowej :)

Share this post


Link to post
Share on other sites

Ja siedze na 1 operatorze CDN ma serwery w pradze niemczech i warszawie ale zawsze jade przez iemcy badz warszawe automat tak przelacza ale ip mam wyjsciowe we wrocławiu wiec no coż ale nie nawrzekam.

Tak jak napisałeś jest jeszcze wiele inych aspektów CDN.

Swoja droga zoabczmy mam rozwojowego klienta malego ale jelsi rozmowy dobrze pojda to pojdą wszystkie technologie ktore bede wskazywać na wydajność serwowania stronki na nowej prescie 1.6

Tylko numer 1 to wyrzucenie bootstrapa czyli przepisanie wszystkiego co jest katargą.

Ale lada dzień powinno widać efekty wiec przekaże winiki z testów nginx opcache memcache CDN i pare jeszcze innych elementów które sa troche moimi priv rozwiazaniami.

Bo narazie 2 sec z 110 requestami mnie nie powala  

Share this post


Link to post
Share on other sites

Pozwolę sobie odkopać temat. Zainstalowałem na VPS 3x2.4 Ghz, 4 GB RAM komendą apt-get install memcached php5-memcache , wszystko skonfigurowałem poprawnie, całość nasłuchuje localhost czyli 127.0.0.1, php info zgłasza że memcache jest aktywny,  netstat -tap | grep memcached ładnie wskazuje, że jest uruchomiony a w preście w zakładce cache mam tylko coś takiego jak testuję serwer.

memcache.jpg.4b84d6e804f80f5ca59b00666946111d.jpg

Jak wybiorę opcję powyżej czyli PHP::Memcache wtedy test przechodzi, jednak strona działa znacznie wolniej na memcache. Czytałem, że PHP::memcached jest znacznie lepszy i jego chciałbym uruchomić, ale czy ktoś wie dlaczego to nie pyka?  Na zwykłym testy przechodzą ale strona zwolniła o jakieś, 2, 3x więc to się rozmija z celem.

 

memcache.jpg.7e68efd092ec7002298a818cb9d5fe4f.jpg

 

Ogólnie po aktywacji tego, zużycie RAMu na serwerze skoczyło o jakieś 300 mb (wciąż pozostaje wolne 2.5 GB), ale nie widzę żadnego wzrostu szybkości tylko zamułe :/ Ktoś coś? 
Prestashop 1.6.1.4

Czy jest to możliwe przez to że korzystam z Apache2 v.2.4.10 a w necie piszą, że memcached to tak tylko do 2.2?

Edited by hakeryk2 (see edit history)

Share this post


Link to post
Share on other sites

Pamiętaj, że memcache(d) działa w oparciu o RAM i aby miało szansę zadziałać trzeba obciążyć serwer. Dawno nie robiłem testów i nie wypowiem się jaka jest różnica między działaniem presty na memcache a memcached. Teoretycznie memcached jest nowszy, kilka rzeczy ma inaczej rozwiązane i może być szybszy ale liczą się testy.

Share this post


Link to post
Share on other sites
14 hours ago, MarioCCH said:

Spróbuj na porcie 11001

Czy to ma jakieś podłoża by pomóc czy ogólnie jest to jakaś tam sprawdzona metoda? Nie wiem czy jest sens od nowa ryzykować.

 

13 hours ago, Piotr K. said:

Pamiętaj, że memcache(d) działa w oparciu o RAM i aby miało szansę zadziałać trzeba obciążyć serwer. Dawno nie robiłem testów i nie wypowiem się jaka jest różnica między działaniem presty na memcache a memcached. Teoretycznie memcached jest nowszy, kilka rzeczy ma inaczej rozwiązane i może być szybszy ale liczą się testy.

Pamiętam i dlatego tak jak wspomniałem mam często wolne około 2GB Ramu które chciałbym spożytkować. Problemem jest to, że nie mogę w preście w ogóle uruchomić memcached, pomimo tego, że config na linuxie mówi, że wszystko jest ok.

Share this post


Link to post
Share on other sites

Presta działa zarówno z memcache jak i memcached o ile oba są dobrze skonfigurowane. Zobacz najpierw sobie czy masz oba w phpinfo.

Share this post


Link to post
Share on other sites

@Piotr K. Ogólnie już po googlowaniu, przetestowaniu itp jestem w 100% w stanie stwierdzić że dla wersji PHP 5.6 i na serwerach VPS  stosowanie memcache(d) mija się z celem ze względu na znaczne spowolnienie. Jedynie w tej sytuacji zaleca się stosowanie opcache który wystarczy uaktywnić w konfiguracji php. Daje to lekkie przyśpieszenie.

Tak więc jeśli ktoś trafi na ten temat niech wie, że później jest mnóstwo babrania się by usunąć memcached z serwera :<

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More