Zend API |
Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.
Zend API |
5.06.2007, 16:06:49
Post
#1
|
|
Admin Techniczny Grupa: Administratorzy Postów: 2 071 Pomógł: 93 Dołączył: 5.07.2005 Skąd: Olsztyn |
|
|
|
6.06.2007, 15:07:18
Post
#2
|
|
Grupa: Zarejestrowani Postów: 219 Pomógł: 5 Dołączył: 18.07.2006 Skąd: Piekary Śląskie Ostrzeżenie: (0%) |
Długo trzeba było czekać ale fajnie, że temat ten powstał.
Od jakiegoś czasu ostro biorę pod lupę tuningowanie aplikacji za wszelka cenę - cachowanie wszystkiego co sie da etc. Moja aplikacja ma w tej chwili około 1,5k klas. Za każdym razem gdy wywoływana jest strona część z nich jest ładowana do pamięci - wiąże się to z otwarciem pliku z kodem php, wczytaniem zawartości itd. Za każdym wywołaniem skryptu kod jest wczytywany i po jego zakończeniu wywalany z RAMu. Pomyślałem sobie, że fajnie by było gdyby silnik PHP raz sobie załadował kod do pamięci przy załączaniu serwera i potem już go miał. Taką możliwość daje wkompilowanie do PHP napisanego przez siebie rozszerzenia. Studiowałem nieco Zend API. Przyznam się, że C nie jest moją miłością ale jak mus to mus Problemem jest to, że Zend API nie jest napisane łatwo, odpowiedniki phpowych klas tworzy się przez wywołanie iluś dziwnych funkcji i makr. Porządnej dokumentacji do tego Zend jeszcze nie napisał - są opisane same podstawy jak takie rozszerzenie stworzyć ale bez żadnego wgłębiania się w szczegóły. I tutaj pytanie do Was - profesjonalistów pełną gębą :-) Macie jakieś doświadczenia w pisaniu swoich modułów? Co myślicie o samym przenoszeniu logiki aplikacji do wkompilowywanego rozszerzenia? Wada takiego rozwiązania jest to, że jakakolwiek modyfikacja kodu - rekompilacja php. Oczywiście można używać modułów dynamicznych ale z tego co wyczytałem na stronie Zenda to one również są ładowane i wyładowywane przy każdym wywołaniu skryptu. Zaleta jest to, że kod jest ładowany raz i potem pamiętany i to zapewne w wersji wykonywalnej. Na pewno to przyspiesza jego działanie. Robił ktoś jakieś testy? Inna zaleta jest to, że mamy dostęp do całego dobrodziejstwa C. Podzielcie się opiniami. -------------------- CMS dla Twojej firmy
Wojciech Małota |
|
|
13.06.2007, 23:46:57
Post
#3
|
|
Grupa: Zarejestrowani Postów: 22 Pomógł: 0 Dołączył: 28.10.2004 Ostrzeżenie: (0%) |
Extension dziala duzo duzo szybciej i zjada mniej zasobow poniewaz Nie musi byc za kazdym razem :
1. Ladowane do pamieci dla KAZDEGO pliku PHP 2. Parsowane przez PHP (ktore jest wolne) 3. Nie zezre 60% zasobów systemowych podczas uruchamiania kodu Sa i minusy : 1. Instancje KLAS beda i tak tworzone dynamicznie (no ale o ile szybciej i sprawniej) 2. Zend dorzuci nam do kodu dodatkowe 10 kb swoich smieci 3. Kod bedzie dzialal wolniej niz czysty c++ pisany bez Zend'a 4. Zend i tak bedzie deklarowal wszystko jako ZVAL czyli taki VARIANT ktory jest wszystkim od arraya po string wiec przekazywanie czegokolwiek z PHP do EXTENSION bedzie sie odbywac wlasnie przez ten ZVAL ktory sam nie wie czym dokladnie jest przez co jest powolny i dosc obszerny. Rozszerzenia sa pisane tylko dlatego ze PHP niektorych rzeczy nie potrafi zrobic i nigdy nie bedzie potrafil .... no i wtedy programisci siegaja po c++. Rozszerzenia i tak opieraja sie na silniku Zenda tak jak PHP. PHP np. nie pozwala na platformie Windowsa na dostep do WinAPI i robi wszystko sam. W sumie to bylo kiedys ext. w32api ale zostalo przeniesione do PECL i dziala pod PHP4 za co nalezy sie wielki minus dla PHP. dla przykladu : Głupie fopen(); skacze jakies 30 razy po roznych funkcjach zanim dotrze do CreateFileA (bo i tak musi) i pozniej do Kernela .... nie latwiej bylo by poprostu umozliwic uzycie CreateFileA(); w PHP ? widocznie to jest za proste rozwiazanie Jesli pozbyc by sie z PHP bzdur ktore skutecznie zabieraja cala wydajnosc skryptow to nie potrzebne by bylo pisanie rozszerzen aby przyspieszyc kod. W sumie to na jedno by Ci wyszlo pisanie rozszerzenia czy wlasnej DLL jako modul apache. |
|
|
14.06.2007, 09:54:36
Post
#4
|
|
Grupa: Zarejestrowani Postów: 219 Pomógł: 5 Dołączył: 18.07.2006 Skąd: Piekary Śląskie Ostrzeżenie: (0%) |
W sumie to na jedno by Ci wyszlo pisanie rozszerzenia czy wlasnej DLL jako modul apache. No nie do końca. PHP zawiera jednak trochę przydatnego kodu. Np. łączenie z bazami danych etc. -------------------- CMS dla Twojej firmy
Wojciech Małota |
|
|
14.06.2007, 11:20:46
Post
#5
|
|
Grupa: Przyjaciele php.pl Postów: 2 923 Pomógł: 9 Dołączył: 25.10.2004 Skąd: Rzeszów - studia / Warszawa - praca Ostrzeżenie: (0%) |
@cicik Twoj problem mozna troche inaczej zrealizowac. 1 uruchomienie zbieranie klass do jakiegos wspolnego pliku gdzie includy nie beda do kazdej akcji i plikow uruchamiane. Jesli chodzi o wykonywanie i ponowne requesty to obiekty serializowane i wrzucane do pamieci wpoldzielonej a pliki to to aby miec definicje i moc deserializowac obiekty i dane. Takie podejscie nie jest latwe ale daje efekt.
-------------------- |
|
|
14.06.2007, 12:14:35
Post
#6
|
|
Grupa: Zarejestrowani Postów: 22 Pomógł: 0 Dołączył: 28.10.2004 Ostrzeżenie: (0%) |
Serializacja zachowa tylko zmienne i stale objektu.
Nie zachowa Metod wiec to jest bez sensu tutaj. Moze lepszym rozwiazaniem bylo by napisanie extension pozwalajacego na uzywanie PreCompiled kodu tak jak w C++ sa OBJ. To bylo by bardzo dobre rozwiazanie tworzac takie PPO (php precompiled object ... tak to bede dalej nazywal) Wiazalo by sie to ze spora modyfikacja kodu samego PHP ale wydajnosc by podskoczyla kolosalnie. Sam brak parsowania PHP przy uruchamianiu skryptu to duzo. W sumie wystarczylo by zlapac i zapisac do pliku to co wypluje kompilator po zparsowaniu i kompilacji pliku PHP i pozniej ten parser omijac w przypadku uruchamiania PPO. To bylby taki cache tylko duzo bardziej wydajny. Mozna by nawet wyciagnac sam parser z PHP aby tworzyl PPO z PHP. Mozna by nawet te PPO trzymac w pamieci. PHP po zparsowaniu i kompilacji calego kodu linkuje go na swoj sposob i uruchamia a my omineli bysmy parser i kompilator. Ten post edytował sobieh 14.06.2007, 12:47:42 |
|
|
14.06.2007, 13:06:27
Post
#7
|
|
Grupa: Przyjaciele php.pl Postów: 2 923 Pomógł: 9 Dołączył: 25.10.2004 Skąd: Rzeszów - studia / Warszawa - praca Ostrzeżenie: (0%) |
Cytat Serializacja zachowa tylko zmienne i stale objektu. Nie zachowa Metod wiec to jest bez sensu tutaj. Eeee nie bardzo rozumiem serializujesz obiekt pozniej deserializacja jest na podstawie definicji i obiekt w takiej postaci jaki byl masz do uzytku. Nie bardzi zrozumialem Twoja odpowiedz. -------------------- |
|
|
14.06.2007, 17:28:39
Post
#8
|
|
Grupa: Zarejestrowani Postów: 82 Pomógł: 0 Dołączył: 18.06.2005 Ostrzeżenie: (0%) |
...serializujesz obiekt pozniej deserializacja jest na podstawie definicji i obiekt w takiej postaci jaki byl masz do uzytku... Czyli bez sensu bo tak czy inaczej klasa musi być wczytana i sparsowana. Ten post edytował DjKermit 14.06.2007, 17:29:56 -------------------- emiker
|
|
|
14.06.2007, 20:13:42
Post
#9
|
|
Grupa: Zarejestrowani Postów: 634 Pomógł: 14 Dołączył: 27.05.2006 Skąd: Berlin Ostrzeżenie: (0%) |
Boże, DjKermit, czy ty naprawdę nie wiesz co robi serializacja? czy testujesz nasze reakcje / osobowości ?!
|
|
|
14.06.2007, 20:50:24
Post
#10
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
Boże, DjKermit, czy ty naprawdę nie wiesz co robi serializacja? czy testujesz nasze reakcje / osobowości ?! Mówimy o serializacji w PHP oczywiści? -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
14.06.2007, 20:50:49
Post
#11
|
|
Grupa: Zarejestrowani Postów: 22 Pomógł: 0 Dołączył: 28.10.2004 Ostrzeżenie: (0%) |
Cytat Boże, DjKermit, czy ty naprawdę nie wiesz co robi serializacja? czy testujesz nasze reakcje / osobowości ?! On po prostu powiedział że Serializacja się nie nadaje. DeSerializacja obiektu zadziała jeszcze wolniej niż utworzenie go ponieważ PHP będzie musiał zparsować definicję obiektu ORAZ zserializowane dane po czym stworzyć tymczasowy obiekt i uaktualnić nasz obiekt tymi danymi z obiektu tymczasowego. Jeśli uważasz inaczej to podaj przykład gdzie PHP nie będzie musiał parsować całej definicji obiektu i tworzyć tymczasowych obiektów na deserializację. Poza tym tutaj nie chodzi o same Klasy ale o cały kod projektu. Może to wytłumaczę dokładniej : PHP przy każdym uruchomieniu jakiegokolwiek skryptu musi cały kod parsować od zera. To tak jak byście wciskali BUILD w C++ za każdym razem jak uruchamiacie swój w pełni działający i gotowy program. Troche bez sensu prawda ? Celem tego tematu jest stworzenie rozszerzenia php / zmodyfikowanie php w taki sposób aby skrypt zawarty w pliku PHP był parsowany , kompilowany i zapisywany jako skompilowana wersja w innym pliku np. PPO lub pamięci. (tak jak C++ generuje pliki OBJ z plików CPP ) Po co to ? Po to aby PHP nie musiał za każdym razem parsować i kompilować skryptów które tego nie wymagają. Co to da ? Da to kolosalną różnicę wydajności której brakuje w dużych projektach. Przykład : Mamy sobie klasę np. Driver MySql'a który jest gotowy i nie będą w nim wprowadzane żadne zmiany. Po co PHP ma za każdym razem kompilować ten Driver skoro się on nie zmienia ? Jest to przykład straty wydajności na zbędną kompilację. Jeśli PHP stworzył by plik PPO i poprostu go uruchomił nie kompilując go to nie stracił by czasu na kompilację zbędnego kodu. Ten post edytował sobieh 14.06.2007, 20:53:56 |
|
|
14.06.2007, 22:46:33
Post
#12
|
|
Grupa: Przyjaciele php.pl Postów: 2 923 Pomógł: 9 Dołączył: 25.10.2004 Skąd: Rzeszów - studia / Warszawa - praca Ostrzeżenie: (0%) |
@sobieh Z wiekszoscia Twoich zdan sie zgadzam ale nie zapominaj ze taka jest specyfika jezykow skryptowych tutaj kod moze byc generowany dynamicznie. Trudno bedzie zachowac taki schemat jak jest powiedzmy w C. Program wynikowy ktory jest tylko uruchamiany choc w wiekszosci przypadkow pewnie tak bedzie.
Odnosine tego co pisales masz jakies testy jak taka metoda wypada (serializacja obiektow) przy klasycznym wykorzystaniu 1 plik 1 klassa? -------------------- |
|
|
15.06.2007, 09:26:11
Post
#13
|
|
Grupa: Moderatorzy Postów: 4 465 Pomógł: 137 Dołączył: 26.03.2004 Skąd: Gorzów Wlkp. |
Nie będę się wtrącał, tylko wyprostuję pewną nieścisłośc dotyczącą serializacji.
Otóż ~sobieh mówi, że Cytat On po prostu powiedział że Serializacja się nie nadaje. DeSerializacja obiektu zadziała jeszcze wolniej niż utworzenie go ponieważ PHP będzie musiał zparsować definicję obiektu ORAZ zserializowane dane po czym stworzyć tymczasowy obiekt i uaktualnić nasz obiekt tymi danymi z obiektu tymczasowego. Jeśli uważasz inaczej to podaj przykład gdzie PHP nie będzie musiał parsować całej definicji obiektu i tworzyć tymczasowych obiektów na deserializację. Parsować musi zawsze, ale jeśli nasz obiekt zawiera dużo danych, które są wynikami pracy innych obektów - często bardzo czasochłonnymi, to cache przez serializację jest jak najbardziej wydajny, bo nie trzeba mielić dziesięciu innych obiektów. Pozdrawiam. -------------------- To think for yourself you must question authority and
learn how to put yourself in a state of vulnerable, open-mindedness; chaotic, confused, vulnerability, to inform yourself. Think for yourself. Question authority. |
|
|
15.06.2007, 09:54:18
Post
#14
|
|
Grupa: Przyjaciele php.pl Postów: 698 Pomógł: 3 Dołączył: 28.03.2004 Skąd: Wrocław Ostrzeżenie: (0%) |
Istnieją programy cache, które trzymają bytecode w pamięci. Poza tym w manualu jest coś takiego: PHP bytecode compiler. Nie chodziło wam o to?
-------------------- |
|
|
15.06.2007, 21:35:51
Post
#15
|
|
Grupa: Zarejestrowani Postów: 219 Pomógł: 5 Dołączył: 18.07.2006 Skąd: Piekary Śląskie Ostrzeżenie: (0%) |
W sumie wystarczylo by zlapac i zapisac do pliku to co wypluje kompilator po zparsowaniu i kompilacji pliku PHP i pozniej ten parser omijac w przypadku uruchamiania PPO. Też o czymś takim myślałem, to by było najlepsze. Trzeba by się pobawić w coś polegającego na wyczajeniu jak PHP z kodu PHP robi wykonywalne binarki. Przyznam się, że troche odstrasza mnie to, że PHP jest napisane w C. Wolałbym C++. Cytat Poza tym w manualu jest coś takiego: PHP bytecode compiler. Nie chodziło wam o to? a na górze czerwony pogrubiony napis "This extension is EXPERIMENTAL." Cytat Twoj problem mozna troche inaczej zrealizowac. 1 uruchomienie zbieranie klass do jakiegos wspolnego pliku gdzie includy nie beda do kazdej akcji i plikow uruchamiane. Nie chodzi o wyeliminowanie includów tylko procesu interpretacji kodu. EDIT: Ta funkcja: http://pl.php.net/manual/en/function.bcomp...-write-file.php wygląda całkiem obiecująco, a zwłaszcza przykład. Może w najbliższym czasie zrobię jakieś testy czy to działa. EDIT: Pierwsze wyniki. Nie może być za łatwo. Funkcja bcompiler_write_file zwraca fatal error, jeżeli plik, który chcemy skompilować zawiera definicje funkcji/klas już wczytanych przez normalne wykonanie skryptu. Nie wiem czemu ale widocznie bcompiler_write_file chce normalnie "zaincludować" konwertowany plik. EDIT: Lipa niestety. Plik skompilowany i oryginalny nie wykonują się tak samo. Mam klasę SQL_sql. Ona zawiera pole protected i metode public, która z niego korzysta. Mam klasę SQL_mysqli, która dziedziczy po SQL_sql. Wywołuję jej metodę odziedziczoną po klasie rodzicu i otrzymuję: Fatal error: Cannot access protected property SQL_mysqli::$tabele_query in F:\strony\php-art\klasy\sql\silniki\sql.php on line 170 EDIT: Dziś rano zacząłem testować rozszerzenie APC. Rozszerzenie to w pamięci RAM cachuje bytecode skompilowanego skryptu. Zapowiada się dość obiecująco. Skrypt przyspieszył około trzech razy. EDIT: Niestety pierwsze badania APC były chyba dziełem przypadku po dłuższych obserwacjach nie da się zauważyć jakiegoś przyspieszenia skryptów. Może gdyby serwer był bardziej obciążony... Ktoś testował? Ten post edytował cicik 16.06.2007, 09:54:33 -------------------- CMS dla Twojej firmy
Wojciech Małota |
|
|
16.06.2007, 14:34:55
Post
#16
|
|
Grupa: Przyjaciele php.pl Postów: 698 Pomógł: 3 Dołączył: 28.03.2004 Skąd: Wrocław Ostrzeżenie: (0%) |
APC czy rozwiązania podobne (ionCube PHP Acceleratior, Zend Optimizer) są powszechnie stosowane przez providerów. Ja zauważyłem kilkukrotne przyspieszenie u siebie, jak włączyłem kiedyś z ciekawości.
-------------------- |
|
|
16.06.2007, 15:03:00
Post
#17
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
Lipa niestety. Plik skompilowany i oryginalny nie wykonują się tak samo. Mam klasę SQL_sql. Ona zawiera pole protected i metode public, która z niego korzysta. Mam klasę SQL_mysqli, która dziedziczy po SQL_sql. Wywołuję jej metodę odziedziczoną po klasie rodzicu i otrzymuję: Fatal error: Cannot access protected property SQL_mysqli::$tabele_query in F:\strony\php-art\klasy\sql\silniki\sql.php on line 170 A może to coś pomoże: Cytat // you must write DB_common before DB_mysql, as DB_mysql extends DB_common. Przy bcompiler-write-class" title="Zobacz w manualu PHP" target="_manual -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
16.06.2007, 17:04:18
Post
#18
|
|
Grupa: Zarejestrowani Postów: 219 Pomógł: 5 Dołączył: 18.07.2006 Skąd: Piekary Śląskie Ostrzeżenie: (0%) |
Ale ja używam bcompiler_write_file. I powinno działać. Ktoś już wcześniej zgłosił ten bug na PECLu. APC czy rozwiązania podobne (ionCube PHP Acceleratior, Zend Optimizer) są powszechnie stosowane przez providerów. Ja zauważyłem kilkukrotne przyspieszenie u siebie, jak włączyłem kiedyś z ciekawości. Ja jakoś nie zaobserwowałem, skonfigurowałem APC, ściągnąłem APC GUI, pokazuje, że kod jest schachowany. Ale pomiary wykonane przy użyciu APD nie wykazują zbytnich różnic. APC GUI pokazuje, że odwołanie zostało przechwycone przez APC. EDIT: Przyznaję się do błędu. Miałem błąd w php.ini i dlatego APC nie działało. Jednak dziwi mnie jedna rzecz... dlaczego mimo schachowanego kodu wywołuje mi się funkcja __autoload ? Skoro kod jest w pamięci to nie powinna sie wywoływać. EDIT: Ok. Wreszcie wyczaiłem jak to działa. To nie jest tak, że jak sie po raz pierwszy includuje plik z klasą to apc zapamiętuje definicję klasy tylko on zapamiętuje cały plik i przy drugim includzie zamiast ściągać go z dysku to jest zwracany z ramu już w postaci bytecode. Trochę to bez sensu bo musze wywoływać includy ciągle (i dlatego też się __autoload wywołuje). Ciągle tylko nie obserwuję wzrostu wydajności. Ten post edytował cicik 16.06.2007, 18:14:12 -------------------- CMS dla Twojej firmy
Wojciech Małota |
|
|
Wersja Lo-Fi | Aktualny czas: 26.09.2024 - 11:45 |