FAQ |
Kalender |
2007-07-06, 02:12 | #11 | ||
|
|||
Medlem
|
I all ärlighet, vi kör bra mycket mer information på bra mycket mindre hårdvara. Du har gjort nåt fel, billigast (och bäst, både för dig och besökaren) är att skriva om det. Tänk igenom det riktigt noga, anlita en prestandakonsult. Den hårdvaran du kör nu ska man kunna pressa ut mångfaldigt mycket mer prestanda ur.
|
||
Svara med citat |
2007-07-06, 11:43 | #12 | |||
|
||||
Supermoderator
|
Citat:
|
|||
Svara med citat |
2007-07-07, 15:06 | #13 | ||
|
|||
Medlem
|
Presentera lite tabellstrukturer och vilka index du harpå dom samt vilka slags querys du kör kan vi kanske spara in en del pengar åt dit.
|
||
Svara med citat |
2007-07-08, 14:18 | #14 | |||
|
||||
Supermoderator
|
Citat:
|
|||
Svara med citat |
2007-07-08, 15:01 | #15 | |||
|
||||
Medlem
|
OT
Vart hittar man en prestandakonsult? Någon som har referenser? |
|||
Svara med citat |
2007-07-08, 15:51 | #16 | |||
|
||||
Har WN som tidsfördriv
|
FredrikMH: du har ju fortfarande inte svarat kullervo på vart flaskhalsen ligger
Citat:
Min personliga reaktion är att 5900 kronor per månad låter som enormt mycket pengar för en (ursäkta ordvalet) enkel site. Alltså skulle jag kunna svara; köp en 8kärnig maskin med 16 gig ram och 8st SAS 15krpm diskar i raid 10 de hamnar på strax under 5 000 i månaden på ett leasing kontrakt, så behöver du inte bry dig längre. |
|||
Svara med citat |
2007-07-09, 06:43 | #17 | ||
|
|||
Medlem
|
Skapa ett filsystem i ramminnet och skriv all info från php-scriptet i tempfiler som du sedan läser av med ett cron-script var N´e minut.
|
||
Svara med citat |
2007-07-09, 12:58 | #18 | |||
|
||||
Bara ett inlägg till!
|
Citat:
FredrikMH: Lägg några tusenlappar på en konsult som kan bygga ett skalbart system åt dig istället. Om du får tag på någon redan idag kan du ha ett färdigt system som går att köra på billig hårdvara innan helgen, så att slänga hårdvara på problemet behöver inte ens vara en snabbare lösning. |
|||
Svara med citat |
2007-07-09, 15:48 | #19 | |||
|
||||
Supermoderator
|
Ursäkta att jag var lite bitter innan, men den aktuella lösningen fungerar inte och även om man optimerar lite så tar det ett par veckor och så står man på samma plats igen och det är inte detta jag vill uppnå med tråden Så antingen är det en helt ny serverlösning eller en helt ny uppbyggnad av "systemet".
I maj flyttade jag sidan från en annan dedikerad server, där den delade resurser med några andra stora sidor. Idag är den redan för krävande för en egen server, trotts att den nya servern har mycket bättre kapacitet än den andra. De optimeringar jag gjorde med memcache hjälpte i några dagar tills cpun hade mycket att göra igen Kullervo: Vad menar du med ett "skalbart system"? Kjette: Ska ta en titt. Tack för tipset. |
|||
Svara med citat |
2007-07-09, 18:10 | #20 | ||
|
|||
Flitig postare
|
Tack för en mycket intressant tråd, älskar performance relaterade trådar
Skulle vilja flika in lite spontana kommentarer om det jag läst här i tråden. Jag utgår från ett system där du periodiskt läser httpd loggarna. Jag såg arkitekturen (bilden) du postade om det nya systemet du funderade på att bygga. Tycker det är lite märkligt att du valt att logga till en remote loggserver. Om du bygger det såhär är det ett perfekt sätt att introducera två flaskhalsar. Dels din loggserver och dels din databas. Om jag hade varit dig så hade jag låtit front-maskinerna logga till sin lokala disk. Detta gör att du uppnår flera saker. 1) Du tar bort en flaskhals från systemet 2) Du kan relativt lätt installera fler front-maskiner om lasten blir för hög för en maskin (men du måste merga resultaten från varje maskin). Dvs, systemet är skalbart. 3) Du sänker trafiken i ditt lokala nätverk vilket för eller senare kommer bli en flaskhals 4) Lägre latency på varje write, vilket gör att du kan hantera fler writes/s Vidare skriver du att du måste outputta en bild för varje request som kommer in. Om du genererar bilden vid varje request så förstår jag varför du har problem. Förgenerera alla bilder du kommer att skicka ut. Visst det kommer ta några timmar att generera de beronde på hur snabb maskin du har men det är det värt. Beroende på hur mycket ram du har kan du välja att lägga dessa bilderna i en ram-partion, dela de via memcache eller bara ha de på lokal disk. Alternativen är listade i snabbhetsordning. När en request kommer in så slår du upp hur många hits siten har (ha det tex cachat i memcache) och lämnar över uppgiften till att skicka ut bilden till din httpd genom att skicka en X-SENDFILE (header('X-Sendfile: 123423.png'). Detta är inte många rader php kod. Var 15 minute så låter du cron-script på dina front maskiner läsa httpd loggarna. Gör en sammanställning och skicka till databasen (antingen direkt eller via ett kommunikationslager som xml). Uppdatera sedan din memcache med antalet hits för varje site. Dina frontmaskiner är io-bundna, så investera hellre i dyra diskar än mycket CPU. Kör lighttpd på maskiner för maximal prestanda, använd APC tillägget för PHP för att cacha op-koderna. Använd memcache för saker du behöver dela mellan dina front-maskiner men använd helst "rent ram" för att plocka bort ytterligare latency (som för bilderna jag nämnde innan). Ställ dig frågan, "Behöver *verkligen* maskinera dela denna datan". Nyckeln till det hela är att designa systemet så asykront du bara kan. |
||
Svara med citat |
Svara |
|
|