Website werkt traag....
http://www.dvcgraphics.com gaat zal je geredirect worden naar http://print.dvcgraphics.com
Waarom weet ik niet, moest van die mensen waar ik die site van gekocht heb.
Maar als je het eens test zal je zien dat alles traag gaat.
zelf een product kiezen duurt soms 20 seconden.
Aan wat zou dat kunnen liggen.
Alle andere sites op mijn server werken veel sneller.
als je naar Waarom weet ik niet, moest van die mensen waar ik die site van gekocht heb.
Maar als je het eens test zal je zien dat alles traag gaat.
zelf een product kiezen duurt soms 20 seconden.
Aan wat zou dat kunnen liggen.
Alle andere sites op mijn server werken veel sneller.
Als ik de W3C validator er op los laat dan zie ik: 238 Errors, 33 warning(s)
W3C wat is dat? Ik wil dit graag oplossen.
P.S. het valt me op dat er zoveel in de /cache zit
dat ik via FTP zelf vast zit te lopen telkens bestanden of een map wil verwijderen in de /cache.
File manager werkt ook niet in direct admin voor dit domein :(
De traagheid valt een hoop te verklaren:
- De server wordt zwaar belast
- De database wordt zwaar belast, en is niet goed geconfigureerd
- Er wordt een externe aanroep gedaan door PHP op de site, die traag laadt.
Met andere woorden, het kan zat oorzaken hebben. Profiling is daarom een handig idee, en ik heb geen idee of je OSCommerce (die gebruik je toch?) een debug-mogelijkheid kunt met een profiling-systeem. Aan de hand daarvan valt uit te zoeken wat de bottleneck is.
Verder zeg je dat de Filemanager niet werkt, maar wat werkt er dan niet precies?
Het duurt meer dan 11 seconden voordat ik een eerste antwoord krijgt. Daarna komt de rest van de in totaal 110 requests.
Je kunt het laden zien in de timeline die ik met fiddler heb gemaakt. (Opgeslagen in een evernote notitie)
http://www.evernote.com/l/ABrLA7QY84tDx4k7FBSDBqoIE4Yt8HN4i2s/
TJVB waarom werken de andere sites wel snel dan op dezelfde server?
Moet ik die cool png files lichter maken?
Toevoeging op 25/02/2015 14:57:46:
De server zelfs staat bij I3D.nl, vraag ik best om eens te checken en op te lossen?
Ik heb nog wat gratis remote hands..
Toevoeging op 25/02/2015 14:59:10:
Dus mijn volgend werk is om alle fouten op http://validator.w3.org/check?uri=http%3A%2F%2Fprint.dvcgraphics.com&charset=%28detect+automatically%29&doctype=Inline&group=0 op te lossen?
Optimaliseer dat eerst maar eens.
- wat vertellen je (error)logs, en hoe groot zijn deze
- trage/inefficiënte queries (database hoeft niet eens zwaar belast te worden, in de zin dat er veel queries worden uitgevoerd)
@Aar, dat zou het ten dele kunnen verklaren (en het mag wel wat minder zijn dan 5 MB) naar als je browser cache aan staat, dan zou alleen de eerste keer dat de site laadt traag moeten zijn. De laadtijd van de pagina zelf is nog steeds relatief hoog, maar het kan ook zijn dat een hoge load (die weer wordt veroorzaakt door de hoeveelheid content die geserveerd moet worden) de veroorzaker hier van is (in dat geval spelen er dus meerdere issues die vervolgens elkaar gaan versterken).
Je zou dit snel kunnen testen en uit kunnen sluiten door de afbeeldingen door een aantal lage resolutie varianten te vervangen en te kijken of (na verloop van tijd) de laadtijd (flink) lager wordt. Zoniet, dan zit het probleem toch meer in de opbouw van de pagina, en niet zozeer in simpelweg de hoevoeelheid data.
Soms duurt het bijna 1 minuut zeg :(
Die staan buiten je webroot, en kan je in DirectAdmin ook zien bij de Domain Management
Ik acht dit vroeger ook gehoord te hebben:
Beste Didier,
Wanneer het script zelf verschillende webshops ondersteunt, dan zal dit zeer waarschijnlijk werken met een catch-all subdomain dat automatisch naam.print.dvcgraphics.com uitleest en door verwijst naar een website met webshop naam. Omdat ik de naam en ontwikkelaar van dit script niet uit mijn hoofd weet, kan ik enkel mijn vermoeden hierbij delen. Ik vermoed dat dit dus een PHP script is in combinatie met ModWrite wordt afgevangen en vervolgens wordt geredirect met PHP.
Wat u op dit moment heeft gedaan is binnen DirectAdmin een apart subdomein aangemaakt, dat als aparte website wordt gezien. Zodra u nu op FTP inlogt, ziet u als het goed is onder 'domains' ook het domein mlm.print.dvcgraphics.com verschijnen. Hierop staat ook de pagina index.html dat nu als placeholder dient.
Op dit moment zie ik twee mogelijke oplossingen, afhankelijk van de haast en doel van de nieuwe webshop.
Indien u enkel van plan bent om enkel mlm.print.dvcgraphics.com te gebruiken niet nog meer winkels op te zetten, dan is het ook mogelijk om specifiek voor deze website een aparte database aan te maken en alle bestanden voor de webshop naar de nieuwe map te kopiëren en de juiste configuratie-instellingen aan te passen zodat deze ook werkt voor het mlm subdomein.
Wanneer u meer webshops op wilt zetten op een simpelere manier, dan zult u de configuratie met een catch-all domain en ModRewrite moeten opzetten - er vanuit gaande dat dit ondersteunt wordt door het webshop script. In principe zou het ook mogelijk moeten zijn om dit door een Webhosting Engineer vanuit i3D te laten uitvoeren.
Best regards,
Er staat mij iets van mij dat Google moeite heeft met indexeren van sub-sub-domeinen, plus dat het ook nog eens 'te lang' en verwarrend is voor de klanten van je gebruikers.
Magento is bijvoorbeeld erg traag als je het op een simpele VPS of shared-hosting draait.