Donnies svar (afstemning) er nok din bedste mulighed - enkelt og virker. Det vil dække næsten alle tilfælde (det er usandsynligt, at et simpelt PK-opslag ville skade ydeevnen, selv på et meget populært websted).
For fuldstændighedens skyld, og hvis du vil undgå polling, kan du bruge en push-model . Der er forskellige måder beskrevet i Wikipedia-artiklen. Hvis du kan opretholde en gennemskrivningscache (hver gang du opdaterer posten, opdaterer du cachen), så kan du næsten helt fjerne databasebelastningen.
Brug dog ikke et tidsstempel "last_updated"-kolonne. Redigeringer inden for samme sekund er ikke uhørt. Du kan slippe afsted med det, hvis du tilføjer ekstra information (server, der foretog opdateringen, fjernadresse, port osv.) for at sikre, at hvis to anmodninger kom ind på samme sekund til den samme server, kunne du opdage forskellen. Hvis du har brug for den præcision, kan du dog lige så godt bruge et unikt revisionsfelt (det behøver ikke nødvendigvis at være et stigende heltal, bare unikt inden for denne posts levetid).
Nogen nævnte vedvarende forbindelser - dette ville reducere opsætningsomkostningerne for polling-forespørgsler (hver forbindelse bruger naturligvis ressourcer på databasen og værtsmaskinen). Du ville holde en enkelt forbindelse (eller så få som muligt) åben hele tiden (eller så længe som muligt) og bruge den (i kombination med caching og memoisering, hvis det ønskes).
Endelig er der SQL-sætninger, der giver dig mulighed for at tilføje en betingelse på UPDATE eller INSERT. Min SQL ruster virkelig, men jeg tror det er noget i stil med UPDATE ... WHERE ... . For at matche dette beskyttelsesniveau skal du lave din egen rækkelåsning, før du sender opdateringen (og al den fejlhåndtering og oprydning, der kan medføre). Det er usandsynligt, at du har brug for dette; Jeg nævner det bare for fuldstændighedens skyld.
Rediger:
Din løsning lyder fint (cache-tidsstempler, proxy polling-anmodninger til en anden server). Den eneste ændring, jeg ville lave, er at opdatere de cachelagrede tidsstempler ved hver lagring. Dette vil holde cachen friskere. Jeg ville også tjekke tidsstemplet direkte fra db'en, når jeg gemmer for at forhindre, at en lagring sniger sig ind på grund af forældede cachedata.
Hvis du bruger APC til caching, giver en anden HTTP-server ikke mening - du skal køre den på den samme maskine (APC bruger delt hukommelse). Den samme fysiske maskine ville gøre arbejdet, men med den ekstra overhead fra en anden HTTP-server. Hvis du ønsker at slukke for polling-anmodningerne til en anden server (lighttpd, i dit tilfælde), så ville det være bedre at opsætte lightttpd foran Apache på en anden fysisk maskine og bruge en delt caching-server (memcache), så lighttpd-serveren kan læse de cachelagrede tidsstempler, og Apache kan opdatere de cachelagrede tidsstempler. Begrundelsen for at sætte lighttpd foran Apache er, hvis de fleste anmodninger er polling-anmodninger, at undgå den tungere Apache-procesbrug.
Du behøver sandsynligvis slet ikke en anden server. Apache burde være i stand til at håndtere de yderligere anmodninger. Hvis det ikke kan, så vil jeg gense din konfiguration (specifikt de direktiver, der styrer, hvor mange arbejdsprocesser du kører, og hvor mange anmodninger de må håndtere, før de bliver dræbt).