Just nu i M3-nätverket
Jump to content

Motsvarighet till APS's Application i PHP?


sMe

Recommended Posts

Hallå alla PHP gurus.

 

Jag har äntligen tagit steget till att börja med PHP efter flera års intensivt knackande i ASP.

 

Dock så finns det en funktion som jag inte hittar i PHP som finns i ASP och är väldigt användbar. Det är just Application.

 

I ASP fungerar det helt enkelt så här:

 

Application("nisse") = "Hej alla glada"

 

Och sedan kan man alltid skriva ut värdet i Application("nisse") på alla sidor. Precis som Sessionvariabeln. Dock så är skillnaden att Application sparas "globalt". Det vill säga att det man skriver i Application kan nås av alla användare. Man kan säga att det är ett globalt sessionobjekt som inte är kopplat till någon specifik användare.

 

Detta är väldigt användbart i många sammanhang. Man tex spara vissa saker i den så att man slipper ställa onödiga frågor till databasen.

 

Man kan visseligen göra så att man sparar detta i Sessionobjekt så fort en person besöker sidan. Men jag vill minimera Sessionanvändandet så mycket som möjligt då detta tar kraft från datorn (Ja. Det gör det. Jag har testat att skapa en sjuh*lvetes massa sessions och det påverkade prestandan märkbart.).

 

Finns det ingen motsvarighet till Application i PHP?

 

Link to comment
Share on other sites

Njae. Inte riktigt det jag letade efter.

 

Problemet med "Semaphore, Shared Memory and IPC Functions" är:

"Note: This extension is not available on Windows platforms" - vilket gör att ditt php-script helt plötsligt blir platformsberoende.

 

Sedan såg jag:

"Remember, that shared memory is NOT safe against simultaneous access." - vilket gör att det skulle vara oklokt att använda denna till en stor site där många besökare använder sig av denna mycket.

 

Link to comment
Share on other sites

Jag skulle inte tro att det finns någon motsvarighet, jag vet inte hur de har gjort i ASP men om det vore minnesbaserat så skulle det skala rätt uselt, speciellt om man driftar på ett ställe där det finns ett helt kluster med webbservrar.

 

Jag skulle nog spontant försöka minimera behovet av dylikt data och i den mån jag behövde det låta det ligga i en databas eller en fil (beroende på hur jag uppdaterar datat). Att göra unserialize går på en sträng (från databas eller fil eller vad 17 som helst) går tämligen fort.

 

Link to comment
Share on other sites

Jo. Fast problemet är ju fortfarande att jag vill minimera användandet från databasen. Att använda koppling mot databasen ökar ju risken till att sidan blir mer instabil och att den kan slöas ner om man helt plötsligt börjar få en hel del besökare. Om jag då lägger upp sådant data i databasen så kan jag lika gärna göra databaskopplingen på en gång och strunta i detta.

 

Sedan så har det ju ingen betydelse om driften finns på ett hotell som har ett ett kluster av webservrar.

 

Alltså, en Application är i princip samma sak som en Session. Med den enda skillnaden att man skapar EN application som alla använder sig av. Alla kommer åt den. (Under den applikationen på servern, dvs). Att använda Application till gemensam data (som ska kunna vara dynamisk) är alltså mindre minneskrävande än tex Sessions.

 

Jag kan testa att lägga data i en vanlig textfil och läsa från den. Har inte hållit på så mkt med att läsa filer via PHP. Är inte risken att om många läser den samtidigt så blir det error pga att filen används av annan användare?

[inlägget ändrat 2005-10-28 09:23:35 av sMe]

Link to comment
Share on other sites

Att använda koppling mot databasen ökar ju risken till att sidan blir mer instabil och att den kan slöas ner om man helt plötsligt börjar få en hel del besökare.

Då har du gjort något på helt fel sätt, allternativt tar du för givet att anslutningar till databaser måste vara jättetunga, så är vanligtvis inte fallet och i de fall det är så (SQL Server, Oracle och några till) så brukar man vanligtvis sätta en poolning av connections runt så att man inte behöver skapa och slänga fullt så många tungviktiga anslutningar.

 

Alltså, en Application är i princip samma sak som en Session. Med den enda skillnaden att man skapar EN application som alla använder sig av.

Jag vet men so what? Om det inte är data som ändrar sig precis hela tiden så kan du ju lika gärna läsa in det i sessionen vid start och sen aldrig mer.

 

Om det är data som ändrar sig precis hela tiden kan du lika gärna ta databasaccesserna. Om din webbapp skulle få de hundratusentals samtidiga besökare som du förväntar dig så kommer det inte att göra någon större skillnad i prestanda. Hade det varit minnesbaserat hade du (eller ASP:s fall, ASP) behövt ta en massa lås för att hindra att det dyker upp läsare samtidigt som annan kod skriver, hade applikationen dessutom varit i ett kluster hade datat fått replikeras mellan hosts osv.

 

Är inte risken att om många läser den samtidigt så blir det error pga att filen används av annan användare?

Nej inte om du kör på ett relativt modernt operativsystem, inte heller behöver det bli speciellt slött eftersom filen med största sannolikhet vid hög last kommer att befinna sig i filsystemet cache och då handlar det om en minnesaccess.

 

Det känns lite som om du har bestämmt dig för att Application-objektet är en golden hammer och att man inte kan leva utan, det är lite samma fel som man ser hos nya programmerare som vill göra globala variabler av allt för att det blir enklast.

 

Fundera istället lite på informationsmängder, vad som hör hemma vad, vad som kan ändras och vad som lika gärna kan läsas in en gång och alltid förbli kvar. Med lite tur kommer din applikation att bli både mer skalbar och effektivare.

 

Om det är en applikation som helt enkelt inte klarar sig utan så får du väl göra dig ett applikationsobject, det är inte så himla svårt att göra två likvärdiga implementationer som använder ett COM-objekt i Win32 och Shared Memory i alla övriga fall. Det blir naturligtvis svårare om du ska kunna skala över flera maskiner men du får väl börja någonstans :-)

 

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.



×
×
  • Create New...