ugrás a tartalomhoz

PHP osztályok lassúak

deejayy · 2008. Jan. 29. (K), 10.50
Sziasztok,

elkezdtem írni egy keretrendszert php-ben, és OO alapúra akarom csinálni.
Létrehoztam pár teljesen tipikus osztályt (page, input, form osztályok).

Ha csak beinclude-olom azt a 8 osztályt, ami eddig megvan, a betöltési
idő 0.0005-ről 0.0026-ra ugrik meg. Ha példányosítom is őket, akkor 0.0034-re.

A későbbiekben tervezem majd az __autoloader használatát, és láttam tippeket
valami EAccelerator nevű szoftver alkalmazására is, de a kérdésem az, hogy
normális-e hogy csak az osztályok betöltése ilyen mértékben megnöveli az
oldal betöltését?

Lehet ez ellen tenni valamit, gyorsítani?

Üdv,
dj
‹ a legjobb teljesítmény titka Elektronikus kosar ›
 ■
1

Durva...

janoszen · 2008. Jan. 29. (K), 12.41
Ennyire nem kellene lassúnak lennie, én már építettem pár tucat osztályból is rendszert és nem volt érezhetően lassabb... esetleg tedd föl a kódot valami más szerverre és nézd meg ott az időket, hátha csak a Te konfigurációd bohóckodik.
2

Gyorstárazás

Nagy Gusztáv · 2008. Jan. 29. (K), 12.50
Másrészt a gyorstárazás segítségével az esetek jó részében csak bizonyos osztályokat kell betölteni, példányosítani, így az _átlagos_ időigény nem lesz olyan vészes.
3

kipróbáltam

deejayy · 2008. Jan. 29. (K), 14.17
Kipróbáltam egy másik szerveren is a kódot, ott lényegesen gyorsabb volt, köszönhetően az erőforrásoknak.

Viszont: lemértem az időigényeket a betöltetlen/betöltött/példányosított osztályokkal, és sajnos azt tapasztaltam, hogy mindkét szerver esetében hasonlóan arányulnak a számok.

Tehát lehet, hogy a gép gyenge, de az osztályok betöltése bizony itt is és ott is ugyanannyi erőforrásba kerül.
4

Osztályok?

vbence · 2008. Jan. 29. (K), 16.03
Ezt most úgy írod, mintha magának az "osztály" használatának lennének káros hatásai. Kipróbáltad, hogy nem osztályokat töltesz be, csak kilóra ugyanegyenennyi procedurális kódot? Mennyivel lassabb ennél az OO megoldás?
5

nem rossz

deejayy · 2008. Jan. 29. (K), 16.21
Hm, nem rossz ötlet, ki is próbáltam egy korábbi függvénykönyvtárammal, ami byte-ra kétszer akkora, és több valódi függvény is van benne.

Az eredmény alapján kezd közelíteni a valósághoz: kb. ugyanannyi idő volt, mint az osztályok betöltése. Ugyanakkor megdöbbent, hogy a 2 xeon processzorral futó gépen hogyan tarthat 0.0034 másodpercig 8 osztály betöltése. A rendszer nem mondható terheltnek, a load alig megy 0.3 fölé.

Ezzel a tendenciával 30-50 osztály betöltése akár 0.02 másodpercig is eltarthat, és akkor még nem is csináltam semmit. Egy ilyen "üres" oldalból másodpercenként 50-et tudok legenerálni, ami egyáltalán nem mondható soknak, itt lenne a php-nek a határa?

Mivel tudok még gyorsítani? FastCGI? Lightthpd?
6

Valami nem stimmel...

janoszen · 2008. Jan. 29. (K), 17.36
Ezeknek a méréseknek van egy pontatlansága, valahogy mindig rájöttem, hogy 1+1 mégsem 2 hanem csak 1.5. Ha pontos teszteket szeretnél, dobd föl valahova a kódot, játsszunk kicsit a profilinggal.
7

profiler

winston · 2008. Jan. 29. (K), 20.25
esetleg valami profiler-t futtass rajta, hogy megtudd, mi a lassú
13

javaslat?

deejayy · 2008. Jan. 30. (Sze), 11.43
Van javaslatod linuxon futó php profiler-re?
31

van :)

winston · 2008. Jan. 31. (Cs), 13.30
xdebug-gal el tudod készíteni a profilt, aztán KCacheGriddel (KDE-s) meg tudod nézegetni, jópár nézetben
8

törlendő

winston · 2008. Jan. 29. (K), 20.25
kétszer ment be, szóri. törlendő
9

csúnyán is néznénk ki...

TeeCee · 2008. Jan. 30. (Sze), 00.00
... ha minden oldalletöltésre 30-50 osztályt kellene behúzni, példányosítani, működtetni...
Csak jelzem, hogy célszerű csak azt behúzni, ami kell és nem többet.
A másik hiba a túlságosan szétcincált fájlokkal szokott lenni. Ha nem használsz fájl-gyorsítást (APC vagy eAccelerator), akkor ha 50 fájl húzol be az qrrva sokáig fog tartani. Persze mindezt képzeld el milliszekundumokban.

Amúgy mivel lenne 30-50 fájl? Csak érdekelne, hogy miket szeretnél külön pakolni?
10

Szétcincálás...

janoszen · 2008. Jan. 30. (Sze), 07.58
Ja igen, juccembe, szétcincálás. Megteheted hogy az összes osztályt összemásolgatod egy fájlba (akár automatikusan is) és akkor nincs annyi diszk IO.
11

10 include vs 10x méret?

Dualon · 2008. Jan. 30. (Sze), 10.56
Inkább tíz include, vagy inkább tízszeres állományméret? (Nekem lokálban a nagyobb állományok jobb eredményt adtak, de egyrészt szívesebben include-olok többet, rendezettebbnek érzem úgy a kódot, másrészt nincs pofám éles szerveren tesztelni.)

A kérdés tulajdonképp megfogalmazható úgy is, hogy proc.idő, vagy memóriafoglalás, ugye?
32

inkább 10x méret

winston · 2008. Jan. 31. (Cs), 13.32
inkább legyen 10xes méret, lévén az még mindig gyorsabb, mint 10 fileművelet
34

pontosítás :)

Hodicska Gergely · 2008. Jan. 31. (Cs), 16.21
Ez így önmagában nem igaz, az hogy melyik megoldás jobb, az attól függ, hogy van-e opcode cache.

Ha nincs, akkor azzal jársz jobban, ha több fájlba bontos szét a dolgaid, és mindig akkor töltesz be valamit, amikor szükség van rá. Ez logikus is, hiszen az értelmezőnek ilyenkor a kódot le kell fordítania byte kódra, tehát minél kevesebb a kód, annál gyosrabb.

Ha van opcode cache, akkor ez nem számít, hisz csak egyszer történik meg. Ez esetben az a jobb, ha egy fájlban húzod be a dolgokat, mert a behúzással kapcsolatos járulékos költség csak egyszer szerepel.

Nem olyan régi verzióban teszteltem ezt. Éles rendszerben használt főbb include-okat másoltam össze, kb. 10 db. file. Opcode cahce nélkül a külön fájl esetében ha csak pár fájlt húztam be, akkor jóval gyorsabb volt, mint az egy nagy fájl. Olyan 7-8 fájl környékén (ez kb. a kódok 80%-a volt) lett egálban a kettő. Opcode cache esetében már 3 fájl behúzása is lassabb volt, mint az egy nagy. Ráadásul a különbség attól is függött, hogy mennyire terhelt a gép IO-ban. Kitettem éles szerverre (durván terhelt), és ha behúztam külön az összes fájlt, meg az egy nagyot, akkor az előbbi 8-szor lassabb volt.


Üdv,
Felhő
39

Köszönöm!

Dualon · 2008. Jan. 31. (Cs), 18.26
Köszönöm a visszajelzéseket, a beszámolót, a tapasztalatnál nincs jobb. :)
42

oké, pontatlan voltam

winston · 2008. Feb. 1. (P), 08.26
jogos, kicsit sarkalatos volt a hozzászólásom. akkor részletezem, hogy csinálom: két felé van bontva a kódom. az első "csoportba" az kerül, ami minden alkalommal, vagy az esetek nagyon nagy részében kell. ezek bekerülnek egy fileba, amit az elején includelok. a többi meg, amik relatíve ritkábban kellenek, azokat a megfelelő helyen rántom be (autoloaddal, ami kicsit lassabb, mintha valami if-ágas berántást alkalmaznék, de mindenféleképpen rugalmasabb)
12

félreért.

deejayy · 2008. Jan. 30. (Sze), 11.42
Nem 30-50 fájl lenne, hanem annyi osztály. Ezeket valamilyen logika alapján 8-10 fájlba akarom majd szervezni.

Jelenleg 3 fájlból töltődnek be az osztályok, amiknek együttes helyigénye nincs 5k sem.

Amúgy miért lenne furcsa 30-50 osztállyal dolgozni egy komplex weblap esetében?
14

sajátomban...

TeeCee · 2008. Jan. 30. (Sze), 13.22
Megírtam, aztán elolvastam mégegszer amit írtál, nehogy elbeszéljünk egymás mellett.
Azt írtad: 30-50 osztály betöltése.
Egy komplex weblap esetében lehet több is, kevesebb is nincs mindenre kenőcs. De én alapból soknak tartom egy általános portálhoz.
Betölteni IMHO csak azt kell, ami kell is. Ha úgy csinálod meg, hogy mindegyik csinál is valamit, akkor már más a helyzet.

... (merthogy nekem is van saját objektumokból felépített portálmotorom :D ) nincs ennyi és remekül megy ;-)
Amik feltétlen kellenek: modul szülőosztály, abból származtatva a moduljaim (ilyen sorrendben is töltődnek be): portal, log, dblayer, user, template. (A dblayer az adboDB-re, a template pedig a smarty-ra egy réteg). Ezen kívül az éppen kívánt tevékenységhez tartozó modul (pl: guestbook, vagy gallery) és a tevékenység objektuma van még. Ez összesen: 12 körül van. Ezen felül ugye a formGenerator, de az csak form esetében kell, ahhoz van validator, stbstb...
Ha nagyon összeszámolom, akkor még mindig 20 alatt vagyok. (Csak az admin esetében van olyan, hogy mindent be kell tölteni, ha kíváncsi vagyok pl. az összes modul összes tevékenységére, mivel ezt az objektumokból mondon meg...)

Másik kérdéskör, hogy 1 nagy, vagy sok kis fájl ezt tudom mondani: én minden modult és minden tevékenységet külön fájlban tartok. Ami olyan objektum, ami önmagában nem fordulhat elő, csak egy tevékenységgel (pl. validator egy űrlaphoz, ami ugye egyedi és tudjuk, hogy hol fordul elő), azt még belerakom az objektum mellé.
Általában egy tevékenység (pl. modul: vendégkönyv, tevékenység: olvasás) kiszolgálására az alapfájlokon kívül csak 3 fájlt kell behúzni: vendégkönyv modul, olvasás tevékenység és az ehhez tartozó template (megjelenítési) fájl.

(kis csúsztatás azért van a dologban, mert jelen pillanatban ha a főoldalon mindenféle modulokhoz tartozó boxok - pl. a nap képe, szavazás, user stat, stb - van, akkor MÉG betöltheti azokat a modulokat is, de ezt már elkezdtem kiváltani megfelelő cache-eléssel. Ilyesfajta felépítéssel, mostmár lassan 2 évvel korábbi fejlődési szakaszban lévő, egyik egyetemi HÖK-által használt portál a főoldalon hírek, user stat, szavazás boxokkal 0.07 körül generál egy régi, egymagos intel P4-en, eAccelerator és APC nélkül. - a mostani rendszer cache-ből nyomná szinte az egészet.)

ööö... izé...
érthető volt, vagy túl gyors? Az biztos, hogy mindenki máshogy csinálja, de szerintem az alapelvek ugyanazok a gyorsaság érdekében:
- minél kevesebb fájlt behúzni
- (de) minél átláthatóbban szervezni a fájlokat és az objektumokat
- mindent, amit csak lehet, cache-elni

Ha ezen felül van kérdés, akár magánba is jöhet, ha nagyon eltér a témától...
15

tervezési minták, mvc

gex · 2008. Jan. 30. (Sze), 13.31
factory, stb mintákkal nagyjából meg is dupláznád az osztályaid, mvc-vel meg megháromszoroznád. persze ez így nem igaz, de valószínűleg te is elérnéd a 40-50 osztályt.
16

aláírom...

TeeCee · 2008. Jan. 30. (Sze), 13.44
... igazad van
17

nagyon oo?

deejayy · 2008. Jan. 30. (Sze), 14.26
Előrebocsátanám, ha eddig nem tettem, hogy a napokban írtam be az első 'class' szócskát php forráskódba. Egy igen alapszintű OO szemléletem van, mert delphiben aktívan programozok, illetve esetileg programoztam már javaban is.

Én kb úgy képzeltem el, hogy van egy 'input' objektumom, amiből származik az editbox, passwordbox, hidden, memo, etc. Ezekből lesz majd egy loginform objektum, stb, stb, stb.

Szóval ha ilyen módon belegondolsz, akkor már logikusabbnak tűnik, ha azt mondom, lesz 50.
18

nem

dOMiNiS · 2008. Jan. 30. (Sze), 14.38
nem
19

ööö

deejayy · 2008. Jan. 30. (Sze), 14.51
ööö, karaj!
20

naja..

Szekeres Gergő · 2008. Jan. 30. (Sze), 15.11
én is próbáltam igy modellezni. szerintem ez az a rész, ami nem hatékony. phpban azért egy függvényhívás/leszármazás viszonylag lassan fut, szerintem ennyire már felesleges objektumokként kezelni mindent.. így nem 50 osztályod lesz, hanem kb500!:)
22

ha már lúd

deejayy · 2008. Jan. 30. (Sze), 15.41
Ha már alkalmas OO fejlesztésre, akkor szeretném kihasználni.

Annak nem sok értelmét látom, hogy egy egész vendégkönyvet mondjuk egy osztályba tenni, semmivel nem fog különbözni a hagyományos struktúrális megközelítéstől (kivéve, hogy írni kell egy 'class'-t a forráskód elejére).

Szeretném a lehető legportábilisebbé és újrafelhaszhatóvá tenni.

ps: kipróbáltam fastcgi-vel is a futtatást, LASSABB! lol? :D
26

Tök korrekt

janoszen · 2008. Jan. 30. (Sze), 19.53
Szerintem, ez a fajta hozzáállás tök korrekt. Így lehet értelmesen sablonozni ha az ember nem akar kézzel HTML-t berhelni. Én is ebbe az irányba megyek el. Aztán a kigenerált kódot meg úgy lehet cache-lni mint annak a rendje. Arról nem is beszélve, hogy van kb 80 HTML tag, abból gyártasz komponenseket és minden oldalon csak azokat a komponenseket húzod be, amikre feltétlenül szükséged van... szóval akár működhet is, nekem minden esetre tetszik a komponensesdi megoldás.
23

Lehet, de lehet rajta javitani

Protezis · 2008. Jan. 30. (Sze), 16.52
En is irtam egy ilyen "keretrendszerecsket" (bar csak 1 projektben hasznaltam, azota cakephp-zok). Nem volt az rossz otlet, nem veletlenul objektum minden a nagyobb rendszerekben (.NET, Java stb.). Viszont pont tegnap gondoltam bele, hogy ha sok minden van egy oldalon (tele form elemekkel, stb.), akkor a pehelysulyu mintaval talan lehetne segiteni a dolgon.

Ekkor nem kell minden pl. inputtext-nel uj objektumot letrehozni, eleg csak a kulso tulajdonsagokat atadni az esetlegesen mar letezo egyetlen objektumodnak.
24

ömm

deejayy · 2008. Jan. 30. (Sze), 16.56
Lehetséges, hogy nem egészen értem, mire gondolsz.

Kifejtenéd egy példával mondjuk?

Köszi.
25

Pehelysulyu minta

Protezis · 2008. Jan. 30. (Sze), 17.59
abstract class AbstractHtmlObject {
	protected $id;
	protected $name;
	
	abstract protected function printHtml($context);
	abstract protected function printXml($context);
	abstract protected function printRss($context);
}

class AbstractHtmlObjectFactory {
	private static $instance = null;
	private $formELements;
	
	private function __construct() {
		$this->formElements = array();	
	}
	
	public function CreateFormElement($type) {
		//vagyis minden AbstractHtmlObject osztalybol szarmaztatott osztalybol legfeljebb 1 peldany letezik
		//tehat csak 1 InputText objektum lesz
		if (!isset($this->formElements[$type])) {
			$this->formElemenst[$type] = new $type();
		}
		return $this->formElements[$type];
	}

	public static function &GetInstance() {
		if (self::$instance == null) {
		    self::$instance = new AbstractHtmlObjectFactory();
		}
		return self::$instance;
	}
}

class Context {
	protected $class;
	protected $options = array();
	//...

	public function setClass($class) {
		$this->class = $class;
	}
	
	public function getClass() {
		return $this->class;
	}
	//..
}

class InputText extends AbstractHtmlObject {
	public function printHtml($context) {
		// meg kellene nezni, be vannak -e allitva a kulso tulajdonsagok
		return '<input type="text" class="'.$context->getClass().'" name="'.$this->$name.'" id="'.$this->$id.'" ...';
	}
}

class Select extends AbstractHtmlObject {
	public function printHtml($context) {
		// meg kellene nezni, be vannak -e allitva a kulso tulajdonsagok
		$ret = '<select name="" ... ';
		foreach ($context->options as $value => $label) {
			$ret .= '<option value="'.$value.'">'.$label.'"</option>';
		}
		...
	}
}

$context = new Context();
$context->setClass("required");

$ahoFactory = AbstractHtmlObjectFactory::GetInstance();
echo $ahoFactory->CreateFormElement('InputText')->printHtml($context);
Nem teszteltem, most utottem ossze. Eddig meg nem hasznaltam ezt a mintat. Biztos van benne hiba, de talan jol szemlelteti a lenyeget. Akkor hasznos, ha sok ugyanolyan (pl sok inputtext) elemet hasznalsz egy oldalon.

Ha a kulso tulajdonsagok mindig masok, akkor nem erdemes azokat kulon context-ben tarolni, erdemesebb atadni azokat egybol a - jelen esetben - printHtml()-nek.
27

Hajjaj...

janoszen · 2008. Jan. 30. (Sze), 19.55
Miért kell ennek Factoryt gyártani? Csinálsz egy XHTMLTextfield osztályt származtatva oszt csókolom. :)
28

Kicsit atgondoltam jobban

Protezis · 2008. Jan. 30. (Sze), 21.12
A kovetkezo osztalyt hasznaljuk, es nem kell az InputText es Select ... stb. osztalyok.
class FormElement extends AbstractHtmlObject {
	private $type;

	public function __construct($type) {
		$this->type = $type;
	}
	
	public function printHtml($context) {
		$ret = '';
		switch ($type) {
			case 'textfield': $ret = '<input type="text" class="'.$context->attributes['class'].'" />';
				break;
			case 'submitbutton': $ret = '';
				break;
			//...
		}
		return $ret;
	}
}
Es az AbstractHtmlObjectFactory osztalyban irjuk at a kovetkezo fuggvenyt:
public function CreateFormElement($type) {
	if (!isset($this->formElements[$type])) {
		$this->formElemenst[$type] = new FormElement($type);
	}
	return $this->formElements[$type];
}
Igy mindossze 1 osztalyunk lesz az osszes form elemhez, es annyiszor peldanyositjuk azt, ahany fele elemet hasznalunk. A CreateFormElement()-nek atadhatnank meg a $context-et (es nevezzuk at formElement()-re), es nem az elemmel, hanem a megfelelo kiiro fuggveny (amit korabban beallitottunk) eredmenyevel terne vissza (aminek tovabbadna a $contextet).
Igy hasznalhatnank valami ilyesmit:
echo $ahoFactory->formElement('textfield', new Context(array('id' => 'login_name', 'class' => 'textfield')));
Persze mindezt meg lehet csinalni ugy, hogy singleton mintaval peldanyositjuk a FormElement-et, es a printHtml()-nek adjuk at a tipust es a parametereket is.
Igazabol most megakadtam, nem latom a pehelysulyu minta elonyet. Valaki felvilagositana? :)
30

nem biztos

deejayy · 2008. Jan. 31. (Cs), 12.21
Nem biztos, hogy jól értitek, amit akarok.

A fenti példád szinte alig különbözik egyetlen eljárástól, ami feldolgozza a kapott inputot, és kiír egy html-t.
Ez a switch-es megoldás pláne.

Mi van akkor, ha a $context->attributes['class'] üres érték? Bekerül a html-be, hogy class=''.
Fölösleges kód, fölöslegesen letöltendő byte-ok.

Az meg a másik, hogy mondjuk csinálsz egy switch-et:
textfield: <input type='text' class='$...' value='$...' id='$...'>
passwordfield: <input type='password' class='$...' value='$...' id='$...'>
stb.

Egymás után többször leírod, hogy class='$...', value='$...', nem optimális.
33

Nem ez a lenyeg

Protezis · 2008. Jan. 31. (Cs), 15.28
A leglenyegtelenebb dolgot sikerult leszurnod. Odairtam, hogy nyilvan figyelni kell, melyik tulajdonsag van beallitva, es ennek fuggvenyeben kell osszeallitani a stringet.
A lenyeg, hogy objektumokkal dolgozol, de megsem nonek a fejedre, mert minden tipusbol csak 1 van.

Az, hogy erdemes -e igy csinalni, nem tudom, mindenesetre jobb megoldas, mint ha minden elem kulon objektum lenne.
36

"objektumokkal dolgozni"

Hodicska Gergely · 2008. Jan. 31. (Cs), 16.43
Szerintem a fenit megközelítés kb. a legrosszabb, amit el lehet képzelni. Ilyen formában nincs értelme OOP-t használni. Nem az a lényeg, hogy objektumokkal dolgozz, hanem hogy megfelelően oszt szét a felelősségeket, jól használható, független részekre bontsd a kódodat.


Üdv,
Felhő
38

nem értem mit akarsz..

Szekeres Gergő · 2008. Jan. 31. (Cs), 18.17
szerintem azoknak kell külön osztály, ami máshogy néz ki.. pl:

abstract class FormElement{
 protected $name;
 protected $class;
 ...
 abstract getElement();
}

class TextField extends FormElement {
 protected $type;
 public function getElement() {
   return "<input type=\"".$this->type."\" name=\"".$this->name."\">";
 }
}

class SelectField extends FormElement {
 protected $options = array();
 public function getElement() {
   return //stb...
 }
}
valamint mindegyik mezőnek az osztályokban van egy getMezőnév metódusa, ami visszatér az adott attribútommal, ha pedig üres az adott mező, akkor visszatér a nagy semmivel. Így a getElement mezőbe egyszerüen cask ezeket meg kell hívogatni, nem kell ott már "ifezni".
35

& a függvény definícióban

Hodicska Gergely · 2008. Jan. 31. (Cs), 16.39
Én is csak átfutottam, & biztosan nem kell a kódba (vagy public ;)).


Üdv,
Felhő
40

Nem kell, de nem is baj

Protezis · 2008. Feb. 1. (P), 00.47
A publicot jobb szeretem kiirni. A referenciajel pedig lehet, hogy nem kell, de hogy mukodik igy is, az biztos (tobb helyen is igy hasznalom a singleton patternt)

Egyebkent tenyleg feleslegesnek tunik a fenti megoldas, agyuval verebre loves esete all fenn. De azert jo volt igy belegondolni (foleg vizsga elotti este :) )
41

PHP4 vs PHP5

Hodicska Gergely · 2008. Feb. 1. (P), 00.53
Nem esett le teljesen: a public arra utalt számomra, hogy PHP5-beli kódról beszélsz, ott viszont az objektumok referenciaként adódnak át, ezért nincs értelme &-t használni. Plusz szerintem E_STRICT mellett még warningol is ezért a PHP, de erre most nem vennék mérget.


Üdv,
Felhő
29

erre gondoltam én is...

Szekeres Gergő · 2008. Jan. 31. (Cs), 10.08
sztem (is) tök felesleges kismillió objektummal dolgozni, ésszerűen kell használni, különben - legalábbis számomra - egy idő után, ugyan olyan átláthatatlan lesz az egész.
21

a végén include optimalizálás

Szekeres Gergő · 2008. Jan. 30. (Sze), 15.13
én azt szoktam, mint adatbázis esetén is szokás volt: mikor még készül a 'cucc', akkor még szét vannak szépen szedve külön fileokba. majd amikor már kész van, és látom hogy mikor mit mivel használsz, akkor próbálom úgy összevariálni, hogy amit egyszerre használok általában, azt egy fileba tartom. persze ez így elég nagy meló a végén, de ennél jobbat én még nem tudtam kitalálni.. :(
37

build folyamat

Hodicska Gergely · 2008. Jan. 31. (Cs), 16.55
A fejlesztés oldaláról tekintve mindenféleképpen érdemes külön tartani a dolgokat, és mondjuk commitkor vagy élesítéskor egy build folyamat pakol össze bozonyos fájlokat egybe. És akkor mindenkinek jó.


Üdv,
Felhő
43

apd

deejayy · 2008. Feb. 13. (Sze), 20.28
Nah, kipróbáltam egy profilert, vagy mit: apd 1.0.1-et.

Top 5 esemény:
Real         User        System             secs/    cumm
%Time (excl/cumm)  (excl/cumm)  (excl/cumm) Calls    call    s/call  Memory Usage Name
--------------------------------------------------------------------------------------
42.9 0.01 0.05  0.00 0.02  0.01 0.03    10  0.0000   0.0000            0 require
14.3 0.00 0.00  0.00 0.00  0.00 0.00    22  0.0000   0.0000            0 define
4.8 0.00 0.01  0.00 0.00  0.00 0.00    34  0.0000   0.0000            0 sprintf
4.8 0.00 0.00  0.00 0.00  0.00 0.00     7  0.0000   0.0000            0 logerr
4.8 0.00 0.00  0.00 0.00  0.00 0.00     1  0.0000   0.0000            0 mysqli->mysqli

Tehát az IO a nagy. Lehet ez ellen valamit tenni?
- memcached (hogyan include-olok?)?
- xcache (nem mukodik nekem)?
- egyéb ötlet?

A második, amin eléggé csodálkozom, az a define. Ez tényleg ennyire költséges művelet, elkerülési lehetőség van? (azon kívül, hogy nem használom)
44

re: apd

zmb · 2008. Feb. 13. (Sze), 20.37
Memcached itt talan nem hoz annyit, elvegre io ott is van (socketen keresztul). Akkor hasznos, ha nagyobb mennyisegu adatot akarsz tarolni, aminek koltseges az elloallitasa (pl db-bol jon)

xcache nekem teljesen jol mukodott, de lehet hasznalni mast is (eacceleratort nem ajanlom, ugy tunik sok bugja van). Lenyegeben azon tudsz gyorsitani, hogy a) bent tartod a memoban a berantott fileokat (ilyet altalaban tudnak az opcode cache-ek); b) memoban tartod a lefordiott php kodokat (ilyet is tudnak az opcode cache-ek).

Egyeb otlet: sose nem probaltam, de talan ha ramdrivera rakod a php fileokat talan csokken egy kicsit az io. Opcode cache hasznalata erose javallott.
45

Ó, kipróbáltam :)

deejayy · 2008. Feb. 14. (Cs), 09.57
Kipróbáltam a ramdisk-et, mert nekem is az volt az ötletem, de sajnos nem volt túl effektív (0.0004 volt az átlagos különbség).

XCache-sel nem tudom mit kellene tennem, de amint beteszem, szór nekem mindenféle php errorokat, amiket még nem volt időm kinyomozni, így hát nem is próbálkoztam vele sokat.

eAcceleratort kipróbáltam, ami igen effektív volt: felére, vagy még kevesebbre csökkentette a render időt (a jelenlegi weblapomat átlag 0.045-ről átlag 0.012-re vitte le, ezt az osztályos mókát 0.01-ről 0.005-re)

Ugyanakkor az apd-vel néha összeakad, és conncetion reset by peer lesz belőle. Egyelőre éles lapokon nem használom az apd hívásokat, így talán ez elkerülhető.

Miket tudnék még kipróbálni? (az mmturck már abandoned, ha jól tudom).
46

Na ez meg aztán...

deejayy · 2008. Feb. 24. (V), 21.58
Érdekes jelenségre lettem figyelmes a tesztelés során.

Mint azt korábban írtam, van egy weblapom, aminek a betöltési idejét sikerült lejjebb vinnem 0.045-ről 0.012 másodperc körülire (eAcceleratorral). Ezzel párhuzamosan ugyanezen a szerveren tesztelem ezt az osztályos mókát is, ami miatt a témát is nyitottam. Ott a 0.01-es render időt szorítottam le 0.005-re eAcc-cal.

A vicces az, hogy valamilyen okból kifolyólag a 0.005 váratlanul felugrik úgy 0.03-ra (általában napok kérdése). Az okát még nem sikerült kiderítenem, figyeltem a performanciát, load-ot, memóriát, szinte semmi változás nincs. Az éles weblapom betöltési ideje nem változott, csak az osztály-tesztelős kódé (mindkettőt ugyanaz a php, apache, mysql szolgálja ki - mindkettő http, tehát nem https). Ha megnézem APD-vel, hogy mi teszi ki az értelmezés nagy részét, akkor a file betöltést teszi első helyre, többnyire 30-45%-kal.

Miután nem találtam semmi okot a megnövekedett generálási időre, újraindítottam az alatta futó apache-ot.
És láss csodát: a render idő visszaesett 0.005-re.

Ennek meg mi lehet a magyarázata?
47

Milyen rendszer?

janoszen · 2008. Feb. 25. (H), 08.10
Milyen rendszeren milyen PHP futtatóval? mod_php vagy FastCGI? Esetleg ha megmutatod az osztály-tesztelő kódot, az segíthet, hátha valami bug van benne.