Hvis alt vi snakker i, er Ghz, og og beregninger, hvorfor laver man så CPU'er med mindre gigahertz end man gjorde for 2-3 år siden? Søren, der er en grund til at rigtig mange CPU'er til servere idag, bliver leveret med flere cores, mere cache, og mindre gigahertz. Mange af de nye CPU'er idag, beregner måske single thread data lidt langsommere, end nogle gjorde for noget tid siden. Og efter min mening (Og nok også resten af verden, undtaget dig) - har scalability og performance under høj load, da en del mere at sige, end "Jeg kan beregne 10.000 if statements hurtigere end din server, dog kan jeg kun klare 10 besøgende". Vi lever i en verden hvor IT og internettet bliver mere og mere vores hverdag, vi stiller flere krav, til at ting skal kunne klare mange besøgende. Performance != scalability - kan godt være det er i dine øjne, men tror sku store IT virksomheder der arbejder med mange millioner besøgende, har lidt mere styr på hvordan man skalere og hvad der skal til. Ja jeg ved godt, at x magento shop, måske ikke har millioner af besøgende, men man må forvente at antallet af besøgende på sin side skal have lov at vokse, og kunne klare mange concurrent users. Så skal man da ikke vælge host x fordi de kan lave 10k if/else statements mere, hvis host y, kan klare langt flere besøgende. Jeg kender utrolig mange folk, der har haft en side hosted ved et udenlandsk firma, hvor at scriptet ovenfor kørte måske 5% hurtigere, men alligevel når siden fik besøgende så begyndte siden at få timeouts etc, fordi deres infrastruktur simpelthen ikke kunne følge med (selvom deres CPU kunne beregne PHP hurtigere (Som jo er UTROLIG vigtigt i din verden)), men x host, som var 5% langsommere, kunne klare 40-50 gange mere trafik uden problemer, og overall loading tid, faldt i sidste ende alligevel. Så ja, jeg har en mening baseret på facts om at vi lever i en verden der skal skalere. Alle der arbejder med scalable sites, ved også - at skalere betyder oftest du mister en lille bitte smule performance. Men hvis x script bliver kørt 5% hurtigere på server x end y, og du kan leve med at have lille antal besøgende, så er det vel helt fint. Men fra jeg tror mange synspunkt, har mængden af concurrent users en del mere at sige. Jeg ved godt du ikke er enig med mig, og det ved jeg du aldrig bliver, så ja, folk fra Amino og sikkert også alle andre steder, kan fylde dig med facts, som er bevist af også store virksomheder, men alligevel, vil de 5% altid betyde mere - de 5% af en test der intet siger omkring skalering. Du må meget undskylde hvis jeg træder dig over dine tæer |
Jeg skriver nu ikke KUN at de skal truncate databasen, jeg skriver de skal rydde op i den. og ja det siger lidt sig selv at man på en shared host påvirker hinanden, derfor er det endnu mere vigtigt, som jeg har sagt før, at man holder sin røv fri, og sørger for at alt spiller, også databasen.Nils:Kim Tetzlaff - KTJ-Media.dk:Ryd op i databasen, og fjern overheadDet kan være svært at sikre MySQL' bliver trimmet ved kun at truncate denne ene db. -Hvis mysql'ens generelle INNODB Mem er fyldt. Så skal der mere til.
Det er typisk tilfældet på en shared hosting at man er påvirket af alle de andre magento sites load på MySQL'en.
har ikke set på deres server, kun på deres løsning.Nils:Kim Tetzlaff - KTJ-Media.dk:Se på jeres htaccess fil, hvis i har sådan en, om den kan justeres og forbedres, og hvis noget af det kan komme ind serversidet, kan det være endnu bedre for performance : http://www.ktj-media.dk/blog/htaccess-indflydelse-performance/.htaccess kan ikke bruges til noget. Sitet er hosted på en nginx. Med mindre de har ændret i HTTP Header svaret.
Der vil vi nok altid være uenige.. jeg er ikke af den overbevisning at selvom den kode der er bag sitet er noget skod, så skal hosten kompenserer for dette. Skal selvfølgelig ikke kunne sige om der er lavet noget skod kode på sitet, eller om det er hosten den er gal med, men det er ret tit sådan at det er skodkode der er synderen.Nils:PingDom siger at initial svar på serveren ligger på 7-11 sekunder. - Det er ret lang tid. (Det kan/skal magentohotel klare på deres servere)
MVH Kim Tetzlaff