Jag undrar om det finns några smarta sätt att serva php sidor med otroligt många sql anrop på ett statiskt sätt. Alltså jag tänkte att man uppdaterar en statisk sida varje minut med aktuell sql information genom en cron av något slag.

Vad jag vill uppnå är att klara av en mycket hög peaknivå på samtidia besökare utan att servern dör..



Några förslag ?

Detta är en viktig fråga jag undrar över också.

En enkel lösning om man vill minska belastningen på sql-anropen är att köra squid lokalt på servern (du kör alltså en proxy lokalt som refreshar sin cache efter X sekunder).

Annars så kan man generellt snabba upp phpscript otroligt genom att använda chachning av php direkt, via mod_php, Zend cache eller Php-accelerator - men för att minska loaden på databasen så måste du då börja hacka om dina script.

Jag tittade på squid men det verkar vara ett rätt avancerat program...

Rekommenderas squid eller är det väldigt ambitiöst ? Jag vet inte om vi kommer att behöva en cache på vår nya sajt men vi vill klara av stora peaks om det nu skulle komma en oväntat stor våg med besökare..



Smarty verkar ju inte vara helt fel!

Ett enklare och ofta bättre sätt är att använda phps buffer och själv lagra det man skriver ut till användaren till en fil genom att använda output buffern.

Se http://se2.php.net/manual/en/function.ob-g...et-contents.php - när man sparat innehållet i denna är det sedan en smal sak att använda mod_rewrite för att skicka filen istället för en dynamisk kopia. Ta bort de statiska filerna med ett cronjob när de blivit äldre än "xx" minuter med find.

Ah där har vi nog det jag egentligen letade efter. Jag tycker dock att smarty verkar vara ett smart sätt att bygga sajten på så jag har bett programmeraren att titta på det.

Eller så går man över till .NET så finns det inbyggt, kräver endast en rad kod. :D

Ja när vi fått lite rullning på våra affärer kanske vi har råd med licenser osv.. men jag har inte sett många bra asp .net sidor, kan du ge några exempel ?

Hur menar du? "Bra" utifrån det som "syns" är väl inte direkt beroende av serverteknologi, så det finns både bra och dåliga siter gjorda med diverse tekniker (som ju det mesta beror på vad som sitter bakom spakarna) =)

Mycket av det som är bra är det som egentligen inte syns, nämligen snabb utvecklingstakt, serverprestanda (kompilerad kod + flera nivåer av cachning etc) och objektorientering (för den som vill det) och "allt-i-samma-paket" (den som lär sig hela .Net's objektbibliotek med klasser och metodnamn utantill ska få ett pris av mig!) :)

Vårt egna lilla Luderstorm är omskrivet i .NET....


Ser dock ingen större skillnad på snabbhet osv....

Att hålla på med proxy och grejer låter som mycket arbete och ändå inte som permanent lösning. Jag skulle välja att skiva effektivare kod framför proxy alla dagar. Här följer två snabbåtgärder som borde vara enkelt fixat:

1. Som Grazzy sa att låta PHP-koden lagra statiska sidor. PHP's inbyggda buffer gör som sagt livet enkelt. Använd crontab efter behag.

2. Slå på cache i SQL-servern. I mysql heter det så enkelt som query cache och aktiveras i my.cnf med raden "query_cache_size = <storlek>MB".

Vad kan ni rekommendera för mig som kör en toplista som hämtar mycket information för varje besökare från databasen hela tiden?

grazzy's idé ?

Playahead är programmerat i ASP.NET och är riktigt snabb.

PHP-Acc är instabil, testa http://turck-mmcache.sourceforge.net, mycket bra och stabil, och som nämnts tidigare, försök få så många querys som möjligt att cachas, kolla så att dom använder index, tabelltyper, innodb kanske gör susen på vissa tabeller genom att frigöra locks osv...finns massor man kan göra.

PHP-Acc är TURCK MM-Cache ;)

MMCache är nerlagt och PHP-Acc är fortsättningen på koden....

eAccelerator (http://eaccelerator.net/) är en fortsättning på turck-mmcache.

Både php-accelerator och turck-mmcache är "döda" projekt.

Jag gillar inte smarty ... även fast den cachar, varför inte använda vyer på databas-sidan?

Som en vän häromdagen påpekade så kan man även serialisera objekt till disken i PHP. Det kan vara praktiskt om man har lite overhead på att skapa objekten.
Se http://se.php.net/serialize och http://se.php.net/unserialize


Här är kod för att cachelagra filer i php.
För att sedan använda sig av den cache-lagrade filen är det bara att titta om den finns.
För att göra livet enkelt för mig har jag valt att inte läsa timestamps osv i mina script, utan det sköts istället via ett crontabjob som med följande rader tar bort alla filer som är äldre än 14 minuter:
rm -f \`find *.xml -cmin +14`

Turck mmcache använder jag också, fungerar mycket bra.

Som nämnts tidigare kan man göra väldigt mycket i mysql-inställningarna (antar att du kör mysql?). I min debian-dist finns en rad exempelkonfigurationer som baseras på hur mycket minne datorn har. Jag har modifierat lite och har ställt in så här för myisam-tabeller (1gb minne):

key_buffer = 512M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 4M
read_buffer_size = 4M
myisam_sort_buffer_size = 128M
thread_cache = 8
query_cache_size = 64M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 2

Vet inte om det hjälper dig något, men det ger en hint iaf. Det som är default i mysql är vad jag sett anpassat för väldigt lite minne.

query_cache_size kan vara mycket större om dina tabeller är hyfsat statiska. Uppdateras dem ständigt så nollställs all cache för den tabellen.

Ett gott råd är dock att alltid spara sina befintliga inställningar innan man börjar pilla med MySQLs defaultvärden.

Jag skulle hellre slå ett slag för eAccelerator, som är en vidareutveckling av Turck MMCache (den utvecklas ju inte längre). Finns på http://eaccelerator.sourceforge.net. Fick inte MMCache att fungera ihop med PHP 4.3.11, så det fick bli eAccelerator istället. Samma upplägg (installera som zend_extension) och samma options som i MMCache, fast mindre buggar.

Jag kan också intyga att Turck MMCache fungerar mycket bra, men jag kör den med 4.3.11 utan problem.

Ett tips angående inställningar av MySQL: Använd Mysql Administrator (www.mysql.com). Där kan man se minnes-status och enkelt utläsa vad man har för flaskhalsar. Det enda jag saknar är möjligheten att se vilka frågor som inte använder sig av index fullt ut.

Just nu för stunden snittar min MySQL 4.1 på 23 frågor per sekund och Query Cache hitrate ligger på hela 92% och använder bara 2MB minne(!!!). Key Efficiency ligger på 99%. Belasningen är 2 communities.

Hur mycket Query Cachen ligger på beror ju mångt och mycket på hur pass ofta informationen förändras på sajten. Själv ligger jag på ca 20%, men jag har mycket inserts också. Snittar ung 260 queries/sek just nu. Håller på och kollar om exempelvis JPCache kan hjälpa lite.