Meget treg nettside på en rask server

[Gavekort]

Hei!

 

Jeg har da en hjemmeside som du kan se i signaturen min. Som du sikkert merker, så er nettsiden ganske treg.

Websiden kjører Concrete5 som er et delvis tungt CMS, men det skal ikke være noe ytelses-problem for andre.

 

Serveren kjører CentOS, PHP 5.2 og nyeste MySQL. Jeg har 2,5GB med RAM, der nesten ingenting brukes, 1000/1000 Mbit linje, og en halv Xeon Quadcore (4 threads). Serveren er knapt under arbeid, men likevel så er det veldig lang responstid på websiden.

 

Hvordan kan jeg optimalisere websiden min?

Endret 13. januar 2012 av Gavekort

[code]

Nå er jeg ingen webdesign guru, men gikk inn å tittet på source coden din, og så java, tipper dette er banneren på toppen.

 

Prøvde å disable java på webbrowseren min, og dette gjorde til at siden din loadet en god del mye raskere.

 

Om dette var tilfedligheter er jeg ikke helt sikker på.

Men er det virklig nødvendlig med java der? Hva med .gif eller flash?

 

Edit: Virker også litt som den bruker tid før den iheletatt vil starte å loade det grafiske, nesten som den titter igjennom litt formye .php filer på siden.

 

Edit2: Også voten på forsiden din mangler noen svar muligheter.

 

 

Endret 13. januar 2012 av ANONIII

[Gavekort]

Nå har jeg fjernet banneret, og jeg merker ikke noe spesielt til høyere ytelse.

 

Kan føre med at cloud.genericurl.org og torrent.genericurl.org er like trege.

[code]

Kan prøve å lage en tom side, med veldig lite text eller innhold, for å se om responstiden forsatt er like dårlig. Som ikke tar ibruk MySQL/Php/Java. For å finne ut om det er grafisk/coding, eller server problemer.

 

 

[Gavekort]

Kan prøve å lage en tom side, med veldig lite text eller innhold, for å se om responstiden forsatt er like dårlig. Som ikke tar ibruk MySQL/Php/Java. For å finne ut om det er grafisk/coding, eller server problemer.

 

Jeg antar at det er noe feil med MySQL, eller at jeg ikke har benyttet meg av noe RAM-caching etc.

 

Serveren er som sagt i tipp topp kvalitet. 1000Mbit begge veier, og 37ms fra Wales til Tyskland, der serveren befinner seg.

 

Jeg får til og med lang responstid om jeg går inn i localhost med links (text nettleser).

[Bolson]

Ser at du bruker Concrete5. Problemer med trege sider har man stadig vekk ved PHP + MySQL baserte løsninger om man ikke passer på å optimalisere MySQL og bruke ulike former for cache. En side kan nemlig lage utrolig mange MySQL-spørringer om dette ikke er optimalisert eller at tabellene er cachet. Ofte er det også slik at en enkelt tilleggsmodul/punkt i opsettet kan drepe all ytelse - ikke minst en tilleggsmodul som er elendig kodet.

 

Anbefaler at du sjekker følgende:

- Optimalisering av MySQL - mysqltuner er her et greit verktøy - du kan også sjekke hvor mange spørringer som kjøres via mytop

- Slå på log for slow_queries i my.cnf

- Gjør eventuelle justeringer i database og my.cnf for å få vekk flaskehalser

- Test skalering med ab, f.eks sjekk 5, 10 - og oppover til 50 cocurrent sessions.

- Sjekk også med YSlow om du har noe som drar mye.

- Ta i bruk cache, for eks APC, Memcache eller eAccelerator - sjekk hvilke Concrete fungerer best med

- Vurder å skifte ut Apache med Ligthpptd (eller lignende lette sebservere)

 

Ellers så spiller ikke 1000 Mbit/s noen som helst rolle her, men 2,5 GiB er ikke nødvendigvis mye minne når det skal deles av PHP og MySQL. MySQL er ellers i normaloppsett dårlig til å bruke flere tråder, så her er det ofte raske kjerner som drar best.

 

PS! Jeg har drept en nettside på en server med Quad Core, 16 GiB minne etc pga et ekstremt dårlig skrevet PHP-script.

[Gavekort]

Dette skal jeg prøve ut! Takk for råd!

[Gavekort]

*snip*

 

 

Her har du resultatet fra MySQLTuner:

 

 

 

 

 

-------- General Statistics --------------------------------------------------

[--] Skipped version check for MySQLTuner script

[OK] Currently running supported MySQL version 5.0.77

[!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM

 

-------- Storage Engine Statistics -------------------------------------------

[--] Status: -Archive +BDB -Federated +InnoDB -ISAM -NDBCluster

[--] Data in MyISAM tables: 405K (Tables: 159)

[!!] InnoDB is enabled but isn't being used

[!!] BDB is enabled but isn't being used

[!!] Total fragmented tables: 20

 

-------- Security Recommendations -------------------------------------------

*Sensurert*

 

-------- Performance Metrics -------------------------------------------------

[--] Up for: 6d 18h 54m 21s (81K q [0.140 qps], 2K conn, TX: 26M, RX: 8M)

[--] Reads / Writes: 89% / 11%

[--] Total buffers: 34.0M global + 2.7M per thread (100 max threads)

[OK] Maximum possible memory usage: 302.7M (13% of installed RAM)

[OK] Slow queries: 0% (0/81K)

[OK] Highest usage of available connections: 8% (8/100)

[OK] Key buffer size / total MyISAM indexes: 8.0M/607.0K

[OK] Key buffer hit rate: 99.8% (275K cached / 554 reads)

[!!] Query cache is disabled

[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 6K sorts)

[!!] Temporary tables created on disk: 47% (4K on disk / 9K total)

[!!] Thread cache is disabled

[!!] Table cache hit rate: 6% (64 open / 947 opened)

[OK] Open file limit used: 12% (126/1K)

[OK] Table locks acquired immediately: 100% (79K immediate / 79K locks)

 

-------- Recommendations -----------------------------------------------------

General recommendations:

Add skip-innodb to MySQL configuration to disable InnoDB

Add skip-bdb to MySQL configuration to disable BDB

Run OPTIMIZE TABLE to defragment tables for better performance

Enable the slow query log to troubleshoot bad queries

When making adjustments, make tmp_table_size/max_heap_table_size equal

Reduce your SELECT DISTINCT queries without LIMIT clauses

Set thread_cache_size to 4 as a starting value

Increase table_cache gradually to avoid file descriptor limits

Variables to adjust:

query_cache_size (>= 8M)

tmp_table_size (> 32M)

max_heap_table_size (> 16M)

thread_cache_size (start at 4)

table_cache (> 64)

 

 

 

 

 

Her er etter jeg gjorde noen småting:

 

 

 

 

-------- General Statistics --------------------------------------------------

[--] Skipped version check for MySQLTuner script

[OK] Currently running supported MySQL version 5.0.77

[!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM

 

-------- Storage Engine Statistics -------------------------------------------

[--] Status: -Archive -BDB -Federated -InnoDB -ISAM -NDBCluster

[--] Data in MyISAM tables: 302K (Tables: 159)

[OK] Total fragmented tables: 0

 

-------- Security Recommendations -------------------------------------------

*sensurert*

 

-------- Performance Metrics -------------------------------------------------

[--] Up for: 9m 32s (1K q [1.970 qps], 75 conn, TX: 329K, RX: 99K)

[--] Reads / Writes: 98% / 2%

[--] Total buffers: 34.0M global + 2.7M per thread (100 max threads)

[OK] Maximum possible memory usage: 302.7M (13% of installed RAM)

[OK] Slow queries: 0% (0/1K)

[OK] Highest usage of available connections: 2% (2/100)

[OK] Key buffer size / total MyISAM indexes: 8.0M/575.0K

[!!] Key buffer hit rate: 94.7% (2K cached / 122 reads)

[!!] Query cache is disabled

[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 49 sorts)

[!!] Joins performed without indexes: 6

[!!] Temporary tables created on disk: 38% (64 on disk / 165 total)

[!!] Thread cache is disabled

[!!] Table cache hit rate: 6% (64 open / 1K opened)

[OK] Open file limit used: 12% (128/1K)

[OK] Table locks acquired immediately: 100% (964 immediate / 964 locks)

[!!] Connections aborted: 6%

 

-------- Recommendations -----------------------------------------------------

General recommendations:

MySQL started within last 24 hours - recommendations may be inaccurate

Enable the slow query log to troubleshoot bad queries

Adjust your join queries to always utilize indexes

When making adjustments, make tmp_table_size/max_heap_table_size equal

Reduce your SELECT DISTINCT queries without LIMIT clauses

Set thread_cache_size to 4 as a starting value

Increase table_cache gradually to avoid file descriptor limits

Your applications are not closing MySQL connections properly

Variables to adjust:

query_cache_size (>= 8M)

join_buffer_size (> 128.0K, or always use indexes with joins)

tmp_table_size (> 32M)

max_heap_table_size (> 16M)

thread_cache_size (start at 4)

table_cache (> 64)

 

Endret 14. januar 2012 av Gavekort

[tingo]

Ble nettstedet raskere da?

[Gavekort]

Jeg vet ikke. Jeg kunne føle at det ble hakket bedre, men siden jeg ikke kan måle det, så kan det være en ren placebo.

 

Jeg har nedetid på serveren nå, så kan ikke jobbe mer med det.

[Gavekort]

Serveren er oppe igjen, og jeg har strippet den ned til et minimalistisk design, men et minimum av tilleggsfunksjoner. Jeg må si at det ble mye bedre nå, selv om problemet fortsatt ikke er fikset noen andre plasser.

 

Jeg vil ikke si at problemet er løst, men det er mindre kritisk nå!

[Gjest Slettet+432]

Det er fortsatt mye du kan tune i my.cnf...

[Bolson]

Serveren er oppe igjen, og jeg har strippet den ned til et minimalistisk design, men et minimum av tilleggsfunksjoner. Jeg må si at det ble mye bedre nå, selv om problemet fortsatt ikke er fikset noen andre plasser.

 

Jeg vil ikke si at problemet er løst, men det er mindre kritisk nå!

 

Serveren virker å være nede igjen nå - dvs et problem med MySQL så vidt jeg kan se. Dette kan faktisk være at det er en feil i MySQL installasjonen om den er ustabil.

 

Selve designet trenger ikke å ha særlig betydning for ytelse - mye av det består av statiske filer som laster fort uansett. Tilleggsfunksjoner kan som tidligere nevnt drepe ytelse om de lager mange spørringer til databasen og er dårlig cachet.

 

Når jeg søker litt på Concrete5 i kombinasjon med "performance" eller "slow" så ser jeg at mange rapporterer tilsvarende problemer. Fant en post om optimalisering på nettsidene deres. Virker ikke som Concrete5 er bygd optimalt for ytelse uten en del optimalisering. Bruk av opcache (Zend, APC etc) er anbefalt.

 

Cache vil fort redusere lastetida på en side med 2 - 5 ganger.

 

Du vil ellers om du søker på nettet finne en lang rekke anbefalinger til nøyaktig oppsett av my.cnf for ulike mengder med minne.

 

 

PS! Det er en av grunnene til at jeg liker TYPO3 - her kan jeg enkelt sjekke hva som er flaskehalser når en side lages og hvor stor effekt cache har. Hvilke spørringer gjøres - og hvor lang tid tar hver spørring, hvor lang tid tar de ulike "scriptene" osv og hvilket innhold produserer de ulike deler.

 

Det er fortsatt mye du kan tune i my.cnf...

 

Helt korrekt. Særlig er det viktig å få til at så mye som mulig av tabellinformasjon som spørres mye etter lagres i MySQL sin cache (dvs i datamaskinens minne). Akkurat det gjør utrolig mye utslag på ytelse.

 

Man må også være klar over at dataene fra mysqltuner ikke har særlig verdi før serveren har ruslet en dag eller to. Kjører man noen omganger med ab så får man mer fornuftige data.