Autoload kešatmiņa?

[F3llony]

Pašreizējā situācija - iespējams izmantot vai nu PHP iebūvēto autoload implementāciju, vai PSR-0 atbilstošu implementāciju. Pirmajā gadījumā ielādi veic core, pārbaudot katra faila, PATH un paplašinājuma kombināciju. Otrajā gadījumā pārbaudi pret eksistenci neveic (???) vai veic ar file_exists. Neveikšanu var izslēgt, ja ir a: vairāk par vienu autoload direktoriju b: vairāki paplašinājumi.

 

Diskusija:

<?php
namespace MicroAva;
$_CONFIG = array(
   'cache' => array(
    'autoload_cache'=> 10 // False or lifetime of cache. 
   )
);
$_CONFIG['autoload']['paths'] = array(
   '/app/controllers/',
   '/app/models/',
   '/app/lib/',
   '/system/lib/'
);
$_CONFIG['autoload']['extensions'] = array('.php');
$microava_autoload = function($class_name) use ($_CONFIG)
{
   $class_file = false;
   $class_name = str_replace(array('\\','_'),DIRECTORY_SEPARATOR,$class_name);
   if($_CONFIG['cache']['autoload_cache'] == true){
    $autoload_cache = \apc_fetch('microava_autoload'.$class_name);
    if($autoload_cache){
	    $class_file = $autoload_cache;
    }
   }
   if($class_file == false){
    foreach($_CONFIG['autoload']['paths'] as $autoload_path){
	    foreach($_CONFIG['autoload']['extensions'] as $extension){
		    $file = realpath(__ROOT.$autoload_path).DIRECTORY_SEPARATOR.$class_name.$extension;
		    if(file_exists($file)){
			    $class_file = $file;
			    if($_CONFIG['cache']['autoload_cache'] == true){
				    \apc_store('microava_autoload'.$class_name,$class_file,$_CONFIG['cache']['autoload_cache']);
			    }
			    break;
		    }
	    }
	    if($class_file){
		    break;
	    }
    }
   }
   if($class_file){
    require($class_file);
   }else{
    throw new Exception('Class not found - '. $class_name);
   }
};
spl_autoload_register($microava_autoload);

 

Ar ieslēgtu cache: 0.00054192543029785

Ar izslēgtu cache: 0.00090503692626953

 

+ ātrums, netiek aiztikts disks, kombinējot ar opkoda kešu aplikācija tiek veiksmīgi noparkota atmiņā.

- ???

Domas?

[marrtins]

Disks tāpat tiek aiztikts pirmajā reizē skanējot tos kokus (neatkarīgi ar kādu tooli). Otreiz skanējot, OS diska cache būs parūpējies par to, lai pie diska vairs neķertos klāt (ja uz diska nekas nav mainījies). Manuprāt ieguvums šādam kešam ir visai niecīgs. Vēl ir vērts patestēt, kā tie apc_* darbojas pie ļoooti liela concurrency.

[F3llony]

Pirmajā reizē protams. file_exists rezultāti arī itkā tiek kešoti, taču vienalga, ieguvums, lai arī niecīgs, taču vienalga ir redzams.

Ko tu domā ar ļoti lielu concurrency? 50-100 req/ps?

[Joyride]

Es ieteiktu uztaisīt komandrindas PHP skriptu, kurš izveido classmap failu. Protams, jāatcerās to palaist katru reizi, kad nāk klāt jauna klase.

 

// classmap.php - ģenerē skripts
return array(
'Mana_Klase' => 'Pilns/ceļš/līdz/libs/Mana/Klase.php',
);

// bootstrap.php
function autoload($class_name)
{
static $cache = null;

if($cache === null)
{
 // Vari arī glabāt APC kešā
	$cache = require 'classmap.php';
}

if(isset($cache[$class_name]))
{
	require $cache[$class_name];
}
else
{
	// Tu met exceptionu, bet es to neiesaku, jo ja nu kādreiz gribēsi tikai noskaidrot, vai klase eksistē ar class_exists()
}
}

 

Vēl ir risinājums apvienot visas ietvara klases vienā lielā failā kā to dara Yii (ja nemaldos).

[F3llony]

Joyride, tik pat labi es varu atmest autoload un likt rakstīt requires vienā failā. :) un visas ietvara klases likt vienā failā... Vienalga, dara to yii vai zend, vai vēl kāds - liekas lielā mērā tizls risinājums. Tā pat, kā index.php kas saturētu visu lapu (lol 2002)

[Joyride]

Kurš ir ātrākais veids, var noskaidrot tikai ar benchmark palīdzību, citādi Tavs viedoklis ir subjektīvs. Uztaisi benchmarku katram gadījumam tieši uz sava konkrētā FW bāzes un salīdzini.

 

Un man tik tiešām nesķiet, ka apvienot visas sava FW klases vienā failā ir kaut kas drausmīgs, jo diez vai Tev tur ir milzu pašrakstītas PDF utml klases (ala tcpdf / ezpdf apmēros). Viens require uz šo failu vienreiz pārstartējot webserveri, Tu taču lieto APC, vai ne?

[F3llony]

Kurš ir ātrākais veids, var noskaidrot tikai ar benchmark palīdzību, citādi Tavs viedoklis ir subjektīvs. Uztaisi benchmarku katram gadījumam tieši uz sava konkrētā FW bāzes un salīdzini.

 

Un man tik tiešām nesķiet, ka apvienot visas sava FW klases vienā failā ir kaut kas drausmīgs, jo diez vai Tev tur ir milzu pašrakstītas PDF utml klases (ala tcpdf / ezpdf apmēros). Viens require uz šo failu vienreiz pārstartējot webserveri, Tu taču lieto APC, vai ne?

Skaties pirmo postu - tur ir crude benchmarks, avg no 1000 pieprasijumiem pie 10 klašu ielādes ar 4 direktorijām un 1 paplašinājumu. Realitātē ir kādi 3 paplašinājumi un 11 direktorijas. Un tavs "diez vai" uz šo brīdi ir kodols no 86299 koda rindām +/- 1k neskaitot vendor bibliotēkas. Un vai es piedāvātos kešot APC ja es to nelietotu? ???

Ja tu raksti lapeles kioskiem, tas nenozīmē ka to dara visi. Šis vairāk bija jautājums tiem, kam hardwares DO ir spēcīgāks par manu, lai tiktu skaidrībā ar ietekmi uz disku. :>

[marrtins]

50-100 req/ps?

Jā, tas būtu labs sākums. Vnk tas APC noteikti taisa lockus pie un vairākiem gribētājiem var nākties pagaidīt rindiņā.

[F3llony]

Okei, vēlāk uzrakstīšu testu.

[Joyride]

Marrtins pareizi saka par lock problēmām, tur nav testēt, nu neder šis variants. Ir jānovērš problēma saknē, jānodrošinās pret keša bombardēšanu. Es Tev piedāvāju divus pārbaudītus un elementārus risinājumus, kuri derēs neatkarīgi no lietotāju skaita, bet Tu kā tāds pārgudrs auns.

 

Piedevām ja ir paredzēti tik daudzi vienlaicīgi pieprasījumi (100/sec), tad jau diez vai PHP tiks laists kā Apache modulis (klasika), drīzāk būs Nginx + PHP fcgi un tad APC vispār neder.

 

[spam enabled=1]

Ieguvums 0.000X sekundes :D Labāk izej cauri DB un pārbaudi indeksus, smagos vaicājumus pārraksti bez JOINiem, tas būs miljons reižu noderīgāk.

 

Skatos, nesen esi sācis apgrābstīt namespaces (Tavs šī gada x0cache projekts tās vēl nelieto), ej cauri kodam un izlabo, kur ir aizmirsies "\" pielikt funkcijām un klasēm, izdomā, ko darīsi ar vendor libiem, kuri tās nelieto - to neesi paredzējis autoloaderī. Un, vispār, namespaces ir sliktas. Tiec vaļā no globālajiem mainīgajiem, uzraksti elementāru Config klasi, nicinātajam Zend ir jauks risinājums. Kāpēc vairāki failu paplašinajumi, PHP ir tikai viens: .php. DI, laikam nav nemaz vērts pieminēt.

 

Starp citu, kiosku lapas veidoju tikai karjeras sākumā, tāpat kā noteikti arī Tu un vairums citi, tagad manā pārziņā ir daudz nopietnāki projekti, kā piemēram šis:

Directories: 583

Files: 3218

Lines of Code (LOC): 1054628

Cyclomatic Complexity / Lines of Code: 0.09

Comment Lines of Code (CLOC): 328815

Non-Comment Lines of Code (NCLOC): 725813

[/spam]

[F3llony]

Aiziet tīģeri. Būtu interesanti uzzināt, kāds sakars CLI ar FPM. Tu taču nedomā izmantot nginx lai spawnotu PHP cgi procesus, ko? Būtu ļoti leimiska kļūda cilvēkam, kura pārziņā projekti, kuri satur >m koda rindu, ne? :>

 

Un tas, ka es kaut ko kaut kur publiski nelietoju, kā tas ir x0cachē, nenozīmē, ka es to nelietoju vispār vai nule kā esmu sācis lietot. Praktiski visa mana source, ko vari atrast kaut kur interwebos ir "kafijas pauzes" "projekti", kuri tiek uzrakstīti, pārbaudīti, ja strādā - reizes 5 refaktorēti lai derētu mērķim un tad izmantoti, kur vajag. Konkrēto projektu rakstīju lai pārbaudītu, cik reāli ir pabāzt maksimums kešu zem viena wrappera un cik daudz funkcionalitātes pārklājas, cik vajag emulēt un cik efektīvi tas ir. Tas pats ar microavu - es gribu atrast visefektīvāko un funkcionālāko front controller pieeju.

 

Pārējos murģeļus par datubāzi un globiem nekomentēšu. Ja tu nesaproti, kāda atšķirība ir starp POC - eksperimentiem un reālu inkorporētu kodu, ej vien turpini pārzināt savu megaprojektu (kuru gan jau uzrakstījis kāds cits).

 

P.S #4 class_exists('dooh',false);

Edited October 1, 2012 by F3llony

[malinens]

Man liekas, ka nav labi hardkodēt apc-store un tml. tev taču ir

 

Microava / app / lib / microava / microcache.php

 

 

Vai tad APC opcode cache neiekešo visus skriptus? Man vispār ir uzlikts agresīvs kešošanas līmenis un serveris pat nepārbauda faila modificēšanas datumu (izmaiņas parādās tikai pēc servera reload) un papildus apc izmantošana jau būtu matu skaldīšana...

Edited October 1, 2012 by malinens

[F3llony]

Hardkodēts tāpēc, ka APC ir lokāls un tiešs atmiņas buferis, microcache piedāvā vai nu APC vai Memcached. Memcached savukārt ir distributēta tīkla atmiņas keša sistēma, kas no APC ātruma ziņā atpaliek, atkarībā no gadījuma un datiem savas 5-10 reizes. Aizstājot APC ar Memcached vai citu analogu ieguvums kļūtu par zaudējumu. Šajā gadījumā izvēle ir tikai starp apc un neko.

 

Šajā gadījumā, mans mērķis ir panākt to, ka faktiski, file_exists pārbaužu rezultāts tiktu buferēts un autoload laikā netiktu meklētas failu atrašanās vietas. Klase tik tiešām tiks paķerta no APC bufera un modifikācijas laiku pārbaudi arī var atslēgt, taču pašu skripta izpildi tas nemaina - faila eksistence vienalga jāpārbauda. No šī atbrivoties varētu tikai ieviešot striktu ielādi bez priekšpārbaudes vai klase vispār eksistē, kas arī tiek darīts daudzos gadījumos. Bet šajā gadījumā es to problēmu tomēr vēlētos atrisināt.

Edited October 1, 2012 by F3llony

[marrtins]

Nu nez, lietoju fastcgi ar APC bez nekādām problēmām ;)

Btw, šāda tipa cache lieti noderētu cluster/distributed FS, kur katra faila pārbaudīte reāli maksā.

[F3llony]

Viņš laikam domāja, ka Nginx spawno PHP kā CGI/CLI procesus un stdout pēc tam servē klientam...

Kā īsti ir ar mākoņiem? Viņiem diski diez ir izolēti uz instanci vai cfs?