PDA

Bekijk Volledige Versie : Trage webshop



GF87
03/07/13, 00:15
Hallo

Momenteel werk ik op een Magento webshop voor mijn bijberoep. Ik gebruik hiervoor "Magento Optimized" hosting bij Combell. Helaas is de webshop nog steeds traag, Pingdom Tools zegt: laadtijd 7s, 62 requests, page size 1,7mb. Onaanvaardbaar & met zo'n snelheid wil ik mijn producten niet lanceren

Het lijkt er op dat er serieus wat queries gebeuren voordat de webshop wordt ingeladen? En waarom een page size van 1,7mb, dat lijkt me bijzonder groot?

Wat er al is gebeurd:

1) Geen onnodige extensions
2) afbeeldingen geoptimaliseerd
2) javascript, media etc op subdomeinen
3) APC in php settings geactiveerd
4) Gzip geactiveerd

Iemand nog tips om te verbeteren? Of is overstappen naar betere hosting (VPS) de enige optie in dit geval? Ik ken helaas geen BAL van hosting.

Alleszins bedankt!

Groeten

The-BosS
03/07/13, 00:51
Ik zou zeggen zet eens een simpele phpinfo.php (of andere php code) op je server en doe daar eens een pingdom check van, misschien je "magento optimized" hosting bij combell gewoon zo al traag. En bouw deze test dan even uit met 1 sql query of meerdere om te zien of het probleem niet bij de mysql server zit, in het geval dit allemaal goed werkt zal je het toch in je magento code moeten zoeken en zal een overstap naar andere hosting/vps niet veel uithalen.

phpinfo.php:

<?php phpinfo(); ?>

SF-Jeroen
03/07/13, 09:10
Gebruik van een backend cache (Redis/Memcached) en/of frontend cache (Varnish). Let wel op dat de laatste nog wel lastig kan zijn om goed te configureren met je webshop, de eerste 2 werken min of meer out-of-the-box met Magento.

magentohosting
03/07/13, 09:54
Heb je het probleem ook al bij Combell neergelegd? Bieden zij opties gebruik te maken van Memcached / Reddis, APC of Varnish?
Was je shop trouwens altijd al langzaam of is dit pas sinds kort?

Wat SF-Jeroen ook zegt: Varnish kan lastig zijn te configureren. Gelukkig zijn er een aantal modules voor Magento beschikbaar waarmee het een stuk eenvoudiger wordt. PageCache is hier een voorbeeld van. Desondanks blijft het niet iets wat je 'zo even' implementeert. Of je Varnish kunt gaan gebruiken is ook maar net afhankelijk van het shared platform.

Ik mag hopen dat de 7s laadtijd die je krijgt is bij een productoverview o.i.d.? Dan nog is het overigens aan de erg hoge kant.
Hoeveel producten staan er +- in je shop?
Alle caches binnen Magento staan aan? (lijkt me dat je dat gechecked hebt. Wij hadden onlangs een klant die ook aangaf dat het traag was, maar hier bleken alle Magento caches uitgezet te zijn door een ontwikkelaar...).

GF87
03/07/13, 09:54
Bedankt voor de info.

Via de helpdesk ben ik te weten gekomen dat de "magento optimized" hosting op 128mb loopt, terwijl het minimum toch wel 512mb is voor deze CMS. Volgens hun zou dat "bij de meeste shops" prima moeten werken, maar niet bij mij dus. Van specifieke Magento hosting verwacht ik toch meer dan dit ;-)

Maar ik wil dus eerst uitspitten of het inderdaad mijn site is of de hosting of een combinatie van de twee. Van die phpinfo & cache bak ik zelf weinig, maar ik zal het doorgeven aan de persoon die de eerdere aanpassingen al heeft gedaan.

Nog andere tips & feedback is natuurlijk welkom.

Bedankt al!

*edit*

Zie net het bericht hierboven: ik heb hun helpdesk inderdaad gecontacteerd met de reactie vermeld hierboven ("het werkt bij de meeste"). Voor de rest zijn er - voor zover ik weet - geen opties, maar ik kan het wel navragen. Ik heb alleszins al tweemaal een mail gestuurd en het komt er steeds op neer dat IK de aanpassingen moeten doen. Ik vrees dat ze met dit type hosting weinig extra service geven.

De webshop is altijd al traag geweest, voornamelijk de homepage. Bij het surfen van pagina tot pagina valt het nog mee (maar niet ideaal), maar het is vooral die initiële laadtijd die mij zorgen baart.

Het is een niche webshop, max 50 producten. Alles staat aangevinkt onder Cache Management.

Indien je een link naar de webshop wil, kan ik je die wel geven via PM :)

SF-Jeroen
03/07/13, 12:39
Alles staat aangevinkt onder Cache Management.

Standaard wordt de Magento cache op disk opgeslagen (wat traag is). Redis en Memcached bieden daarin een alternatief om het in het geheugen op te slaan (in het geval van Redis helemaal, en bij Memcache deels). Hierdoor zijn acties waarbij gezocht moet worden door de metadata files van de cache een stuk sneller. Door gebruik te maken van Full Page Cache (standaard in Enterprise) of via een gratis module (zie magento_connect) kan je de snelheid een stuk opkrikken icm met Redis/Memcache

GF87
03/07/13, 13:22
Bedoel je deze? http://www.magentocommerce.com/magento-connect/zoom-full-page-cache-1742.html

En is VPS gegarandeerd beter dan shared hosting?
En wat raden jullie dan minimum aan voor een startende webshop? (250 à 500 bezoekrs/maand, 50 producten)

RichardVD
03/07/13, 13:37
Een VPS is niet gegarandeerd beter dan shared hosting. Ook hoeft "Magento Optimized" van partij x niet beter te zijn dan shared hosting van partij y. Helaas is het vaak maar een sticker die erop word geplakt.

Kijk niet alleen naar de hosting maar ook naar de template en de modules die nog actief zijn. Helemaal bij een standaard aangekochte template want daar zit veel verschil in.

Wellicht verstandig om iemand met meer Magento ervaring erna te laten kijken, die kan sneller zien met welke aanpassingen de snelheid te verbeteren is.

SF-Jeroen
03/07/13, 13:52
Bedoel je deze? http://www.magentocommerce.com/magento-connect/zoom-full-page-cache-1742.html

En is VPS gegarandeerd beter dan shared hosting?
En wat raden jullie dan minimum aan voor een startende webshop? (250 à 500 bezoekrs/maand, 50 producten)

Ik zou niet zomaar voor een willekeurige VPS gaan. Vooral MySQL performance kan erg belangrijk zijn en dat is niet
altijd optimaal op een vps. Wat betreft Zoom, die kan je gebruiken ja, wij gebruiken vaak Lesti_FPC (omdat die ook met Redis werkt).

magentohosting
03/07/13, 14:22
Een shop van dat formaat zou makkelijk zonder problemen op een shared omgeving moeten kunnen draaien (mits geen overselling, snelle servers, caching, etc.).
Een VPS biedt je wel de mogelijkheden voor full page caching. Je geeft aan geen bal van hosting te weten, dus dan zou ik aanraden om wel een managed VPS af te nemen mocht je daarvoor kiezen. En laat daar even goed op wat de betreffende hostingpartij onder "managed" vindt vallen..

Bij een shared hostingpakket zul je qua prijs voordeliger uit zijn. Een goede VPS zal je misschien voor +- dezelfde prijs als een shared pakket kunnen vinden, maar daar komt dan nog wat overheen voor het "managed"-stukje.

SF-Jeroen
03/07/13, 14:50
Afhankelijk van de hoster kan FPC natuurlijk ook op shared hosting.

magentohosting
03/07/13, 15:12
Afhankelijk van de hoster kan FPC natuurlijk ook op shared hosting.

Klopt inderdaad.

frederikbove
03/07/13, 16:19
Soms is het voor eindgebruikers denk ik moeilijk om te weten hoe of wat. Want de ene shared hosting is de andere niet. En net het zelfde met vpssen.

Dus ik snap zijn probleem wel. Hosters zeggen ook nog al snel dat het niet aan hun ligt

GF87
03/07/13, 16:25
Iemand een idee wie ik dan kan contacteren om eens te controleren waar het probleem echt ligt dan? Want van hosting veranderen wanneer het eigenlijk de template is die voor problemen zorgt, is ook een verspilling van tijd en resources :)

Heb al even op Google gezocht, maar ik zoek blijkbaar op de verkeerde termen.

SF-Jeroen
03/07/13, 16:37
Ik zou dan SupportDesk (www.supportdesk.nu) aanraden, die zijn gespecialiseerd in de wat kleinere losse jobs zoals deze.

Randy
03/07/13, 17:00
APC installeren zonder deze te activeren in Magento is zinloos.
Cache installeren op disk is vrij zinloos (gebruik tmpfs in geheugen, kan niet op shared hosting)
Magento optimaliseren zonder bij MySQL te beginnen is zinloos.
GZip aanzetten zinder naar mod_expires te kijken is zinloos.
Cache aanzetten op een webshop zonder bezoekers geeft geen reeel beeld.
Heb je voor een 'Flat catalog' gekozen in de configuratie?

Zoals je leest, genoeg zaken om aan te pakken maar enkel het samenspel tussen alle factoren zal je helpen.

Randy
03/07/13, 17:01
APC installeren zonder deze te activeren in Magento is zinloos.
Cache installeren op disk is vrij zinloos (gebruik tmpfs in geheugen, kan niet op shared hosting)
Magento optimaliseren zonder bij MySQL te beginnen is zinloos.
GZip aanzetten zinder naar mod_expires te kijken is zinloos.
Cache aanzetten op een webshop zonder bezoekers geeft geen reeel beeld.
Heb je voor een 'Flat catalog' gekozen in d

Zoals je leest, genoeg zaken om aan te pakken maar enkel het samenspel tussen alle factoren zal je helpen.

PimEffting
03/07/13, 21:28
Shared hosting biedt je niet de controle en stabiliteit waar Magento zich prettig bij voelt. Het is nou eenmaal een zwaar pakket.
Een paar tips (sommige zijn al gegeven):
- Zorg ervoor dat je Magento zo licht mogelijk is. Schakel onnodige modules uit. Comprimeer je plaatjes voordat je ze upload.
- Check je database. Soms zitten hier tabellen met 100.000 regels in (voor de logging). Die kun je veilig truncaten.
- Controleer je var/sessions map. Soms wordt die niet opgeschoond met tienduizenden files tot gevolg. Je raadt de gevolgen al.
- Heb je de crons goed ingesteld? Die ruimen ook op en vergeet ook de indexer niet af-en-toe te draaien.
- De hoster kan veel doen op je server. Zoals apc-caching, Nginx, php-fpm, noem maar op. Maar daar heb je als shared hosting klant niets aan.
- Overweeg een full page caching module. Een klant van ons heeft goede ervaringen met http://www.magentocommerce.com/magento-connect/lesti-fpc-4534.html

SF-Jeroen
03/07/13, 21:42
Er hoeft natuurlijk geen enkel verschil in performance te zijn tussen een shared hosting pakket en een vps, soms zal shared hosting zelfs sneller zijn. Het hangt allemaal van de hardware, software en overselling af. Sommige hosters hebben voor shared magento hosting zware servers met SSD storage en diverse mogelijkheden tot caching beschikbaar, met soms zelfs losse databaseservers. In praktijk is dit vaak sneller dan een VPS (omdat je meer iops hebt). Maar zoals gezegd; het hangt van talloze factoren af.

GF87
05/07/13, 13:28
Ter info, dit is de mail die ik kreeg van Combell :

"De website mijnsite.com staat op onze nieuwe hosting. Belangrijk om weten is dat Magento eigenlijk helemaal geen product is om op Shared Hosting te plaatsen. Dit omdat de developers van Magento aangeven dat hun applicatie minimaal 512 MB ram in de PHP_MEMORY_LIMIT nodig heeft.
Op onze shared hosting kan u maximaal 128 MB PHP_MEMORY_LIMIT verkrijgen. Dit gezegd zijnde is het wel zo dat er enorm veel klanten toch Magento draaien op shared hosting, zij het met enig performantieverlies. Het is dus perfect mogelijk om Magento ook te draaien met minder ram-geheugen beschikbaar per bezoeker, maar hou in het achterhoofd dat deze nooit razendsnel zal zijn. Maar omdat de benodigde opstelling om Magento op piekperformantie te kunnen laten draaien bijzonder zware investeringen met zich meebrengt, starten vrijwel alle webshop toch met Shared Hosting.

Een van de tools die wij gebruiken is Firebug. Met deze plugin voor Mozilla Firefox kunnen wij een analyse maken van de laadtijd en specifiek zien welke elementen toedragen aan de laadtijd.
Met deze tool kom ik op een totale laadtijd van 4,81 seconden, wat voor een Magento-website zeker niet slecht is.
Ik zie dat er geen structurele grote vertragingen zijn, maar vooral veel kleinere elementen die elk een beperkt aantal miliseconden aan de laadtijd toevoegen.
In bijlage kan u hiervan een secreenshot bekijken.

Ik zie alvast dat u gebruikt maakt van meerdere subdomeinen om de laadtijd te bespoedigen, wat uiteraard de performantie ten goede zal komen. Ik stel wel vast dat er erg veel elementen via static.mijnsite.com worden ingeladen. Dit kan, mijn inziens nog verder geoptimaliseerd worden door bijvoorbeeld het aantal elementen per subdomein te beperken tot 6 tot 8. Zo kan u gebruik maken van meer simultane downloads in de browser om de website nog sneller in te laden. Bij de meeste recente browsers is het aantal simultane downloads beperkt tot 6 of 8 per domein.
Dit kan de laadtijd nog verder reduceren."

Ramon Fincken
05/07/13, 15:44
Nette mail, maar met extra (sub) domeinen gaat je site niet ineens vliegen als je PHP/mysql -> dus HTML stuk al seconden nodig heeft.

The-BosS
05/07/13, 18:52
Inderdaad een net antwoord van combell, alhoewel ik mij toch even wat vragen stel bij hun "magenta hosting", op hun website staat het volgende te lezen: "Magento geoptimaliseerde servers". Waarom komen ze in die e-mail dan af met een beperking van 128MB per hosting account als ze zelf al aangeven dat dit eigenlijk 512MB zou moeten zijn, dat is dus juist het tegenovergestelde van geoptimaliseerd wat mij betreft. En dus een grondig punt voor de TS om dit aan te halen, dan kun je net zo goed ergens een hosting nemen die niet magenta geoptimaliseerd is, maar wel standaard 256MB of 512MB ram per account toe laat ;).

GF87
06/07/13, 12:57
Inderdaad, dat was wat mij behoorlijk tegen zat. Ze verkopen een "magento optimized" server, maar die is dan uiteindelijk toch niet zo geoptimaliseerd volgens hun eigen woorden.

Iemand op dit forum was zo vriendelijk om mijn webshop even volledig te hosten op hun servers: bijna 4 seconden sneller! Ook de back-end is supersnel, terwijl dat bij Combell vreselijk traag is ...

GF87
16/07/13, 13:52
Webshop ondertussen volledig overgezet, wereld van verschil. Vanmorgen even getest: site laadt onder de 2 seconden, daarvoor +9.
Ondertussen annulering bij Combell aangevraagd. Ze weigeren wel terug te betalen voor de maanden na annulering omdat het een contract van 1 jaar is. Alleszins de laatste keer dat ik daar langs ga :)

tvm
20/07/13, 12:59
in principe dienen ze terug te betalen. Valse verkoopsbeweringen, ik zou hen dit alvast laten weten en vragen opm een commerciële toegift.

ThijsFeryn
28/07/13, 11:53
Beste GF8

Het is spijtig dat je Magento webshop niet sneller performat op onze shared hosting omgeving. We hebben intussen al wat ervaring opgedaan met Magento installaties en kennen de pijnpunten.

Deze ervaring heeft ervoor gezorgd dat we bij Combell achter de schermen een nieuw type hosting product aan het uitbouwen zijn die nog beter overweg kan met veeleisende pakketten zoals Magento.

Ik merk dat er in deze forum thread al heel wat informatie staat en tips gegeven zijn. Bepaalde van deze opmerkingen zijn terecht, andere zaken zijn niet correct in deze context.

Het is duidelijk dat Magento veel geheugen nodig heeft. De memory_limit kan bij onze gewone hosting pakketten op 128 MB gezet worden. Bij ons nieuw product zal de limiet nog veel hoger liggen. Maar ik moet wel duidelijk maken dat memory_limit en performance hier niets met elkaar te maken hebben.

De memory_limit bepaalt hoeveel geheugen elke PHP request krijgt voor de verwerking van scripts. Meer memory betekent niet snellere verwerking. Het feit dat Magento op 128 MB foutloos werkt (maar jammergenoeg wel traag) bewijst dit. Mochten er fouten optreden in het genre "Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes)", dan is het duidelijk dat bepaalde Magento modules te weinig geheugen hebben om correct te werken.

APC is wel degelijk actief op deze omgeving en kan gebruikt worden zowel om het compilatieproces van PHP scripts te versnellen, als voor de caching binnen Magento. Spijtig genoeg zijn hier ook beperkingen op in combinatie met FastCGI: er is geen master proces die cache geheugen ter beschikking stelt. Elke klant krijgt bij ons meerdere aparte PHP processen toegewezen die elk hun eigen geheugen hebben. Het gevolg is dat er een APC cache per proces is.

Ons R&D team is onderzoek aan het doen naar alternatieve connectoren voor Apache en PHP. Momenteel gebruiken we nog FCGID, dit zal in de toekomst waarschijnlijk wel veranderen om een centrale memory pool te hebben waar APC gebruik van kan maken.

Niet tegenstaande wij streven naar een optimalisatie van onze PHP setup, komt de Magento vertraging niet van PHP zelf. De modules zijn optimaal geconfigureerd en geselecteerd en "normale" sites draaien bijzonder snel. Een terecht opmerking die in deze thread gemeld werd is dat Magento heel sterk gebruik maakt van disk caching.

We kunnen in de 2-step cache andere caching engines koppelen zoals bijvoorbeeld APC of Memcached. APC wordt nu al ondersteund (maar zoals vermeld met beperkingen), maar Memcached komt er op middellange termijn ook aan. Klanten zullen bij ons Memcached buckets kunnen afnemen en koppelen in de local.xml van Magento.

Maar hoewel Memcached caching een duidelijk verschil zal maken, berust de backend nog steeds op disk caching. Om deze vertraging te tackelen zullen we op ons nieuw product ook RAM disks aanbieden. Dit zijn dedicated schijfvolumes die klanten aangeboden krijgen waarvan de opslag in het geheugen zit. Bèta tests hebben aangetoond dat dit de belangrijkste maatregel is. Verschillende van onze klanten hebben dit getest en goed bevonden.

Ten slotte is een Varnish As A Service product ook in de maak, afhankelijk van de Magento configuratie zal dit ook wel een impact hebben. De grootste beperking hier is dat Varnish geen "user specific content" zal cachen. Vanaf dat een bezoeker iets in zijn winkelmandje stopt, zal Varnish het verdere verloop niet meer cachen. Dit is geen fout, maar is "by design" aangezien cookies niet zo gecached worden.

Varnish zal wel een degelijke hit rate hebben als er op de productpagina's geen cookies gebruikt worden. Als een gebruiker zonder in te loggen kan navigeren naar de producten, zal Varnish zorgen voor laadtijden van enkele milliseconden in plaats van 7 seconden.

Varnish kan niet overweg met SSL verbindingen, in een eerste fase zullen we dus enkel non-SSL traffic via Varnish kunnen verwerken. Later zullen we de SSL connectie termineren op een toestel voor de Varnish server, waardoor SSL connecties wel zullen werken.

Conclusie: we zijn ons bewust van de beperkingen. Helaas is elke Magento anders en sommige Magento installaties kunnen performant op onze omgeving draaien, andere installaties vereisen specifieke maatregelen. Ik vat nog even de shortlist samen:

- Plaats de /var/cache map op RAM disks
- Gebruik Memcached als cache in local.xml
- Gebruik eventueel Varnish om non-SSL traffic te cachen die niet user specific is
- Activeer flat catalogs om MySQL laadtijden laag te houden

Ik stel voor dat GF8 me een mailtje naar me stuurt op thijs at combellgroup dot com zodat we de hosting in kwestie even kunnen onderzoeken. In afwachting van dit nieuwe product, kunnen Memcached en RAM disks al gratis in bèta getest worden. Het verschil zal duidelijk zijn ;-)

Hopelijk heb ik via deze weg het één en het ander duidelijk kunnen maken. Mochten er nog vragen zijn, dan mag je me zeker contacteren op thijs at combellgroup dot com. Ik wil GF8 en andere mensen die vragen hebben ook gerust telefonisch te woord staan. Hiervoor bel je best naar onze support afdeling op 0800/85678 vanuit België en 0800/8567890 vanuit het buitenland.

Mvg
Thijs Feryn
Combell

necrosis
29/07/13, 23:54
Dit kan ik zeer zeker beamen! Ik zelf gebruik momenteel opencart. Vrij licht en op een 1 GB shared VPS loopt dat vrij vlot.

The-BosS
30/07/13, 00:58
Varnish kan niet overweg met SSL verbindingen, in een eerste fase zullen we dus enkel non-SSL traffic via Varnish kunnen verwerken. Later zullen we de SSL connectie termineren op een toestel voor de Varnish server, waardoor SSL connecties wel zullen werken.

Niet om afbreuk te doen op je volledige uitleg, maar hier had ik toch even mijn bedenkingen bij aangezien dit kortom totaal nog niet bruikbaar is bij een webshop, want een (goede) webshop zal altijd via een ssl connectie verlopen.


Dit kan ik zeer zeker beamen! Ik zelf gebruik momenteel opencart. Vrij licht en op een 1 GB shared VPS loopt dat vrij vlot.

En wat heeft dat er mee te zien, shared hosting is verschillend van een VPS, naast het feit dat opencart en magento ook totaal verschillende programma's zijn.

ThijsFeryn
30/07/13, 13:02
Niet om afbreuk te doen op je volledige uitleg, maar hier had ik toch even mijn bedenkingen bij aangezien dit kortom totaal nog niet bruikbaar is bij een webshop, want een (goede) webshop zal altijd via een ssl connectie verlopen.


Ik moet je 100% gelijk geven, maar onze Varnish As A Service opstelling is niet enkel gemaakt voor webshops. Vandaar dat we eerst verkiezen om het zonder SSL te lanceren zodat we Drupal, Wordpress en andere installaties ook kunnen versnellen. Het termineren van SSL verbindingen op zich is niet zo moeilijk, maar ervoor zorgen dat klanten hun SSL certificaten en uniek IP-adres meteen correct gekoppeld staat is heel wat complexer.

We zouden liefst eerste lanceren en zorgen dat klanten (niet noodzakelijk Magento gebruikers) een werkbaar product hebben, om dan later in een tweede fase meteen SSL aan te bieden en het Magento publiek aan te spreken.

Ik sta in contact met verschillende invloedrijke Magento integratoren en ze zeggen stuk voor stuk dat Varnish en Magento niet altijd naadloos is. E-commerce vereist veel user-specific content (shopping cart, prijzen op maat, inlogsessies, ...). Dit zorgt ervoor dat de hit rate van Varnish vrij laag is.

Meer en meer Magento integratoren zijn bezig met het gebruik van Edge Side Includes om de hit rate te verhogen, maar het resultaat is verre van acceptabel.

Net daarom dat ik vooral zou inzetten op RAM disks en Memcached (of Redis). Voor Magento enterprise klanten schijnt Full Page Cache dan weer heel wat voordelen te bieden, maar het prijskaartje hiervoor is navenant.

Mvg
Thijs