Gander napisał/a:
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.

m_i_n napisał/a:
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.

Widać nie pofatygowałeś się żeby sprawdzić o co chodzi.

Wszystko jest opisane jak należy.

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.

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

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

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

Te problemy o których piszesz są mi znane - rozwiązałem je już dawno temu.

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.

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

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.

m_i_n napisał/a:
Blee... co to za roznica? na pewno nie w predkosci.

m_i_n napisał/a:
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.

m_i_n napisał/a:
Prezentujesz pewien produkt, nawet bierzesz za to pieniadze, wiec w twoim interesie lezy by uzytkownik nie mial z nim problemu.

m_i_n napisał/a:
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ą.

m_i_n napisał/a:
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.

m_i_n napisał/a:
To jak wyjasnisz przypadek kolegi wyzej?

m_i_n napisał/a:
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.

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.

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 ?

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.

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

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)

przy wyborze takiej opcji zmieniam SÓL

m_i_n napisał/a:
Hahaha... no prosze cie. A co jesli plik glowny jest pofragmentowany na 20 kawalkow?

m_i_n napisał/a:
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.

m_i_n napisał/a:
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.

m_i_n napisał/a:
Mnie chodzilo o jedna zmienna a nie o ogolna idee dzialania Hypercacher'a - ta znam b. dobrze.

m_i_n napisał/a:
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.

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.

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

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 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.

Gander napisał/a:
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.

m_i_n napisał/a:
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.

slawekneo napisał/a:
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.

slawekneo napisał/a:
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

slawekneo napisał/a:
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!!

Ale niestety w praktyce odczyt z dysku jest szybszy. Dużo szybszy.

m_i_n napisał/a:

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.

Riklaunim napisał/a:
1. RAM jest znacząco szybszy od operacji na dysku, w szczególności zapisu i wyszukiwania

Riklaunim napisał/a:
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ą.

Riklaunim napisał/a:
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.

Riklaunim napisał/a:
4. nie staraj się udowodnić wyższości swojego pseudosuperkodu.

Riklaunim napisał/a:
Na forum.php.pl ci się dostało to wróciłeś tutaj :P Twój kod nie jest ani odkrywczy, ani nie jest szczególnie pomocny.