Har du en benchmark reference ? |
Søren.Pedersen:
Så giver du mig jo også ret. Jeg skriver jo NETOP, at jeg vil gøre forsøget med den eksterne DB, men hvis det kræver MERE END DET, så gider jeg ikke lige pt.
Har du en benchmark reference ? |
SAFe SPC, Magento Expert, Jira Guru, Kammalou.com
Så giver du mig jo også ret. Jeg skriver jo NETOP, at jeg vil gøre forsøget med den eksterne DB, men hvis det kræver MERE END DET, så gider jeg ikke lige pt. |
allanisaksen.dk - Online Digital Assistent
Et tal mener du? Jeg får ca 3.4-3.5 sekunder hvor jeg tester |
Den BENCHMARK test er så ubrugelig. Hvis man tror den er brugbar til noget, så er det fordi man ikke ved bedre. Jeg hiver lige et gammelt (men dog relevant) svar frem igen: Den SQL-forespørgsel du laver er ikke brugbar til at teste SQL-performance med. Forespørgslen beder MySQL om at udregne hvilket årstal det er i øjeblikket. Det er i sagens natur ikke et kompliceret spørgsmål, og derfor testes det 1 milliard gange i træk, for overhovedet at tage så lang tid at man kan måle det. Det er selvsagt ikke en query man nogensinde ville bruge i virkeligheden :-) |
Screenshot or it didn't happen. Fik jeg ikke forklaret dig klart nok at den test ikke er brugbar, og at de magiske tal du kunne hive frem, ikke stemte overens med dem jeg hev frem, fra samme udbyder, fra samme server? |
Gud troede du var død. Ingen snakker om at testen kan bruges eller ej, vi er alle godt bekendt med at f.eks en bils egenskaber er andet end bare motoren, men lad os da vide motorens performance inden vi snakker undervogn etc etc. Man må vel ligeledes formode at en udbyder, ingen nævnt ingen glemt, der har hurtige CPU'er, brugbar information iflg dig eller ej, ligeledes har hurtige disksystemer eller ej. Giver dig iøvrigt ikke ret, meget data er allerede I en MySQL servers cache memory og netop CPU/memory IO er ved sådanne operationer mere vigtige end disk IO (ved select statements hvilket sandsynligvis er det der foretages det meste af tiden) da det jo netop er CPU der leverer data fra ram og ikke fra disken.
|
Så skal det godt nok også være simple. og tabellerne super indexerede. med både index, tabller og joins gemt i mem. Vi skal iøvrigt også passe meget på med InnoDB Transaction Log, Disk Commits, Hvilke er, af praktiske årsager, svære at bevare i memory. |
SAFe SPC, Magento Expert, Jira Guru, Kammalou.com
er det vel for det meste også, ved du mere om end jeg :-) |
Ved godt det er en gammel tråd, men ligesom op så leger jeg lidt med magento på surftowns business premium. Kan også genkende oplevelsen med at systemet virker meget trægt. Jeg er overbevist om det skyldes dårlig performance fra surftowns side. Jeg har lavet en såkaldt reverse ip lookup på mit domaine, her kan jeg se hvilke andre domaine der er hostet på samme server. Vi har en shop hos golden planet, her er der eksempelvis i alt 18 forskellige domainer på serveren. Når jeg laver lookup på domaine ved surftown så får jeg et chokerende resultat, mit domaine er delt med 463 andre domainer, her incl. domainer som www.sexdiscount.dk & livsstilsexpo.se som sikkert er domainer med mange brugere og aktivitet. Jeg er overrasket over man kan betale så meget for en business premium og så dele servere med så mange andre domainer. I kan selv prøve at slå jeres domaine op her www.yougetsignal.com/tools/web-sites-on-web-server/ Edit: har lige fundet en mulighed i surftowns adminpanel hvor jeg kan ændre min ip fra delt til dedikeret, der kan dog gå op til 24 timer før ændringen går igennem. Jeg har lige ændret min, prøver lige at komme med feedback inden længe for at se om det har en indvirkning |