ugrás a tartalomhoz

Kép elérése más fájlon keresztül

sandrosdj · 2013. Jan. 30. (Sze), 19.38
Üdv!

A szerveren levő /home/rootie/users/ mappában lévő képek elérését szeretném bonyolítani a következőképpen:

jelenleg ha el akarok érni egy képet, az így valósul meg:

http://example.org/users/picture.jpg -> /home/rootie/users/picture.jpg


..amit szeretnék:

http://example.org/users/picture.jpg -> /home/rootie/convert.php?file=users/picture.jpg


Véleményem szerint újraíró modullal lehetne megoldani a legegyszerűbben. Ehhez szeretném a segítségeteket kérni, kellene egy olyan sor, ami megoldja a fönt említetteket.
 
1

Véleményem szerint újraíró

Poetro · 2013. Jan. 30. (Sze), 22.02
Véleményem szerint újraíró modullal lehetne megoldani a legegyszerűbben.

Mit értesz újraíró modul alatt?
2

Szerintem rewriterule-ra

eddig bírtam szó nélkül · 2013. Jan. 30. (Sze), 22.15
Szerintem rewriterule-ra gondolt (már feltéve, hogy nem oktatásilag kérdeztél vissza ;-) )
4

Megoldás

sandrosdj · 2013. Jan. 31. (Cs), 00.04
Köszönöm a segítséget!
Itt a megoldásom:
RewriteRule ^(.*).(jpg|jpeg|png|gif)$ php/image_gear.php?file=$1.$2&type=$2
5

Ha csak jogosultság

inf3rno · 2013. Jan. 31. (Cs), 10.48
Ha csak jogosultság ellenőrzés kell a képekhez, akkor lehet, hogy egy rewriteMap jobb megoldás, mint a rewriteRule...
6

Ovatosan!

janoszen · 2013. Jan. 31. (Cs), 11.53
Ovatosan az ilyen varazslatokkal! Egy-ket ismeros mar befurdott azzal, hogy nem ertette, hogy a vadiuj, meregdraga szervere hogy a francba koppan ki par szaz latogatotol. Kiderult, hogy profilkepeket rakott ki es konvertalta kisebb meretre minden lekerdezeskor. Az ilyesmit alapvetoen feltoltes utan illik csinalni, nem lekerdezeskor!
7

Ezzel teljesen egyetértek, de

sandrosdj · 2013. Jan. 31. (Cs), 13.06
Ezzel teljesen egyetértek, de én sem méretezem át feltöltéskor, viszont használok cache-t. A képeket a php fájl méretezi át majd lementi egy cache mappába. A mappa tartalma automatikusan, bizonyos időközönként törlődik, és amikor nem található a cache mappában a beágyazott kép, akkor elkészíti újra majd menti oda. Ha meg már ott van, onnan olvassa ki és nem méretezi újra.
8

Hat...

janoszen · 2013. Jan. 31. (Cs), 13.40
Hat kerdes, hogy ez jo-e neked. Igy eleg konnyu megszivatni azzal, hogy elkezdek tolni egy csomo HTTP HEAD requestet regi kepekre. Nincs eleg kapacitasod a kis kepek tarolasara, vagy mi a baj?
9

Egy kép túl sok méretben

sandrosdj · 2013. Jan. 31. (Cs), 15.20
Egy kép túl sok méretben kell, ezért nem találtam gazdaságosnak már az elején elkészíteni az összes méretben plusz ha a közeljövőben más méretben is kellenek a képek, akkor mindenkinek újra el kellene készíteni mindet.

De ha mégis le lenne mentve mind külön-külön és van olyan kép, amit nagyon ritkán, vagy szinte soha nem használ az oldal vagy nem nézik meg, akkor fölöslegesen foglalja a tárterületet. A cache 24 óránként törlődik és ha egy kép egy méretben már le van mentve, akkor nem méretezi újra, csak kiolvassa onnan.

Azt, hogy ne tudjanak mindenféle méretet kérni, azt hiszem le lehet korlátozni valahogy.
(48|64|120...)
10

Célszerűbb csak azokat

Joó Ádám · 2013. Jan. 31. (Cs), 18.28
Célszerűbb csak azokat törölni a gyorstárból, amik bizonyos ideje nem lettek lekérve, így sok erőforrást megtakarítasz.
12

ha utólag kell...

_subi_ · 2013. Feb. 1. (P), 12.43
ha a közeljövőben más méretben is kellenek a képek, akkor mindenkinek újra el kellene készíteni mindet


Ha utólag kell egy méret, még mindig írhatsz egy cron jobot, ami végigfut a már feltöltött képeken, és elkészíti a hiányzó méretet.
13

Ha van 100ezer kép, amelyről

sandrosdj · 2013. Feb. 1. (P), 22.26
Ha van 100ezer kép, amelyről el kell készíteni az új méretet, az nagyon terhelné a szervert, ráadásul nincs kész az összes egyszerre és ha limitálom, hogy percenként futtassa le az átméretezést 20-30 képre, az is rengeteg időt vesz igénybe, nem beszélve arról, hogy nagyon sok tárterületet foglal. A tartalom szerverek közötti szinkronizálásakor nagyban megnövelné az adatforgalmat is.
14

A kontrollálhatatlan számú

BlaZe · 2013. Feb. 2. (Szo), 01.39
A kontrollálhatatlan számú párhuzamos képkonvertálás lehetőségét mindenképpen iktasd ki a képletből (ha nincs alapból), tehát a méretezést magát szerintem ne az image_gear.php végezze. Illetve ahogy szabo.b.gabor is javasolta, csak akkor rewrite-olj a php-re, ha nincs meg a lekonvertált kép (RewriteCond). Ezekkel el tudod kerülni, hogy letérdeltessék a gépet. Max a userek átmenetileg nem látnak pár képet, ha olyan durva terhelésed van, hogy a konverter processek nem győzik adott időn belül szállítani az új méreteket.
17

Köszönöm az

sandrosdj · 2013. Feb. 3. (V), 15.54
Köszönöm az ötletet!

Beiktattam egy RewriteCond-ot is, amely ellenőrzi, hogy a gyorsítótárban már megtalálható-e az adott kép és ha igen, akkor egyből azt nyitja meg, nem pedig php-n keresztül.

A php fájl csak annyit csinált ezelőtt (abban az esetben, ha már meg volt a kész kép), hogy fejlécben beállítja a tartalom típusát majd beolvassa a képfájlt readfile()-lal.
19

Bár itt valószínűleg kis

BlaZe · 2013. Feb. 4. (H), 11.10
Bár itt valószínűleg kis file-okkal fogsz dolgozni, akkor is ritkán, és ebből nem lesz gondod, de a readfile()-lal érdemes óvatosan bánni, mert az egész file-t beolvassa a memóriába, és onnan nyomatja ki. Érdemesebb ciklusban valamekkora blokkokban kiküldeni a tartalmát.

A másik, hogy így visszaolvasva nem volt túl részletes, amit az image_gear.php-ról mondtam. Tehát ha esetleg nem sikerült jól átadnom a gondolatom, valami ilyesmit kéne csináljon az image_gear.php-d:

- Bedob egy queue-ba egy konvertálás requestet (melyik file, hova tegye a konvertáló stb)
- Vár a válaszra egy bizonyos timeoutig. Ha timeout volt, akkor http error.

A queue lehet valami queue szerver, vagy sima adatbázis tábla stb, az mindegy.

A másik oldalon pedig n db konverter process, ami pollozza ezt a queue-t, és indítgatja a konvertálást, amikor beérkezik egy request. Az eredményt pedig visszatolja a queue-ba, ahonnan az image_gear.php leveszi (ha nem timeoutol-t el közben). Így dinamikusan tudsz méretezni, ha kell gyorsan be tudsz állítani új konvertáló gépet, ha a meglévő nem bírja az iramot, és 100 requestre nem indul 100 konvertálás, csak n db.

Aztán ha úgy hozza a szükség, lehet priorizálni is a requesteket, hogy azonnali kiszolgálásra kell a konvertálás, vagy valami upload/admin funkcionalitás miatt kell konvertálgatni, és ráér később. Vagy pl az image_gear.php jelezheti, hogy eltimeoutolt, és akkor annak kisebbre lehet venni a prioritását, hogy az élő requesteket tudja kiszolgálni a konverter.
20

Bár itt valószínűleg kis

Joó Ádám · 2013. Feb. 4. (H), 16.38
Bár itt valószínűleg kis file-okkal fogsz dolgozni, akkor is ritkán, és ebből nem lesz gondod, de a readfile()-lal érdemes óvatosan bánni, mert az egész file-t beolvassa a memóriába, és onnan nyomatja ki. Érdemesebb ciklusban valamekkora blokkokban kiküldeni a tartalmát.


Nem, a readfile() lényege épp az, hogy közvetlenül másolja lemezről a kimenetre az adatot (vö. Linux sendfile()).

A kézikönyvből:

readfile() will not present any memory issues, even when sending large files, on its own.
21

Akkor ez azóta vagy

BlaZe · 2013. Feb. 4. (H), 17.10
Akkor ez azóta vagy megváltozott, vagy inkább output buffer volt, de én láttam szervert hanyatt esni readfile()-tól. Videoklipet töltöttek így le, és megették a memóriát pár párhuzamos requesttel. Rég volt, nem emlékszem rendesen, nem is ismertem a rendszert, csak a probléma rémlett, de ezek szerint rosszul :)
22

Ez nem rossz ötlet, viszont a

sandrosdj · 2013. Feb. 4. (H), 19.22
Ez nem rossz ötlet, viszont a tudásomhoz mérve a kivitelezése elég időigényes lenne. Mindenesetre a válaszod megjelöltem magamnak, így ha több időm lesz a dolgokra, elő fogom venni.

A readfile() elvileg nem a memóriába tölti az adatot, épp ezért használom ezt, nem pedig fopen és 2ezer byte-onként olvastatom ki (ez lassabbnak tűnik).
15

Kicsit off

Pepita · 2013. Feb. 2. (Szo), 09.49
Ne haragudj, de honnét van (egy site-on) 100e kép? Nekem ez kínai, homályosíts fel.

De ha van is, az átméretezés mindig elég "vasigényes", tehát a többféle méretben tárolás kevésbé "költségesnek" tűnik. Persze a szinkronizálás is szempont, de mikor egy oldalra kell pl. 10-20 képet egyszerre méretezni, azt a látogató már igencsak észre fogja venni futásidőben.

Szerintem itt a szoftver logikai struktúráját újra kéne gondolni, úgy tűnik, hogy több irányban is feszegeti a határokat, ami csak bajt szokott szülni.
16

Ne haragudj, de honnét van

Joó Ádám · 2013. Feb. 2. (Szo), 17.18
Ne haragudj, de honnét van (egy site-on) 100e kép?


Fényképmegosztó?
18

Ja-ja

Pepita · 2013. Feb. 3. (V), 18.32
Ez kimaradt a fantáziámból...
Akkor viszont pláne necces a "röptében" méretezés.
11

rewriterule csak akkor

szabo.b.gabor · 2013. Jan. 31. (Cs), 21.04
rewriterule csak akkor érvényesüljön, ha nem létezik az adott fájl, és a 'cache' képet mentsd arra a helyre, ahonnan amúgy is lekérik.

így ha megvan már a legenerált kép, akkor a php kört már egyáltalán nem kell lefutni.