Jag har förtillfället en sida som i korta drag tillhandhåller en liten bild för att räkna unika besökare. Denna bild/php-script jobbar mot en MySQL databas som ligger på samma server som webbservern.

Förtillfället anropas denna fil ca 50 gånger i sekunden och detta är inget som kommer minska utan tvärtom. Samtidigt ökar databasens storlek kontinuerligt och är idag på 1GB varav 20-30% är ip-adresser kopplade till en användare. Först tänkte jag öka mängden minne i servern men det hjälper endast läsning från databasen, skrivningarna måste fortfarande ske till disken vilket de flesta anrop till databasen rör sig om.

Serverns tillfälliga hårdvara är:
Dual Opteron 2212 Dual Core
2 x 146GB, 10K RPM SCSI/SAS Hard Drive (RAID 1)
2048 MB RAM

Belastningen på servern ökar tyvärr rätt så lavinartat så jag undrar vilken hårdvara och uppbyggnad som är det bästa. The Planet kan inte erbjuda en enkel server som presterar mycket bättre än denna så det blir att dela upp det men det har jag ingen erfarenhet av. Antingen en dedikerad mysql-server eller loadbalanced-pairs.

Jag skulle rekomendera dig att i första hand titta på databasstruktur och försöka optimera din kod/frågor mot databasen i största möjliga mån. Kanske byta ut apache mot en annan webbserver (lighttpd kanske). Kika även på någon form av cache, kanske xCache så slipper du lite overhead tider.
Har du gjort allt detta är du nog inne på rätt spår.

Databas-strukturen och programmeringen är så bra som jag kan göra den. Nogrant gjord då jag visste innan jag började att stora mängder förfrågningar skulle ske.

Problemet med att tweaka en server är att man lägger ner massa arbete nu och så blir jag ändå tvungen att byta server om en månad. Detta är lite irriterande. Hittils har jag haft en ökning med nästan 100% var tredje månad så nästa serverbyte måste klara av några ökningar även om det kostar lite.

Jag har inte sett koden och jag vet inte vad det handlar om men jag tror inte han med "optimering" endast menar förbättring av queries samt funktionerna som du använder utan försöka komma på ett bättre sätt, om möjligt, att utföra det du gör fast på ett bättre sett som gör att mina behov minskar.

Försök att tänka i andra banor eller publicera din kod här så vi andra kan hjälpa dig om du inte känner att din kod/idé kan leda till vinstsyfte då.

php-scriptet måste köras för att registrera besökaren och allt som sparas är ett id-nummer och en ip-adress i en databas. Berätta gärna för mig hur man på ett snabbare och mer optimerat sätt sparar denna data. Det är detta lilla script som tar upp "all" kapacitet av servern. Jag är ingen amatör på detta område utan är endast ute efter serverlösningar som klarar av belastningarna.

Varför lagra den informationen i en relationsdatabas? När, hur och varför läser du datan från loggen?

Va?

Min mage säger:
1. Onödigt att lagra datan i en relationsdatabas.
2. Onödig overhead med PHP.
3. Datan är oviktig. Det är inte hela världen om du sumpar ett entry eller två.
4. Du vill cruncha datan asynkront med requestsen.

Förslag på lösning:
Skippa PHP och crunch:a webbserverns logg asynkront istället. Släng på fler webbservrar vid behov. När det blir jobbigt att merga:a alla webbservrarnas loggfiler kan du låta de logga över en socket för central lagring. Använd Spread (gruppkommunikationssystem. Finns modul till apache) om du inte vill bygga socket-lösningen själv.

Å andra sidan låter det som att ditt nuvarande system borde klara bra mycket mer än 50 skrivningar per sekund. Men du har kanske massa tunga index över en enda enorm tabell? En snabblösning vore att fortsätta logga i mysql fast i en heap-tabell och dumpa över den datan till din redan befintliga tabell regelbundet, fast partitionera den först. Tänk på vilken information du verkligen vill ha kvar permanent. Dvs, du vill kanske inte veta exakt vilka IP-adresser som besökte sajten 1:a juli 1999 utan bara mängden unika besökare den dagen, den veckan och den månaden. Minska nogrannheten på äldre data låter lämpligt.


Edit: Sorry, det var visst hårdvarutips du var intresserad av. Jag rekomenderar någa billiga PC-servrar förr webbserver samt lastbalanserare och din befintliga för crunch och lagring av statsen. För övrigt berättar du inte vad flaskhalsen är i ditt nuvarande system. Disk-IO eller concurrency-problem med mysql?

Behöver väl inget phpscript per request över huvud taget. All info du behöver hamnar väl ändå i apache-loggen (ip,referer osv).
Sen så batchar du en körning en gång i timman eller hur du vill där du bearbetar loggfilen och gör det du vill med datan.

Och om du inte sparar IP-nummer som en unsigned int så är det dags att göra det.

Har tittat vidare på lösningar för sidan och jag gjorde en liten "miss" innan jag startade denna tråden. PHP-filen som räknar besökare lagrar inte endast en ip-adress utan hämtar även ut sidans placering och skriver ut den på bilden, där av den "onödiga" overhead med php (fast jag hade kört på den lösningen ändå). Så en hel del av belastningen låg på denna SQL-fråga men det har jag löst med memcached. Även om detta drog ner load så är det inte tillräckligt, speciellt inte när sidan helt plötsligt kan få en 100% ökning. Så jag har kommit fram till något liknande det Kullvervo skrev om.

Denna Bild demonstrerar hur jag har tänkt det. I min värld borde det bli mycket bättre.

HTTP-Server - Sköter all kommunikation utåt och slipper belastningar av MySQL och statistik-uträkningar.
MySQL-Server - Sköter all lagring av datan och får RAID 10 för felkontroll och säkerhet samt 4GB minne för datan.
Log-Server - HTTP-Servern kör Remote-logging till denna maskin.

Tanken är att istället för att PHP-scriptet ska skicka INSERT med IP till MySQL så ska ett program skrivit i C++ gå igenom loggfilerna och göra detta istället. På så sätt samlas alla INSERTS in i en fråga istället för många små vilket borde borde snabba upp det mycket. Programmet ska även göra de uträkningar för användarna som idag görs via cronjobs var 15:e minut. Tanken är att dessa beräkningar som kräver kapacitet inte ska påverka sidladdningarna på sidan då en lite överbelastad webbserver skickar html-kod samt alla bilder väldigt långsamt.

Idag har jag bara HTTP-servern som kör MySQL och alla uträkningar. Det planerade kalaset kommer gå loss på ca 5900kr/mån, vilket det är värt om det hjälper mycket.

Vad tror ni om denna lösning och om utvald hårdvara (som visas på bilden)?

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.

I all ärlighet så undrar jag om du ens läst tråden?

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.

Ditt kanske är snarare högst osannolikt. Jag vill inte ha hjälp att optimera kod/databaser. Du kanske borde läsa vad trådskaparen vill uppnå istället?

OT
Vart hittar man en prestandakonsult?
Någon som har referenser?

FredrikMH: du har ju fortfarande inte svarat kullervo på vart flaskhalsen ligger Så jag vet inte varför du dissar alla när dom försöker hjälpa dig.

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.

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.

Tyvärr räcker det nog bara några månader för honom. Efter det måste han nog sikta på IO-system som går loss för >100k och där har åtminstonde inte jag något tips. Undrar vad det kommer krävas för grejer om 1 år...

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.

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.

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.

Jaha, det är CPU:n som har det svettigt. Vad bra, för det är nog både enkelt och billigt att göra något åt. Vet du vad det är den håller på med? Min gissning är att den sliter med att uppdatera stora index.

Att kapaciteten i systemet är skalbar, dvs. att du alltid kan öka kapaciteten genom att *lägga till* (helst kostnadseffektiv) hårdvara. Att behöva byta ut hårdvara för att öka kapaciteten är vad kostymnissarna kallar för att skala vertikalt (till skillnad mot horisontalt) vilket ofta bara är onödigt dyrt och sämre om inte helt omöjligt t.om.

Det kan ju bero lite på vilken scsi/sas-kontroller du kör också. Det är inte så att den är en billigare variant som behvöer lite extra hjälp av CPU?

Vad är det för nätverkskort? Var iofs ett par år sedan jag märkte av billiga nätverkskort som nästan sänkte maskinen när det kom trafik.

Förresten, vilken process är det som käkar CPU? Är det mysql, httpd eller något annat?

Weaver:
Att jobba sig igenom en loggfil tar en hel del resurser det med. Blir det verkligen så "mycket" bättre?

Ja bilden genereras varje gång. Bilden laddas av php och en siffra läggs till på bilden. Bilden är inte direkt stor (163 bytes) av typen gif. Totalt sätt skulle det finnas 100 olika bilder (kanske fler i framtiden) då jag idag endast visar deras position om de ligger i top 99 i deras kategori.

Skulle inte söktiden bli större för bilderna om det var 100 olika bilder som ska laddas in varje sekund? Jag menar de ligger på olika ställen på disken och läshuvudet får flytta sig oftare? Diskar är långsamma och att rita ut en liten siffra är inte jobbigt för processorn. Idag är det mysql som tar upp 25% cpu och är den som överbelastar servern.

Eventuellt skulle man spara en del disk-kapacitet genom att lagra dessa bilder i memcached men det har jag inte lyckats med då der serialiseras. Läste någonstans att det inte gick att spara filer i memcached men jag har inte undersökt det ytterligare.

Kullervo:
Jag har en ip-tabell som sparar alla ip-adresser och jag är medveten om att index gör det jobbigare att lägga in data i tabellen än en som är utan index. Tabellen består bara av två kolumner (userid, ip) där det jobbiga unique-index är placerat över båda, samt ytterligare ett index över userid (för att gruppera antal ip för användare).

Jag är medveten om att detta inte är snabbt och jobbigt för mysql att hantera. Men och andra sidan måste jag på något sätt sortera ut dubletter av ip-nummer. Kanske är det bättre att tillåta dubletter av ip och utnyttja DISTINCT i queryn för att beräkna de unika ip-nummerna i och med att detta endast sker var 15:e minut? Men samtidigt kommer datan i tabellen att öka enormt mycket. Idag har den närmare 10 miljoner rader i slutet på vekcan och då är dessa endast unika.

Jag har även provat med en heap-tabell med samma kolumner fast inga index alls och endast mata in alla ip-nummer där under 20min för att se om belastningen på servern sjönk men det blev tyvärr inte min uppfattning.

Jonny:
Jag har inte full tillgång till hårdvaran som sitter i min server. Jag hyr allting av The Planet men för $40 i månaden extra så hoppas jag inte att det är mjukvaru-raid jag fått :)

Ledsen kan inte hjälpa dig med nätverkskortet heller :(

mysql tar upp 100% enligt cpanel (vilket blir 25% med 4 processorer/kärnor).
httpd och övriga ligger långt ifrån mysql.

----------------
Som kullvervo skrev så segar säkert index ner men varför märkte jag inte någon förbättring när jag körde utan index och som heap-tabell? Det borde i så fall varit mycket snabbare. Det var detta som fick mig att sluta titta på tabellens uppbyggnad. Kanske är något annat som belastar?

Det som stör mig mest av allt är att så fort servern får lite att jobba med så går det segt att surfa på sidan. De dynamiska sidorna laddas lite långsmmare men alla bilder är det som får en att hämta en kopp kaffe under tiden. Ligger då mySQL på egen server så måste bara användaren vänta "lång" tid på innehållet. Sen trillarna bilderna in snabbt och enkelt vilket ger en mycket behagligare upplevelse.


Edit:
Idag hade jag en ytterligare ökning. Över 15% mer besökare sedan i fredags och så här fortsätter det från vecka till vecka. Enligt Alexa har jag en 150% trafikökning var tredje månad.

Just nu laddas allting väldigt långsamt med en härlig belastning på servern "Server Load 19.60 (4 cpus) ". Börjar bli riktigt kritiskt nu. Antaligen blir det köp av en dedikerad mysql-server tills jag kommit på något bättre.

BrokeP är duktig, om han tar sig an jobb vet jag dock inte ;)

Kan väl också hålla med om att mer burkar är overkill, jag mixtrar hårdvaran bakom TV.nu och där snackar vi sidvisningar/db-querys utan dess like, körs på liknande maskin(er) du har nu.

Om du kan shoppa en till burk via theplanet utan uppsägningstid och liknande så gör det för att stabilisera driften, sen kan du i lugn och ro felsöka och optimera en månad och återgå till en burk igen.

Det märks. Tycker det där var ett riktigt läsvärt inlägg. :)

Du har möjligtvis inte en foreign key på loggtabellen som pekar mot userid-tabellen?

Väldigt intressant!

Jag har själv inte nån direkt kunskap, jag har själv anlitat BrokeP & Decibel. BrokeP's trafikvolymer på The Pirate Bay gör nog att dom kliat sig i huvet några ggr när dom byggde systemet. Jag kan inga stats där men räknar med att det är mycket och tungt för hårdvaran. I mitt fall på Tv.nu har vi 2-300 ganska tunga laddningar i sekunden mellan 20:00-22:00 och vi loggar varenda klick en besökare gör och visar annonser relaterade till klicken men ett halvårs historia. Det blir nån miljon nya poster per dygn. Vi raderar inget utan komprimerar och lägger endel i cookies. Vi går på samma hårdvara du planerat kanske aningen mer, fast i ett kluster för skalbarheten. Utöver lagringen som nämts laddas Indexsidan som är dynamiskt (beroende av besökaren kanalval) ut 7-900 000 ggr per dygn. Som sagt vi går på samma hårdvara i princip. Det är nåt annat som är strul med din server, den skall klara mer.

Har du stängt av allt du inte behöver på servern? sendmail, httpd-logg, httpd-logg-rotations osv, secure-server etc ...

Kolla så det inte skrivs nåt felmeddelande till nån 5 GB fil, lägg crontabs på att tömma allt som kan bli stor om du inte kan stänga av det.

Httpd-loggen är en serverdödare, när jag körde tv.nu på The Planet körde jag hårddisken full på en söndagkväll om loggen var på.

Du nämner cpanel, mitt tips är att du hyr rena servrar. Jag hade Ensim på den tiden, det gick inte bara rena servrar utan kontroll-panel och loggar höll.

Jag tänkte inte på ovanstående ... kanske är det nåt av det som hjälper.

Tack för alla svar!

Eftersom jag kan komma på flera olika sätt att lösa detta på men inte kan urskilja vilket som är bäst så blir det antagligen att hyra in en konsult som kan komma fram till en bra lösningen åt mig. Någon som har ett hum om vad detta skulle kunna kosta?

Edit: raderat.

Du tror inte att operativsystemet kommer cacha de 100 stycken filerna på alla sätt eftersom de är extremt eftertraktade?
Jag garanterar dig att ett header()-anrop är några miljoner gånger snabbare än att ladda en befintlig bild, packa upp den, rita på den upppackade bitmappen, komprimera den och sen skicka den till klienten.

Jag kan åta mig att försöka optimera saker och ting åt dig på befintlig miljö och priset kan vi basera på hur bra jag lyckas. Sånt här är skojjiga saker så jag blir inte dyr. ;)

Du kan maila mig på [email protected]

Hahaha varför provade jag inte att felsöka innan jag upptäckte att en dedikerad mysql-server inte hjälpte?

Om jag lägger tracker.php att jobba mot den dedikerade mysql-servern så sjunker inte load alls. Och load på mysql-servern blir 0.10 :D Tar jag dessutom bort så inte ranking skrivs ut på tracker.php så sjunker inte load på servern heller.

Om jag däremot tillfälligt skickar en 503 Service Unavailable till alla besökare på sidan och skriver ut en text för besökaren att det sker underhåll på servern så lägger sig webbservern på en load av inte mindre än 0.17 :D

99% av alla anrop går till tracker.php men det betyder inte att det är den som belastar servern. Bra jobbat Fredrik!!! Man lär sig i alla fall av sina misstag.

Antagligen är det några av mina andra databaser som är jätte sega och jag har ju mina misstankar nu direkt när jag inte längre är fokuserad på något annat.

kika dina sqler med mytop där kan du se segdragna queries och allt..

Vad kör du för OS? MySQL är ju inte ett prestandamonster på vissa OS till exempel, kolla på PostgreSQL, brukar gå fortare.

Blev inte mycket sömn inatt.

Hittade några stora (små) flaskhalsar i systemet inatt och gjort ett flertal förbättringar i databaserna och i källkoden. Som det ser ut nu så blev det riktigt bra.

Fast tracker.php har blivit markant mycket bättre och det finns sätt att göra den ytterligare snabbare så det var väl inte helt värdelöst att fokusera på den men jag känner mig dum som uteslöt allt annat.

Förhoppningsvis kan jag stanna kvar på denna servern ett tag till. Fast om tillväxten fortsätter som den gjort så vill jag lägga högre vikt på tillgängligheten och då blir det lastbalansering vid årskiftet. Har pratat med The Planet angående detta och det kommer bli en kostnad på närmare 20 000:- i månaden med ett Rack, LB och 3-4 Servrar.