Jump to content

peal

Members
  • Posts

    31
  • Joined

  • Last visited

Everything posted by peal

  1. Actually that's not a problem - site is working without errors. The reason why I am asking is that we have currently php 5.2 with APC and nothing else. While upgrading server, we would like to be prepared and take it as the opportunity to get maximum of it. For now we are sure APC can;t be used with php 5.6. APCu seems to be a replacement but some claim that inbuilt opcache is enough. The same with mod_pagespeed - for some must have, for others buggy module which should be avoided. I would love to see some opinions what can be used alltogether.
  2. Hello, I am a little bit confused (ok, more than little) about all the caching systems used around. We are going to upgrade our server and prestashop as well so I would like to sort out few things... Server is nginx with php 5.6 installed. PS version would be latest probably. Now, what are the possibilities to speed it up? I read it is good to use APCu, memchached and pagespeed. Is it possible to use them all without conflicts, or are they some alternatives and it's better to use just one (or some)? I have read pagespeed documentation and it seems to do lot's of impressive things. This one looks promising to me. Currently we were using APC but it's not supported in PHP 5.6 anymore, but there is APCu. I believe this cache system is used for caching compiled php files? And finaly memcached. I do not have any experience with it but I found several articles it's used very often as well. Could I ask you to clarify which one is ok to use on up to date server? Thank you very much for any related comments.
  3. Az priste budete mit opet problem, v prvni rade si opiste vsechny chybove hlasky, ktere uvidite. Lip se pak hleda pricina
  4. Podle tech grafu se problem tykal cloudu ve Francii, coz se vas opravdu netyka. Pricinu problemu bych hledal jinde.
  5. Zkusim to, snad vam nebudu vykladat nepravdy, vychazim z toho co vim a co mam odzkouseno. Prestashop je mozno pouzivat jako cloudove reseni, coz je relativne novinka a v podstate mate hosting s predinstalovanou prestou na jejich serverech. Ve vasem pripade mate ale zrejme klasickou instalaci, takze vsechna data jsou ulozena u vas (na serveru hostingu). Vse se tam take zpracovava, ke kontaktu se servery prestashopu podle me dochazi jen v backofficu v prehledu modulu, kde se kontroluje jestli neni k dispozici aktualizace. Takze nic, co by melo ovlivnit rychlost obchodu. Jestli jste zazil nejake problemy s rychlosti, tak bych se vsadil ze slo nejspis o problem prave u hostingu, zvlast pokud mate sdileny hosting. Ve spicce muze mit vas shop k dispozici mene vykonu nez obvykle, coz se projevi zpomalenim. Jak jste vlastne dosel k tomu, ze byla chyba na presta serveru?
  6. 1. Neni potreba jeste doupravit kosik? Tam se take zobrazuji ceny. 2. Tak toto je urcite snazsi reseni, na to jsem zapomel
  7. 1) Jedine co me napada, je uprava templatu, ale muselo by se to predelat na spouste mist, coz by vedlo akorat tak ke zmateni, protoze tech mist je opravdu dost. Skutecne je nutne tam tuto hodnotu davat? V maloobchode je zvykem, ze pokud je uvedena jedna cena, je s dani, tak proc to dopisovat? Pripadne by melo stacit pridat tuto informaci do obchodnich podminek, nebo nekam na viditelne misto. 2) Reseni je jednoduche, staci na stitek v css aplikovat styl display: none;
  8. Pokud mate cloudovy prestashop, tak tam problem byt muze, pri instalaci na vlastni server ale k pripojeni na presta servery ani nedochazi.
  9. Podle mych zkusenosti opravdu pomaha spravne urcit problem, to znamena na ktere strance (homepage, kategorie, produkt...), zapnout na chvili debug a zkontrolovat mysql a moduly. Proste takova ta klasika. Co mi zatim nejvice zpomalovalo shop je toto: - bloky s novym/doporucovanym zbozim, hlavne dalsi zbozi v teto kategorii. nahrava to moc dat a pritom zbytecne, takze pokud mozno srusit, nebo aspon omezit jen na par kusu. - block layered, neboli filtry. to je kategorie sama o sobe, v soucasne dobe lepsi se tomu vyhnout uplne - zapnute cachovani v optimalizaci dole: mam zkusenost jen s apc, ale presta cachuje spatne a cache za par hodin fragmentuje na 100%, takze zacne zpomalovat. Lepsi je to v preste vypnout, ale samozrejme na serveru mit apc zaple. - zbytecne velke obrazky - slider na homepage, pri nahravani stranky to stahuje vsechny obrazky ktere mate nastavene. pokud jich mate nastavenych 10, tak se jich stahne deset. Idealni je upravit nacitani na lazy load. - zbytecne moduly: odstrante vse co jde, kazdy modul navic zpomaluje nacitani
  10. Nezkusil, ani jsem netusim ze je neco takoveho k dispozici. Ja to prozatim udelal tak, ze jsem si na barvy udelal vlastni modul, vyuzivajici klasicky search controller. Jake to ma mit vylepseni? A je to skutecne uz funkcni oprava, nebo je to jen o trochu rychlejsi?
  11. Schvalne se zkuste na ten filtr podivat i na jinych vlaknech fora, co jsem nasel tak si vsichni stezovali ze je spatne udelany. Nepouziva totiz cache a data taha primo z databaze komplikovanym dotazem, a prave to zpusobuje to zpomaleni (na nasem serveru tento jeden dotaz trval 10 sekund, jine jsou v radu milisekund takze db je v poradku). Vetsinou vsichni udajne skoncili u Advanced Filter Pro 4, ale ten stoji tusim nejakych 250$ coz neni zrovna levna zalezitost. S tim APC to ale skutecne funguje, jediny problem je, ze presta se snazi cachovat prakticky vsechno, a pri vetsim mnozstvi produktu a pri vetsi navstevnosti se zacne strasne rychle cache fragmentovat. Pro kazdou navstivenou stranku s produktem to vytvorilo priblizne 100-200 promennych, u velkych kombinaci i vic. Vynasobte poctem produktu a zjistite ze to je uz mnohem vic, nez dokaze pamet udrzet.
  12. Jestli vam to situace dovoli, zkuste nechat na serveru APC zapnute, v BO APC vypnout a projdete si ruzne stranky, treba testem jako webpagetest nebo gtmetrix. Podle mych testu je homepage a product page nactena hluboko pod dve sekundy, jen ty kategorie kde je blocklayered zapnuty nacitaji 10-15 vterin. Kdyz zapnu APC i v BO, tak je to za 2 sekundy. Timhle testem jsem zjistil ze prave ten filter je pricinou a podle ostatnich adminu jim to dela taky ve chvili kdy maji hlavne ty kombinace. My mame neco malo pres 2000 produktu, kombinace jen barvu a u prstenu velikosti (ty prave delaji poradne mnozstvi kombinaci, protoze damska/panska velikost vytvari velke mnozstvi moznosti). Kdyz sem APC vypnul i na serveru, tak ta rychlost klesla vsude na osklive cisla. Takze souhlasim s vami, bez APC to moc nejde. Pokud se vam ale zacne obchod zpomalovat, zamerte se na filtr
  13. Ja to prave taky zkousel hnat do extremu az jeden giga, ale po tech tydnech googlovani, konfigurovani a zkouseni mi postupne vsechno "docvaklo". Kdykoliv nekde doporucovali nejakou konkretni konfiguraci APC, tak meli fragmentaci i nulovou. Toho jsem docilil jen ve chvili, kdy jsem v backofficu APC vypnul. Vsechny stranky fungovalyu mozna jeste o zdibec rychleji, krome kategorii, kde je blocklayered. Tady bych se zeptal: pouzivate tento modul? Kolik mate produktu a kombinaci? Podle ostatnich to zacne drasticky snizovat vykon s rostoucim poctem produktu a hlavne atributu. Ja se ted chystam tohodle modulu zbavit, cimz vyresim i problemy s APC, ale nejdriv musim zrejme modul sam udelat, protoze free alternativu jsem nikde nenasel. A rotoze potrebujem stejne jen filtry podle barev, tak by to nemelo byt tak tezke. Kazdopadne to cachovani v preste je fakt nejake divne, lepsi je to bez neho.
  14. Hello, I have a tricky question: Is it possible to disable cache (APC in my case) in prestashop BO to stop floofing APC by useless user cache entries, AND force some modules/files to still use the cache? My problem is that enabling APC in BO is useless and in fact slower the performance of site. Except of blocklayered module, this one is much faster with cache enabled. So I was curious if there is in php source code something like if (cache.isEnabled) -> set/get variable from cache else -> set/get variable where removing the condition will force to use the cache which is set correctly on server of course. Till I found some alternative for blocklayered module, this is the only solution I have on my mind at this moment... Thanks
  15. Hello, because blocklayered module is not working properly and is really slow, I am looking for free alternative. My expectations are not high, we want just simple block in left column with checkbox list of available color attributes for current category so visitor can filter 0-n colors in product list. Is there something similar? Or some workaround/blocklayered module modification? We don't need any other feature, just color filtering. I would appreciate any hints or suggestions, thanks.
  16. Hi, I am fighting with this module too. I know there are alternatives, but paid as far as I know and we can't afford them at this moment. So why debugging, I found out that blocklayered module IS cached by APC if enabled in BO. However pain in the *** is that besides this module also lot of other presta variables are cached and it cause high fragmentation soon. It would be good to force caching only for this module but I don't know how...
  17. Tu stranku znam, asi jsem uz prosel opravdu vsechno Ja mam ccc zatim pozapinane, precejen to slo poznat na rychlosti. Ale hned jak dostanem na server google PageSpeed modul, tak to povypinam. Neprekompilovavani sablon mam taky. Pisete ze mate cachovani dole uplne vypnute: jakou mate rychlost stranek? Ja postupnym zkousenim zjistil, ze u homepage kde nemam prakticky zadne produkty kvuli rychlosti neni rozdil postrehnutelny, ale na strankach kategorii a produktu, kde se uz s php pracuje o dost vic je to na rychlosti opravdu znat. Se zapnutym APC (zabehnutym, ale jeste nefragmentovany) neni problem dostat stranky pod dve sekundy na first view. Bez APC to byva k peti sekundam, coz je dost markantni. Jde proste poznat, ze presta predzvykava nejake php skripty nez posle uzivateli prvni data. Proto me zajima, jak rychle stranky mate vy a jak to pripadne resite. EDIT: Uz jsem to zrejme rozlustil. V preste je dobre mit APC vypnute, protoze presta cachovat umi jen mizerne. Jedina vec na co je dobra je prave blocklayered modul, kde bez apc je load page 10-15 sekund, s apc 2-3 sekundy. Ale mit zapnute cachovani jen kvuli jednomu modulu je dost nehezke reseni.
  18. Zdravim, google si vas casem sam najde, pokud na vas shop nekde vedou odkazy. Bez nich to muze byt dost na dlouho. Nejlepsi zpusob, jak o sobe dat googlu vedet, je zalozit si google webmasters tools ucet, tam je mimo spousty zajimavych veci i moznost nahrat sitemap soubor (presta ma modul na generaci). Staci zadat cestu k tomuto souboru a google zacne vase stranky zkoumat. Dovolim si jen upozornit, ze google indexuje jen stranky zajimave a vyhovujici urcitym parametrum, takze nepocitejte s tim ze vam zaindexuje 100% stranek. Je tam hodne kriterii, jako kvalitni obsah, popisky atd.
  19. Muzu se zeptat, jestli jeste mate nekde po ruce odkazy na to zabugovane cachovani? Resim totiz podobny problem, uz docela dlouho, ale o chybach jsem zatim nic nenasel. A jestli to neni tajemstvi, co vse jse vypnul?
  20. Zdravim, uz delsi dobu patram, jake je vlastne normalni chovani APC cachovani pro prestashop. Docela rozumim tomu, co to dela a jak funguje, ale uz mi neni jasne jestli je neco spatne u mne, nebo je to obecny problem. Takze k problemu. Konfiguraci tu ani davat nebudu, zkousel jsem uz vice variant a samozrejme vse podle doporuceni, lec bez vysledku. Kdyz v BO nezapnu APC, tak se mi v APC nacachujou jen php soubory, coz je logicke, ale zadne user entries. Podle testu je rychlost pomala, se zapnutym APC v BO je to o mnoho lepsi. Zaver tedy je, pouzivat APC. Jakmile vsak presta zacne cachovat user entries, okamzite narusta fragmentace. Ze zacatku jsou to jen desetinky procenta, cili nic cim bych se normalne stresoval. Je ale zvlastni ze uz v tu chvili k nejake fragmentaci dochazi, mel jsem za to ze to bude hazet jeden zaznam za druhym, dokud nedojde misto... Po case vsak pocet entries zacne narustat do takove miry, ze to chache nezvladne a vznikne 100% fragmentace. Postupne se mi povedlo toto chovani zpomalit, pomoci filtrovani nekterych souboru (block layered indexery, google sitemap...) v apc filter parametru, ale je to jen zpomaleni. Pozorovanim jsem si napriklad vsiml, ze kdyz ve FO navstivim nejakou produktovou stranku, pocet entries stoupne o 100-200 zaznamu. Jednouduchou matematikou si dokazu odvodi, ze pri 2000 produktech je to poradna varka zaznamu. A zrejme na tom moje cachovani pada, ve chvili kdy je vetsi navstevnost (nebo google crowler co projde vse?). Celkove tech dat v MB neni az tolik, cca 50MB pro soubory a obdobne pro promenne. Ale nakonec bylo jedno, jestli shm_size je 128 nebo cele giga, vzdycky to dopadlo stejne. Takze lidi zlati, prosim poradte nebo nasmerujte co se to vlastne deje? Doposud jsem nenasel zadnou relevantni odpoved jak vlastne funguje APC ostatnim prestashopakum, jen zasvecene navody na konfiguraci. Proste nechapu, proc k te fragmentaci dochazi, kdyz velikost cache je dostatecna, produkty na strankach jsme v posledni dobe vubec nemenili, takze obsah je v podstate staticky... Nemate nejake rady nazbyt prosim? EDIT: nasel jsem stranku, kde se o vysoke mire fragmentaci v cache kvuli tomu jak to ma presta spatne nastaveno bavi taky. Takze je to zrejme featura, coz me vede k myslence APC zapnout, protoze je benefit nesporny, ale primo v APC defaultni cachovani vypnout a definovat pozitivni filtry jen na soubory, ktere maji nejvice zasahu. Neni to uplne hezke reseni, ale v soucasne chvili je presta asi necachovatelna jinym zpusobem. Zkousel to uz nekdo podobnym zpusobem?
  21. I think I finally solved it. Besides the fact which Dh42 mentioned (thanks for the hints, good server configuration is not so easy...), problem was in WHAT was caching. I found out one 3rd party application on same server which created user cache entries with very low ttl and constantly recreated. When I turned it off, it was a little bit better than before. Further analysis showed that there are more php scripts which create too many cache entries: - cron - blocklayered module, to be more specific the indexers which are croned to reindex some values needed for filtering So I added filter parameter to apc and now it's ok, fragmentation between 2-4%. If somebody else have similar problem, I suggest to sort user cache entries by creation time, find blocks where many files were created in the same moment and analyze stored entries or check if some php file was cached in the same time. In my case it was indexers which are part of BO run once per night so there is no need to cache it.
  22. Found it finally. In case somebody is curious... First two requests belongs to Google Analytics and is probably used by almost everyone. Third request belongs to Google as well, but is related Advertising features. So in case you are not advertising or you don't need some specific statistics, you can disable it in your GA panel. See details here.
  23. Hello, I am tweaking and studying my e-shop to be as fast as possible. Today I noticed on WebPagetest that besides other things there is this: URL: http://www.google-analytics.com/plugins/ua/ec.js Loaded By: http://www.google-analytics.com/analytics.js:3 Host: www.google-analytics.com IP: 173.194.112.227 Error/Status Code: 200 Client Port: 61419 Request Start: 1.497 s Time to First Byte: 43 ms Content Download: ms Bytes In (downloaded): 1.7 KB Bytes Out (uploaded): 0.3 KB URL: http://www.google-analytics.com/r/collect?REMOVED_TOO_LONG Loaded By: http://eshop.kouzelna-svatba.cz/18-obchod:1 Host: www.google-analytics.com IP: 173.194.112.227 Error/Status Code: 302 Client Port: 61419 Request Start: 1.585 s Time to First Byte: 67 ms Content Download: ms Bytes In (downloaded): 0.9 KB Bytes Out (uploaded): 1.9 KB URL: https://stats.g.doubleclick.net/r/collect?v=1&aip=1&t=dc&_r=3&tid=UA-59199520-1&cid=654510997.1428502523&jid=814181501&_v=j34&z=1958616918 Loaded By: http://eshop.kouzelna-svatba.cz/18-obchod:1 Host: stats.g.doubleclick.net Error/Status Code: 200 Client Port: 0 Request Start: 2.219 s DNS Lookup: 33 ms Initial Connection: 48 ms SSL Negotiation: 485 ms Time to First Byte: 62 ms Content Download: 1 ms Bytes In (downloaded): 0.2 KB Bytes Out (uploaded): 0.6 KB I have installed google analytics module so I understand why first two scripts are present. But what is the last doubleclick one? I know it's from google as well, but what is it for and is it really needed? In this report it took 0.6s to load and it slows down the page load, it takec cca 20% of the time. Sometimes it's even 1s. Thanks for any oopinion.
  24. Hmm, I didn't even thought it can be related to workers. Related workers pool configuration is below. But thanks for suggestion, I will try to search today what should be set there. There should be some kind of manual from Prestashop provided what to be careful about, there are so many things to be set while they can really cripple the shop performance. If they would do that, Presta could be more competitive :/ POOL CONFIGURATION pm = dynamic pm.max_children = 50 pm.start_servers = 20 pm.max_requests = 500 ; Default Value: 0 ;request_terminate_timeout = 0 ; Default Value: yes ;clear_env = no PRESTA SITE CONFIGURATION fastcgi_read_timeout 1200s; include fastcgi_params; proxy_buffer_size 8k; NGINX CONFIGURATION worker_processes 64; pid /var/run/nginx.pid; events { worker_connections 768; # multi_accept on; } sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; # server_tokens off;
  25. Thanks for your opinion Dh42. After 14 hours of APC running fragmentation is on 30% in cca 10k fragments (on 1gb allocated memory). It seems that putting that table on blacklist for caching helped a lot, it's much better than before (fragmentation within few hours). But I am still wondered how much variables from prestashop are cached. User Cache Information Cached Variables 12025 ( 61.5 MBytes) Hits 719872 Misses 96331 Request Rate (hits, misses) 16.42 cache requests/second Hit Rate 14.48 cache requests/second Miss Rate 1.94 cache requests/second Insert Rate 13.64 cache requests/second Cache full count 0 And I think it's prestashop fault, when apc caching in presta was disabled, apc cache was ok. But even with 30% fragmentation performance is quite good, cca 2s for all pages which is not so bad for presta. So now it seems only solution is to have that modification set and clean cache from time to time. Does somebody else experience such behavior? How many variables are stored for your shop? There isn't written anywhere what is "normal" value
×
×
  • Create New...

Important Information

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