Effektiv php kode

[Ellingsen]

Hei.

 

Jeg har skrevet en del systemer og scripts i PHP, men lurer litt på effektiviteten.

Jeg har søkt både dette forumet og rundt på nettet men ikke finni noen enkle og forstålige forklaringer.

 

Hvordan gjør jeg kodene mine mere effektive (kjappere og laste opp) og hva trekker ned på farten? Jeg regner med at MySQL spørringer er treige, hvordan er det med if/else osv? Noen som har en god side for dette?

 

Også: er det best og lagre bilder (for f.eks til et bildegalleri) i database eller rett i en mappe på serveren? har lest begge deler, hvorfor/hvorfor ikke?

 

Takk for all hjelp.

Endret 20. mars 2007 av Ellingsen

[ze5400]

Også: er det best og lagre bilder (for f.eks til et bildegalleri) i database eller rett i en mappe på serveren? har lest begge deler, hvorfor/hvorfor ikke?

8151187[/snapback]

 

 

Mappe på serveren, å lagre bilder i BLOB er jo helt på trynet.

 

 

 

 

http://databases.aspfaq.com/database/shoul...filesystem.html

 

# if there is any chance that you will migrate to a different database platform, your current BLOB format might be incompatible with, or at least a pain to convert to, the new format -- since, like web browsers, each vendor has implemented things with their own slant.

 

# when your database really goes south, to the point where even the backup is useless, you still have the files on the filesystem (though their usefulness is questionable, depending on how much related data was kept in the database). Which is arguably better than losing all of your data *and* all of your files.

 

# having the images in the file system allows you to access the images from many different standard applications (FTP, web browser, etc) without having to write application code to pull the data out of the database, since you can't just 'SELECT image FROM table' and have the image appear in Enterprise Manager or Query Analyzer.

 

# with some databases, e.g. Access and MSDE, the data inside is limited to 2 GB (SQL Server Express 2005, as of July 2004, is planned to support 4 GB), whereas the file system is only restricted by the size of the volume. Also, most hosts charge a premium for SQL Server storage space, so in that case it would be cheaper to store them in the file system.

 

# in SQL Server 7.0, when a table has an IMAGE or TEXT column, a page is reserved for every row, whether or not that column has any data... so if you don't have an image for each record, there is potential to have a lot of wasted space. There are workarounds to this, of course, such as splitting the image data into its own table with a foreign key to the main table. SQL Server 2000 *can* combine multiple images < 8kb on one page (but typically, high-volume sites with plenty of images are not focusing on file sizes < 8kb anyway). Also, in SQL Server 2000, if your images are less than 8kb, you can use the text in row option by running the following code:

 

EXEC sp_TableOption N'TableName', 'TEXT IN ROW', 'ON'

 

Of course you will have to be careful with this option if you have other TEXT / IMAGE columns in the table.

 

# performance wise, including an <IMG SRC> tag generated by the database and pointing to a file that already exists is going to be faster than pulling the file out of the database, generating a temp file on the web server, and streaming that to the user. Also, table scans take more resources when there is an image datatype as opposed to a varchar that simply holds a 'pointer' to the file's location.

 

 

[Ernie]

Nå er hastigheten til PHP sammenlignbar med en Lada. PHP er treigt og det er skrekkelig lite man kan gjør med det. Det betyr selvsagt ikke at det ikke er noe å hente. Stikkordet er da caching.

• Å skrive ut (i betydningen noe sendes fra websever) noe er treigt. Ved å bruke output buffer blir echo og print betydlig mindre krevende siden utskriven buffres opp. Dette gjør også at output blir samlet slik at det kreves mindre pakker å overføre.
  
• Cache select-spørringer. Det er ikke noe poeng å kjøre en spørring på f.eks siste 10 artikler på forsiden eller siste innlegg fra forum for hver bidige sidevisning.
  
• Minnehåndteringen i PHP er sirrup. Derfor bør enhver rekursiv funksjon unngås og skrives om til en while-loop eller lignende.
  

Når det kommer til sql-spørringer er det strengt tatt lite å gjøre annet enn at joins ofte kan optimaliseres.

 

Lagring av bilder vil være helt klart raskest hvis man legger de på disk.

[Gjest Slettet-rXRozPkg]

Når det kommer til sql-spørringer er det strengt tatt lite å gjøre annet enn at joins ofte kan optimaliseres.

8151719[/snapback]

 

I tillegg kan det være smart å unngå SELECT * FROM blabla. Ikke velg ut mer enn det som trengs i en gitt situasjon.

 

Du kan også bruke refferanser mange steder, isteden for å opprette nye variabler hele tiden. Dette kan du lese om her: http://no2.php.net/variables.scope

[PHPdude]

Du kan også bruke refferanser mange steder, isteden for å opprette nye variabler hele tiden. Dette kan du lese om her: http://no2.php.net/variables.scope

8152315[/snapback]

 

Nå spesifiserer vel manualen at referanser kun skal brukes vis du har en teknisk grunn for det og ikke for å optimalisere, dette tar PHP seg av selv.

I hvilken grad referanser kan øke ytelsen i noen tilfeller vet jeg ikke, men vil tro det fort kan slå feil ut.

[Ellingsen]

tusen takk for all hjelp.!

[Roberto]

Fint om du også kan endre emnetittelen til noe som beskriver problemet litt nærmere.