jeju, dzieci, jak chcecie coś naprawdę testować to użyjcie Xdebug i porównajcie logi jego profilera - zobaczycie co i ile się wykonuje i ile RAMu zajmuje

tak mnie pięknie przekonujesz że przetestuję to na starym hostingu znajomego (właśnie wykopali go z NetArt, za zbyt duże obciążenie serwera)...


Faktycznie przyspiesza wczytywanie stron. I tylko tyle dobrego mogę powiedzieć. Mój znajomy wchodząc na tą stronę widzi ją jak ja - zalogowany jako Gander. Chociaż nie jest fizycznie zalogowany to może obejrzeć wszystkie strony, na których byłem podczas działania tego skryptu. Dzięki temu że panel administracyjny ma własny subheader.php, kolega nie mógł obejrzeć zakładek administracyjnych.

Odradzam instalowanie tego na PHP-Fusion! Nawet jeśli zabezpieczyło by się przed tego typu wpadkami - po zmodyfikowaniu strony nadal wczytywana jest stara wersja.

Hmmm. Niech zgadnę.

1. Używałeś starej i wadliwej wersji Hypercachera

LUB

2. Nieumiejętnie grzebałeś w kodzie i wyciąłeś z niego fragmenty odpowiadające za rozróżnianie stron...

LUB

3. Jest coś nie tak z tą stroną...

Zainstaluj nową wersję lub/i nie grzeb w kodzie, jeżeli nie wiesz jak to zrobić... Te problemy o których piszesz są mi znane - rozwiązałem je już dawno temu.

Btw. jeżeli chcesz rozwiązać ten problem, możesz też podać mi adres tej strony - sprawdzę i dojdę od razu co jest nie tak ze stroną lub Hypercacherem.

Btw2.
Skoro jest tak jak mówisz, to czemu nie zgłosiłeś problemu na moim forum ? Mam przecież specjalną sekcję na zgłaszanie błędów...
http://hypercache...um.php?f=4




I co z tego ? Przecież można sobie ustawić czas odświeżania kilka minut. Nikt nie potrzebuje tak naprawdę natychmiastowego odświeżania.... a jeżeli potrzebuje, bo jest jeszcze PHP Hypercacher Refresher, który odświeża wszystkie strony natychmiastowo po dokonaniu zmian.

Dopiero teraz zauwazylem ten topic, i mam pare pytan:

1. "< Nagłówek PHP-Hypercachera (HEADER) >"... jaki on wogole jest? bo w dwoch plikach pisze ze mam go wstawic (txt & odt) ale nigdzie nie znalazlem co to ma konkretnie byc.... a to z kolei uniemozliwia instalacje. Moze zle szukam ale sadze ze powinno sie to rzucac w oczy. Czy chodzi o zaincludowanie "php_hypercacher_standard_v1.949.php" ? chyba nie bo co w takim razie oznaczal by FOOTER z cachera.

2. Cache walker time - niby pisze co to jest ale prawde mowiac dalej nie wiem co ten czas daje... po prostu maslo maslane. Mozna o konkret prosic. Przeanalizowal bym kod ale jest tak super czytelnie w jednej linijce umieszczony ze szkoda slow.

3. Cookie unlock time - to wogole nie jest opisane.

A tak co do posta kolegi wyzej, to wydaje mi sie ze on ma racje. Czy twoj cacher uwzglednia dane wysylane po przez POST? dane ktore skrypt moze pobrac z cookies? jesli rozruznia strony tylko po GET (czyli po adresie) to moze sie walnac bardzo latwo. Bo adres bedzie ten sam a jednak zawartosc inna dla roznych userow. Tutaj wlasnie wspomniane zalogowanie usera - dane z cookies sa pobierane.

Żadnego includowania właśnie. W pliku php_hypercacher_standard_v1.949.php masz dwa fragmenty kodu, które trzeba skopiować wkleić w dwóch różnych miejscach. Są one opisane komentarzami "HEADER" (nagłówek) i "FOOTER" - stopka.

W dokumentacji ODF/PDF masz też pokazany przykład jak to się robi. Widać nie pofatygowałeś się żeby sprawdzić o co chodzi.



Wszystko jest opisane jak należy. Żeby ściągnąć OPISANĄ wersję z listy pobierania na stronie http://hypercache... wybierz DEVELOPERS PACK (na samym dole)



Jak wyżej - spójrz do wersji Developerskiej - tam masz pełny, ładnie opisany kod.

Ogólnie funkcjonowanie tych zmiennych jest dość złożone... nie trzeba wszystkich ich rozumieć żeby dobrze skonfigurować Hypercachera.



Mój cacher uwzględnia dane z POST, GET, FILES, COOKIE a także ściezkę do pliku _FILE_, zmienną serverową PHP_SELF, oraz url do strony (zmienna REQUEST_URI). Wszystko co może się zmienić na różnych stronach zostało uwzględnione.

Blee... co to za roznica? na pewno nie w predkosci. Wg mnie z include jest pewien porzadek i lad, a nie wklejanie kodu jednego autora w drugi. Potem tylko problem przy aktualizacji jest bo zmaiast podmienic zew. plik trzeba znow grzebac w kodzie.


Prezentujesz pewien produkt, nawet bierzesz za to pieniadze, wiec w twoim interesie lezy by uzytkownik nie mial z nim problemu.

Ja piszac aplikacje (pod win32) dbam o to by byla max. intuicyjna i wygodna dla uzytkownika, mimo ze wszystko rozprowadzam jako freeware. O ile tylko w przypadku programu mamy caly interface do komunikacji z userem to przy php trzeba to nadrobic dobra dokumentacją.


No i znow to samo... ja mowie ze nie przemawia do mnie ten opis proszac o wyjasnienie a tu cos takiego. W takim razie podziekuje.


To jak wyjasnisz przypadek kolegi wyzej?

Druga sprawa, trzymajac dane w _cache jest pewne ryzyko ich odczytania przez osoby niepowolane i dostep do tresci ktore nie powinny wyplynac - to jest pewne zagrozenie wg. mnie. Wystarczy wklepac odpowiedni adres i mozemy sie dostac do stron jakie widzial niedawno zalogowany admin.

Jeśli najnowsza wersja z twojej strony jest stara i wadliwa to jaka nie jest?



Wszystko instalowałem wg instrukcji, nic nie zmieniałem



Strona jest ok. Co nam pozostaje?



Pewnie tak - pisałem o tym miesiąc przed twoją odpowiedzią



Dla bezpieczeństwa skasowałem ten skrypt. Zresztą strona chyba już została usunięta z serwera a na nowej nie będę robił takich eksperymentów.



Przetestowałem i opisałem problem tu, gdzie o tym rozmawiamy

Skoro podchodzisz do sprawy w ten sposób to nie mogę ci pomóc.

Napisałem ten program i potrafię szybko i bezproblemowo dojść o co chodzi jeżeli coś nie działa na danej stronie.

Jeżeli nie podasz mi PRZYKŁADU, to nie ma:

1. Żadnego dowodu że to co mówisz jest prawdą
2. Żadnego sposobu na usunięcie przeze mnie błędu (jeżeli faktycznie istnieje)

Więc może albo podaj DZIAŁAJĄCY PRZYKŁAD, albo przestań siać zamęt, bo z twoich wypowiedzi kompletnie nic nie wynika.



Dla mnie to ogromna różnica.

Jeżeli masz jeden plik, to głowica dysku musi odczytać tylko jeden sektor. Przy wykorzystaniu dwóch plików, głowica musi dwa razy skoczyć w dwa miejsca żeby odczytać dwa pliki PHP. Więc żebyś nie wiem co robił, to JEDEN odczyt będzie zawsze szybszy niż DWA odczyty.

Hypercacher ma być super-maksymalnie szybki tak jak sie tylko da... Szczegóły schodzą na drugi plan.



Może z include jest większy porządek. Ale szybkość na pewno jest mniejsza.

Nie tylko że dysk musi odczytać jeden sektor więcej, ale też sam interpreter PHP musi wykonać jedną komendę includowania więcej.



Wersja standard jest za darmo/GPL i działa prawie tak samo jak wersja płatna. Jeżeli nie potrafisz sobie poradzić z wersją standard, to przy wersji płatnej będzie to samo...

Przecież właśnie próbuję ci wytłumaczyć jak działa Hypercacher... ale nie wiem jak można bardziej zrozumiale wytłumaczyć wklejenie dwóch fragmentów kodu za pomocą CTRL+C / CTRL+V ?



Bardzo przyłożyłem się do mojej dokumentacji, ale pewnie można to zrobić lepiej.

Moje pomysły jak ulepszyć dokumentację już się skończyły. Naprawdę nie wiem jak można to poprawić. A może ty masz jakieś lepsze pomysły ? Chętnie je wdrożę.



Przykro mi że Cię zawiodłem. Niestety nie potrafię tego wyjaśnić w bardziej przystępny sposób.
W kodzie są dwa duże fragmenty kodu. Trzeba je wkleić w dwóch miejscach. To wszystko.

Nie wiem jak można to prościej powiedzieć.



Nie wyjaśnię, dopóki kolega wyżej nie zacznie współpracować, a będzie tylko siał zamęt.





Masz częściowo rację, bo można wklepać adres

i zobaczyć listę plików. Chyba dodam dodatkowe zabezpieczenie - plik index.html w folderze _cache, co sprawi że odczytanie jego zawartości stanie się niemożliwe bez znajomości sumy MD5.


Ale przewidziałem to wcześniej i już od najstarszych wersji programu i wprowadziłem środki zapobiegawcze:

1. Już sama zmiana nazwy folderu "_cache" utrudnia tą możliwość

2. Do nazwy pliku MD5 przy HASH'owaniu (przed zahaszowaniem) dodawana jest SÓL - tak samo jak przy zapisywaniu haseł w Linuksie, co skutecznie likwiduje możliwość przewidzenia sumy wynikowej MD5, co likwiduje możliwość odczytania plików (bez znajomości sumy)

3. Na mojej stronie jest możliwość zamówienia płatnej instalacji wraz z podniesieniem stopnia bezpieczeństwa - przy wyborze takiej opcji zmieniam SÓL, folder cache, oraz inne rzeczy. Oczywiście możesz to zrobić sam, bo dla programisty jest to dość proste, ale dla ludzi którzy nie znają się na programowaniu istnieje ta opcja.

4. Panele administracyjne nie powinny być cache'owane. Moje instrukcje instalacyjne do CMSów też są zbudowane tak, żeby panele nie były cache'owane - co uniemożliwia odczytanie "krytycznych danych".

Hahaha... no prosze cie. A co jesli plik glowny jest pofragmentowany na 20 kawalkow? to jeden odczyt w ta czy w tamta... litosci. Poza tym wiesz do czego sluzy bufor dysku i pamiec RAM? jesli ten plik jest czesto uzywany - a zakladam ze tak jest bo wlasnie po to pisales ten skrypt to zapewno siedzi on non stop w pamieci operacyjnej i interpreter php na pewno nie odczytuje go z dysku za kazdym razem bo by server padl przy wiekszej liczbie odwiedzin - nieco brakuje ci orientacji w tym temacie. To co napisales to jest optymalizacja na poziomie moze 1 sek na miesiac. Zaloze sie, z calym szacunkiem dla twoich umiejetnosci, ze w kodzie jest duzo wiecej fragmentow ktore wymagaja poprawy niz cos takiego. Przerost formy nad trescia.


Mnie chodzilo o jedna zmienna a nie o ogolna idee dzialania Hypercacher'a - ta znam b. dobrze.


To ci nic nie da, bo jesli znam URL to sobie wygeneruje sam MD5 i wklepie gotowy adres. Dokladnie tak samo jak robi to twoj skrypt i tak czy owak sie do niego dostane.


Tutaj sie zgodze.


No i co z tego??? wezme za pomoca kodu skryptu twojego wygeneruja sobie ta sume dokladnie w taki sam sposob jak on to zrobil w orginale. Co innego gdyby ten fragment kodu byl tajny ale nie jest, kazdy moze pobrac HC i sprawdzic jak on to robi. Cos jak crackowanie programu - uzyskanie keygeneratora na podstawie zdiasemblowanego kodu execka aplikacji.


Acha, no to co innego Wogole co to jest SÓL ??? domyslam sie ze cos jest dorzucane do stringa przed hasowaniem?

Nie ma różnicy. Jeden odczyt o 5KB większego pliku (np. rozmiar bazowy 40KB + rozmiar Hypercachera 5 K będzie zawsze szybszy niż dwa odczyty - jeden 40 KB z jednego sektora dysku (nawet zcache'owanego) oraz drugi 5KB w innym sektorze.



Mylisz się. A to dlatego, że BUFOR jest także zajęty przez miliony innych plików... więc każdy dodatkowy plik to dodatkowe obciążenie dla servera.

Poza tym nie powiedziałem tutaj chyba jeszcze że mam prawdziwą manię na punkcie szybkości tego programu



Ohhhh nie wątpię że tak jest. Na pewno coś da się zrobić jeszcze lepiej i mniejszą ilością szybszych instrukcji.

Jakieś sugestie ?




Ściągnij DEVELOPERS PACK (na samym dole listy pobierania na mojej stronie). Przecież mówiłem że tam wszystko jest wyjaśnione... każda zmienna jest opisana dłuuuugim komentarzem.



Nie rozumiesz. Nie możesz znać sumy MD5 od czegokolwiek, jeżeli przez zahaszowaniem dodana jest do danych wejściowych SÓL !

SÓL SÓL SÓL - z solą nie rozczytasz ŻADNEGO wyniku MD5 bez znajomości SOLI. Jeżeli ktoś w skrypcie ZMIENI SÓL (wystarczy jeden bajt zmienić), to nie ma możliwości wygenerowania identycznego MD5

Jeżeli nie wiesz co to SÓL to poczytaj. Ja nie będę ci tutaj tego tłumaczył.


Po drugie:

Nawet gdyby sól wyłączyć, to nie możesz znać wynikowego MD5, jeżeli nie znasz wszystkich potrzebnych danych serwera - takich jak dokładna serwerowa ścieżka do pliku PHP, dokładny URL, dokładna struktura zmiennych POST i GET. Bez tego nie wygenerujesz MD5 - bo te dane też są dodawane do ciągu generującego MD5 i działają w tym kontekście podobnie do soli. A zdobycie tych wszystkich danych jest wbrew pozorom WCALE NIE TAKIE ŁATWE !

Żeby znać te dane, musiałbyś mieć wgląd w konfigurację serwera którego folder _cache chcesz przejrzeć.

Sól to taki zwiazek chemiczny powszechnie uzywany w przemysle spozywczym.


Czaje o co ci chodzi.

A co do odczytu z dysku, to zauwaz ze szybciej jest wygenerowac czasami proste zapytanie do mysqla niz odczytywac dane z dysku z cachu. Sam stwierdziles ze trwa to dluzej (stad brak include)... wiec wg. mnie nie ma to sensu bo mysql odpowiada duzo szybciej niz trwa odczyt z dysku. Najczestrze zapytania sa trzymane w ramie, i dostep do tego na pewno znacznie szybszy niz do dysku, oraz transfer danych rowniez. Nad baza mysql pracuje sztab ludzi i chodzi juz ona max. szybko jak tylko to jest mozliwe. Zreszta gdyby trzymanie danych w plikach bylo szybsze to nie rozpowszechnila by sie taka baza danych. Wiec to co pseudo zaoszczedziles na include tracisz setki razy w samej idei trzymania tego jako pliki.

Może trochę za ostro podszedłem do twojego produktu, ale twoja wypowiedź:


to już przesada! Myślisz że byłbym moderatorem na tym forum gdybym "kłamał i siał zamęt"? Jeśli czegoś nie jestem pewien to przynajmniej się do tego przyznaję.

Opisałem to co widziałem. Jesli tamta strona jeszcze istnieje (a jeśli nie to postawie nową instancję) zainstaluję na niej ponownie najnowszą wersję tego produktu i przetestuję. Zrobię to tylko dlatego żeby być fair.

OK, dobra przepraszam - moja wina.

Mnie łatwo zdenerwować i łatwo się unoszę. Myślałem że jesteś jakimś forumowym pół-trollem i drażnisz się ze mną.

(btw. gdzie jest napisane, że jesteś moderatorem, bo w ogóle tego nie widać ??)



Cóż.

Teoretycznie masz rację. Ale niestety w praktyce odczyt z dysku jest szybszy. Dużo szybszy.

Pewnie to wina obciążenia serwera - być może w jakichś idealnych warunkach byłoby tak jak mówisz.

W moim profilu widać do jakich grup moderatorów należę

ehh ale wy sie tu klucicie
SoofMan - jesli chodzi o zabespieczenia to przecierz w moich ostach wczesniejszych napisalem rozwiazanie czyli zmiana nazwy katalogu _cache na cyfrowa i dodanie do nazwy pliku rozszerzenie cyfrowe (czyli haszowana_nazwa_pliku.545334654) i to wystarcza w pelni.
co do bespieczenstwa wygenerowania kodu unikalnego wystarczy dodac do ciagu generujacego funkcje uniqid(); i zapewniam Cie ze to tez wystarczy, hyy.. hyba ze ktos zna dokladny folder z cache i poprostu walnie sobie jakis tam ciag na chbil-trafil i trafi

a i oczywiscie musze sie zgodzic z Soof'em cacher jest szybki bo jedynie co wykonuje w php to sprawdzanie a zarazem wczytanie pliku z czystym html'em naszej sztrony (zero polaczen z baza danych) :]

Pozdro!!

No przecież tak jest... nazwę folderu cache można sobie łatwo zmienić na inną jak ktoś potrzebuje...



Ale to o czym mówisz to jest właśnie sól... w kodzie są dwie różne zmienne które służą za sól... wystarczy do jednej z nich wstawić wynik funkcji UNIQID i już masz idealne zabezpieczenie.



Taaaa zapomniałem przecież dodać że w przypadku odczytu z bazy SQL, trzeba wykonać kilka osobnych połaczeń żeby wykonać kilka kwerend, co zajmuje czas.

Poza tym server SQL ma zawsze jakieś obciążenie, co sprawia że jego odpowiedź nie jest natychmiastowa. I dochodzi jeszcze komunikacja z serverem SQL przez sieć, co też zajmuje przecież paredziesiąt milisekund.

No więc nic dziwnego że jeden odczyt z dysku będzie szybszy.

Jesli twierdzisz ze odczyt z dysku jest szybszy niz z RAM'u to nie mam juz pytan.

W takim razie wielkim bledem bylo stworzenie pamieci RAM, przeciez HDD jest szybszy... LOL.

Powiem ci tak:

bez twojego cachu:
- duze obciazenie CPU (zapytania sql), male dysku,

z:
- male obciazenie CPU (brak zapytan sql), duze dysku (ciagly odczyt danych),

to jest bardzo ogolnikowo ale tak to +/- wyglada.

Niestety popełniasz logiczny błąd w rozumowaniu.


Przypuśćmy że mamy skrypt nazwa_skryptu.php którego zawartość wygląda tak jak niżej:



Wyobraź sobie co się dzieje kiedy serwer go otwiera BEZ użycia Hypercachera.

1. Załadowanie Interpretera PHP
2. Wczytaj z dysku i Interpretuj nazwa_skryptu.php
3. Wczytaj z dysku i Interpretuj costam1.php
4. Wczytaj z dysku i Interpretuj costam2.php
5. Wczytaj z dysku i Interpretuj costam3.php
6. Wczytaj z dysku i Interpretuj costam4.php
7. Wczytaj z dysku i Interpretuj costam5.php
8. Wczytaj z dysku i Interpretuj costam6.php
9. Wczytaj z dysku i Interpretuj costam7.php
10. Wczytaj z dysku i Interpretuj costam8.php
11. Wczytaj z dysku i Interpretuj costam9.php
12a. Połącz przez sieć lokalną z bazą MySQL
12. Wykonaj kwerendę SQL 1
13. Wykonaj kwerendę SQL 2
14. Wykonaj kwerendę SQL 3
15. Wykonaj kwerendę SQL 4
16. Wykonaj kwerendę SQL 5
17. Wykonaj kwerendę SQL 6
18. Wykonaj resztę kodu
19. Wyrzuć kod HTML do przeglądarki



A teraz wyobraź sobie co się dzieje kiedy serwer go otwiera z użyciem Hypercachera.

1. Załadowanie Interpretera PHP
2. Interpretuj nazwa_skryptu.php
3. Hypercacher - znaleziono aktualny plik cache odpowiadający zadanemu żądaniu
4. Hypercacher - odczytaj kod HTML z pliku na dysku (szybsze nawet od pojedynczego include)
5. Hypercacher - wyrzuć gotowy kod HTML do przeglądarki

Mam nadzieję że teraz jest to dla ciebie zrozumiałe dlaczego jeden odczyt z dysku jest szybszy od pełnego przetwarzania skryptu.

1. RAM jest znacząco szybszy od operacji na dysku, w szczególności zapisu i wyszukiwania
2. Stosowanie keszowania do plików nie zawsze jest szybsze od oryginału, jako że MySQL jest bazą działającą w pamięci RAM, tak więc jeżeli nie ma jakiś złożonych i połączonych zapytań to MySQL górą.
3. wykonywanie przez serwer w kółko tych samych plików to nie problem, jako że z tego właśnie powodu będą w keszu dysku. Odczytywanie zmiennych plików częściej będzie wymagało ich rzeczywistego odczytania z dysku. "PHP" domyślnie tego nie robi, ale np. w przypadku pythona i mod_python/apache binarna kopia kodu aplikacji jest wczytywana przy starcie serwera do RAM i serwer ciągle z niej korzysta.
4. nie staraj się udowodnić wyższości swojego pseudosuperkodu. Na forum.php.pl ci się dostało to wróciłeś tutaj Twój kod nie jest ani odkrywczy, ani nie jest szczególnie pomocny. Aplikacje działające na dużą skalę mają własne dedykowane rozwiązania i działają w zupełnie inny sposób, a te mniejsze dla "zwykłego użytkownika" wystarczy że będą porządnie wykonane by działać wydajnie. Nie wolno zasłaniać się "to ja to będę keszował" bo doprowadzi to do pogorszenia się kodu aplikacji. PHP-Fusion i mu podobne nie powinny rozwiązywać problemów wydajności w ten sposób.

Oho, a ten zwnowu swoje.

Ekhm...



Zadowolony ? Dwa razy powtarzał nie będę.



Hahahahahahahahahaha
hahahahahahahahahaha

Tak. Masz rację. W teorii. Szkoda że w praktyce ja mam rację. Mój "pseudoprodukt" wymyśliłem dokładnie dlatego i TYLKO dlatego, że serwer PADAŁ od natłoku tych "superszybkich" odczytów z bazy MySQL i zgadnij co - po zainstalowaniu problemy zniknęły, a obciążenie serwera spadło chyba o 70%.

Miłego bujania w obłokach :D.




1. Pliki GIF, JPG, ZIP, RAR też są w cache dyskowym. I jest ich tyle, że na 100% zajmują większość buforów dyskowych. Więc przy odczycie zmodyfikowanych plików bufor dyskowy nie pomaga tak bardzo jak by mógł.

2. Nawet samo wykonywanie skomplikowanego kodu wczytanego NAWET z pamięci jest dużo wolniejsze od wczytania pojedynczego pliku. Hypercacher ma specjalnie tak proste instrukcje i nieskomplikowane algorytmy po to żeby nie obciążać procesora.

3. LOL. Gadaj zdrów. Mimo całej "teorii" którą mi tu wykładasz, Hypercacher działa po prostu szybciej. Patrz wyżej - masz wytłumaczone dlaczego: z Hypercacherem liczba potrzebnych do wykonania instrukcji spada wielokrotnie. Nie trzeba wykonywać skomplikowanych funkcji obliczen, includow, polaczen z baza danych - to wszystko zabiera cenną moc CPU.

3a. Nawet kod który jest wczytany z RAMu trzeba interpretować i wykonać -> CPU.




[gromki smiech mode]
Hahahahahahahahahahahaha
hahahahahahahahahahahaha
hahahahahahahahahahahaha
[/gromki smiech mode]

Mała podpowiedź:
Gdzie widzisz napisane coś o wyższości mojego "pseudoproduktu" ?



[gromki smiech mode]
"Dostało mi się"

Hahahahahahahahahahahaha
hahahahahahahahahahahaha

"Dostało mi się"

hahahahahahahahahahahaha
hihihihihihihihihihihihihihihihi

ohhhh ohhh nie wytrzymam...
[/gromki smiech mode]

Oho cóż ja widzę - Mr. Wiecznie niezadowolony is back.


-------------------------
Nie ma to jak duża dawka humoru/rozrywki o poranku, dzięki stary :D