zrobilem pelne dostosowanie do php fusion + zabespieczenia plikow cache; zmienilem tez funkcje generujaca nazwe pliku z sf_qhsx($ax) na szybsza md5($ax) i domyslnie wylaczylem refresh na okreslony czas
oto kod dla maincore (przed dodaniem tego kodu trzeba zrobic podmianke funkcji dbquery opisane w moim poprzednim poscie)
i kod dla footer.php

Pozdro!!

czas wykonywania kodu PHP, szczególnie w przypadku PHP-Fusion jest niewspółmiernie mniejszy od czasu wykonywania zapytań. Tak więc lepiej by było gdybyście przerobili funkcje wykonującą zapytania tak by keszowała zapytania na czas nieokreślony. kesze dla danej tabeli usuwane byłyby w przypadku wykonania innego niże SELECT zapytania dla tej tabeli. Proste i nie ma efektu starego cache

No niestety tutaj się przejedziesz...

Robiłem DOKŁADNY JavaScriptowy Benchmark (wywoływanie strony co sekundę) funkcji Haszujących MD5, SHA-1 oraz mojej własnej sf_qhsx.

I zgadnij co ? sf_qhsx jest w praniu o 40 % szybsza od MD5 i chyba o 50% szybsza od SHA-1. A to dlatego że MD5 i SHA1 używają skomplikowanych obliczeń, a moja funkcja tylko dodawania i odejmowania, co jest dużo szybsze. (To mój własny patent)

Mam gdzieś jeszcze ten plik XLS, w którym miałem podane czasy wykonywania się funkcji...


-----------------------------------------------------
Slawekneo: zauważam że trochę za bardzo rozpędzasz się z modyfikacjami i nie zauważyłeś, że zacząłeś poważnie zwalniać kod.

Modyfikacja którą wcześniej zaproponowałeś (aktualizacja cache przy aktualizacji bazy) jest dobra, ale spowoduje spowolnienie WSZYSTKICH wywołań do strony jednocześnie, co w godzinach szczytu może spowodować nawet ZWIS serwera, bo wszystkie strony będą nagle ładowane od zera jednocześnie (w wypadku jeżeli serwer jest na już na skraju przeciążenia i tylko Hypercacher trzyma go przy życiu).

Natomiast mój sposób na odświeżanie cache (cachewalker) powoduje odświeżanie cache wszystkich stron, ale tylko przeglądanych przez jednego użytkownika.

Widzisz: ja projektując Hypercachera myślałem o NAPRAWDĘ obciążonych stronach typu pl.wikipedia.org lub www.onet.pl, a nie tylko o małych stronkach dla pasjonatów.

SoofMan - ja jednak wole sprawdzone funkcje

Riklaunim - ta mowi to sie latwo, ale zrobic juz ciezko bo przeciez jedno zapytanie bedzie musilo miec minimum 4 cache (dla sadma, adma, usera i goscia) a i dodatkowe dla kazdej grupy userow ale zobaczymy moze mi sie uda cos przez nastepny tydzien wymodzic

Niestety. Sprawdzone, ale dużo wolniejsze. Moja funkcja działa już od 5 miesięcy. Dziesiątki milionów wywołań. Ile jeszcze można sprawdzać ??



Hmmmm.... to chyba przewiduję dopiero w następnym produkcie - PHP Hyper Query Cacher. Oczywiście też musi być banalny w instalacji oraz prosty w konstrukcji. Ale narazie tylko w planach.

---------------------------------------------



BTW.

Znalazłem ten plik z wynikami JavaScriptowych benchmarków poszczególnych algorytmów.



Jakby ktoś pytał, to są czasy uruchamiania się całej strony a nie tylko funkcji haszującej. Więc efektywnie strony które będą używać MD5, mogą ładować się dokładnie 61% wolniej o SF-HASH, a SHA1 o 43% wolniej od SF-HASH (wyczytane ze śrenich czasów).

Więc jak widać, funkcja SHA1 jest strasznie wolna, a MD5 to już w ogóle ślimak.

w RkCMF1 miałem coś takiego - obejmowało wszystkie tabele poza tablą userów/uprwanień


Zrozum że na takich stronach nie używa się tego typu "ogólnych" rozwiązań. Serwery wikipedii są replikowane na wiele maszyn - zarówno bazy danych jak i serwery http. Do tego dochodzą load-balancery i wspomniany memcached (przerobiony przez projekt mediawiki) inteligenty system cache zdolny do działania na wielu serwerach. Twoje rozwiązanie jest dla wikipedii się nie nadaje, gdyż kesz nie może być do tyłu w stosunku do oryginału. Zapis zmian odświeża kesz w memcached, który obowiązuje przeważnie do kolejnej edycji.

Podobnie na onecie, slashdot i każdym innym dużym serwisie - tam nie stosuje się ogólnych półśrodków - niedokładnych rozwiązań.

A jak chcesz opinii licznej rzeszy programistów PHP napisz na http://forum.php.pl/

ehh drogi SoofMan'ie wcale sie nierospedzilem tylko dodalem co koniecznie aby nie bylo (jak to Riki okresli) efktu starego cache.
jezlei chcesz aby ludzie instalowali cachera na tego typu cms'ach to musi on spelnia warunek po odswiezeniu w cache maja byc zawsze swierze dane inaczej nikt Ci tego nie zainstaluje
bo gdyby na supporcie byl Twoj cacher to rozmowa w shoutboxie byla by praktycznie niemozliwa z powodu starego cache

----------------------------------
po oblookaniu wynikow moge przyznac ze Twoja funkcja generujaca jest szybsza i napewno powruce do niej

Dlaczego cache nie może być nawet 1 minutę do tyłu za oryginałem ?? Nie rozumiem tego. Poza tym ten cache będzie do tyłu tylko dla niezalogowanych użytkowników. Po zalogowaniu, lub wysłaniu jakiegokolwiek formularza cache się odświeży...




To już w ogóle musiałbym cały dzień siedzieć i odpowiadać co 5 minut na posty... masakra. Chyba podziękuję.




Błąd. Po wysłaniu formularza cache odświeży się automatycznie na WSZYTSKICH stronach, ale tylko dla użytkownika który ten formularz wysłał.
Pozostali zobaczą odświeżoną stronę po upływie czasu cache refresh


-----------------------------------
W ostateczności można tak jak ty zrobić moda, który odświeży automatycznie wszystko po wysłaniu czegoś do shoutboxa, ale nie jest to tak jak mówiłem ładne ani szybkie rozwiązanie...





-----------------------------------------------

Wiecie co ?
Zasadniczo to macie rację. Zmobilizowało mnie to do działania i wpadła mi do głowy koncepcja "przyśpieszanego odświeżania" w przypadku jeżeli ktoś wysyła formularz lub zmienia content... Muszę tylko to dokładnie przemyśleć zanim to zaimplementuję... Mogę powiedzieć, że na pewno będzie dużo szybsze i dużo ładniejsze niż koncepcja odświeżania cache przy modyfikacji bazy.

W jakiejś następnej wersji coś takiego zrobię... Tylko kiedy ? Za tydzień lub dwa.

czy az tak wolniejszy moj dodatek jest to niebyl bym tego taki pewien bo tylko jest dodane wczytanie (w celu sprawdzenia czy niewykonano jakiegos wsadu z insert into) jednego pliku ktory bagatela zajmuje 10 bitow i tyle reszta dodana to standardowe zabespieczenia dla plikow cache ktore musza byc! no chyba ze wymyslisz jakies super rozwiazanie to czekam
Pozdro!!

Tak... dlaczego autorzy genialnych projektów nie chcą pochwalić się swoim dziełem na forum odwiedzanym przez profesjonalnych programistów Chcesz mieć "jakość" swojego produktu to go tam przedstaw Jeżeli dostaniesz tam pozytywną ocenę to oznacza iż na nią zasługujesz.

OK, zgłoszę się tam. Ale na pewno nie dzisiaj. Wiadomo - programiści nie śpią po nocach...

Jak znajdę wolną chwilę to na pewno skorzystam.

Tak w ogóle to nawet nie wiedziałem że jest takie forum LOL...

Od ciebie dowiaduję się po raz pierwszy. Ale jak zobaczyłem te setki tysięcy postów to trochę się przeraziłem, że będę musiał siedzieć cały dzień i odpowiadać.



Noooooo... odczytanie pliku to zdecydowanie zbyt wolne rozwiązanie. Ja używam zwykle do takich celów odczytania czasu modyfikacji pliku lub odczytania nazw plików z listowanego katalogu... chyba jest szybsze, chociaż muszę zrobić JavaScriptowego benchmarka żeby to sprawdzić na 100 %.


------------------------------------------
UPDATE:

1. Nie trwało to tydzień czy dwa, i zrobiłem już modyfikację PHP Hypercachera pod nazwą Refresher. Tutaj content jest odświeżany automatycznie, w zależności od czasu ostatniej modyfikacji odpowiedniego pliku. Fragment kodu z nagłówka PHP Hypercachera wygląda tak:



Modyfikację oznaczyłem jako osobną gałąź rozwoju (osobny changelog, osobne źródła, dodatkowa dokumentacja itd.) i nazwałem PHP Hypercacher Refresher Standard / PHP Hypercacher Refresher GZIP. Jest dostępna na stronie do ściągnięcia tam gdzie zawsze.

Dodałem dwa nowe changelogi, i dopisałem w changelogach zasługi Slawekneo - to znaczy podsunięcie mi pomysłu na dodanie takiej funkcjonalności.
http://hypercacher.com/changelog_refresher_standard.txt
http://hypercacher.com/changelog_refresher_gzip.txt

Gdyby ktoś chciał dodać sobie aktualizację cache do kwerend zamiast do wysyłania formularzy, to wystarczy zamienić powyższy kod na :



oraz dodać polecenie



do miejsca w którym kwerenda się wykonuje (tak jak Slawekneo zaproponował)



--------------------------------

2. Wrzuciłem też posta na forum PHP.pl i potraktowali go jako spam i wykasowali, a do tego zbanowali mi konto...

Cóż, spodziewałem się że chociaż trochę po mnie pojeżdżą - że kod badziewny, że wolno działa, że nie binarne, że to, że tamto, a tutaj takie zaskoczenie...

Niektórzy to mają problemy - dawać za kasę - ŹLE, dawać za darmo (i do tego na GPLu) to też źle. Normalnie co za ludzie.

2. z automatu czy ktoś się tym zajął ?

Az sie zarejestrowalem gdy to przeczytalem
Walnales chlopie topic jako reklame, a tam na forum reklama jest niedozwolona. Czego oczekiwales? Ze dla ciebie jednego wyjatek zrobia?

Z tego co wiem, to nie zbanowali, a zalozyli blokade postowania. Lekka roznica.... na PW mogles dochodzic swego, ale nie, Pan nieobyty drugie konto zalozyl.... tez to jest zabronione wiec tylko czekac na kolejnego "bana"

lol
a te bulenie kasy pod spodem to tez za darmo?

sorki za OT ale jak przeczytalem te "lament" i "placz" poszkodowanego to nie moglem sie powstrzymac

A to co tutaj zostało zaprezentowane to niby co to jest? REKLAMA i tylko tyle. Nic nie wart sposób

i jakby nie bylo przeprowadzilem swoje testy na czas wykonania funkcji md5() i twojej sf_qhsx() (napisalem specjalna klase w php do tego) i wynik bardzo sie roznil od Twojego

i dodaje ze funkcja sf_qhsx() przy testach miala ustawione generowanie znakow na 24 gdy ustawilem ja na 32 (taka ilosc znakow generuje mi md5) to czas wykonania zwieksza sie o 1/3 a i jeszcze zapomnialem dodac ze czas wykonywania funkcji sf_qhsx($ax) rowniez zwieksza sie z coraz to wieksza iloscia znakow w zmiennej $ax a w md5($ax) czas pozostaje bez zmian

co do sha1($ax) to wykonuje sie ona srednio w 0.000200987 sekund wiec wyglada na to ze kolejnosc czasow generowania wyglada tak
1) md5()
2) sha1()
3) sf_qhsx()
Pozdro!!

yyy, a co ma js do php? Jak ty mozesz mierzyc efekt działania funkcji php kodem js? Prosze o wyjasnienie, a najlepiej kod tego benchmarka bo normalnie albo będe pelen podziwu Twojej genialnosci albo będe pełen podziwu czegos innego

edit: a juz znalazlem odpowiedź na moje pytanie:

LOL LOL LOL
Ty tu mierzysz czas wgrania sie strony z serwera? Nie no chlopie, faktycznie zrobiles benchmark porownania md5() ze swoja funkcją.... LOL LOL LOL

edit: pozatym wiadomo, ze md5 jest szybsze od sha1 (co nawet pokazaly testy slawka powyzej) a wedlug twojego testu jest na odwrót.... hmmm, bardzo (nie)wiarygodny ten benchmark

jak ktoś chce robić dokładne i wiarygodne testy wydajności kodu PHP to polecam Xdebug - pomiar szybkości i zużycia RAMu

1. OK OK odpalę skrypcik z javascriptowym benchmarkiem i zapodam gdzieś na sieci, bo inaczej to się nie przekonacie.

2. Jak działa ten javascriptowy benchmark ? Proste. Na końcu strony jest JAVASCRIPT który odpala stronę co sekundę - dokładnie w momencie jak skończy się ładować, to ją odświeża. I z użyciem takiego właśnie benchmarku wyszły mi te czasy.

Każdy czas wykonania zapisuje się przy tym za pomocą funkcji microtime() i fwrite() do pliku tekstowego.

Nie zrozumcie mnie źle - po tylko kilkukrotnym wywołaniu funkcje SHA1 i MD5 też wydawały się szybsze, ale kiedy zrobiłem 50-krotne wywołanie co sekundę, to czasy wychodziły takie jakie widać.

2a. Zauważyłem ponadto bardzo dziwną sprawę. Kiedy wykonasz funkcję MD5, SHA1 i SF-HASH tylko RAZ podczas pojedynczego wykonania skryptu, to wyniki wychodzą takie jak na moim obrazku. Natomiast, jeżeli zrobisz skomplikowany skrypt i wykonasz każdą z funkcji po 50-100 razy, to SF_HASH zostaje daleko w tyle. Może to tylko specyfika samego kompilatora PHP - no nie wiem.


3. Funkcja SF_HASH jest KONCEPCYJNIE nieporównywalnie szybsza niż jakikolwiek MD5 i SHA1, bo używa tylko dodawania i odejmowania. Ale PROBLEMEM z nią jest to, że nie jest BINARNIE skompilowana jako rozszerzenie PHP. Gdyby tak było, to byłaby 10-razy szybsza (a nie tylko o kilkadziesiąt %) od MD5 czy SHA1, które uzywają skomplikowanych obliczeń takich jak potęgi, mnożenie itp.

Gdybym napisał funkcję MD5, SHA1 i SF_HASH w takim C++, Visual Basicu czy czymkolwiek i skompilował do binarki, to nie byłoby nawet porównania w szybkości...





Nie z serwera, tylko z LOCALHOSTA. I nie czas wgrania, tylko różnica czasów wynikowych z funkcji microtime() z początku i końca skryptu.



---------------------------------------
Skrypt porównujący SF-HASH, MD5 i SHA1 wkrótce


----------------------------------------------
Jeżeli MD5 lub SHA1 okaże się szybsze, to od następnej wersji Hypercachera użyję jednego z tych hashów


---------------------------------------


Ale o co chodzi ?? Przecież BARDZO DUŻO (większość) jest za darmo !

A wersja GZIP nie jest nikomu potrzebna, jeżeli nie chce oszczędzać kasy na transferze ! (no już nie mówiąc że można sobie samemu dorzucić funkcję gzcompress() i mieć własną wersję GZIP). Co prawda nie będzie aż tak szybka jak mój algorytm, ale zawsze to coś.

Na prawdę nie rozumiem niektórych ludzi. Chyba nie wiecie na czym polega GPL ! A GPL polega na tym, że możesz udostępniać za darmo, ale możesz też sprzedawać dodatkowe USŁUGI za kasę ! I ja to robię - sprzedaję usługi. A całość jest i tak WOLNYM oprogramowaniem.

wyniki z benchmarka napisanego w php

Pozdro!!

100% racji. Zrobiłem własny nowy benchmark, który daje podobne wyniki jak te powyżej.

http://hypercache...m/hshtest/

- Wychodzi, że MD5 jest około 4-krotnie szybszy od SF-HASH.
- SHA1 jest około 2 razy szybsze od SF-HASH (zależnie od długości ciągu)

Ale szybkość SF_HASH zależy znacząco od długości ciągu. Im dłuższy, tym SF-HASH jest wolniejsze

Oraz skrypty benchmarku do pobrania

http://hypercache...ex.php.txt
http://hypercache...ts.php.txt


-----------------------------------------
Nie wiem jak mi te wyniki wyszły poprzednio. Używałem prawie identycznego skryptu do testowania hashów wcześniej, i wyniki wyszły takie jak wyszły.

Widocznie mój komp był obciążony, za dużo aplikacji uruchomionych czy coś - i dlatego MD5 i SHA1 wykonywały się wolniej...

Od następnych wersji PHP Hypercachera używam zatem MD5

-------------------------------------------
Może kiedyś napiszę wersję binarną SF-HASH i wtedy zobaczycie prawdziwą prędkość tego algorytmu.