Mariusz Tarnaski "MariuszT"

15 odpowiedzi dla tego wpisu

1. Michał napisał: 02.08.09 o godzinie 16:05

   Sam wpisujesz keywordsy do meta tagów na nasztomaszow.pl, czy generujesz je z tekstu?

   Czemu na nasztomaszow.pl nie ma index.php. Ciekaw jestem z czego ty korzystasz. zmieniasz htacessem index?

2. MariuszT napisał: 02.08.09 o godzinie 22:59

   Przy meta tagach na nasztomaszow.pl nie kombinowałem zbytnio. Title to tytuł, description to zajawka do artykułu a keywords to tagi na początku i kilka podstawowych słów, które zawsze się pokazują.

   Korzystam z własnego oprogramowania i sam decyduję jaka ścieżka wskazuje na jaki zasób. Nie dodawałem ścieżki „index.php” bo nie mam takiej potrzeby. Jeżeli bym chciał to mógłbym ustawić aby ścieżka „index.php” kierowała np. na jakiś artykuł. Oczywiście po wejściu na http://www.nasztomaszow.pl nadal otwierałaby się strona główna. Podsumowując: przy moim oprogramowaniu „index.php” nie byłoby wskazaniem na jakiś plik a po prostu ścieżką do której mógłbym przypisać cokolwiek mi się podoba tak jak np. /kamera/ wskazuje na kamerę internetową.

3. Michał napisał: 03.08.09 o godzinie 19:49

   Wybacz ciekawość, ale czemu wyłączyłeś możliwość komentowania w artykule: http://www.nasztomaszow.pl/akt.....zeprosiny/ to zwykłe wyłaczenia w PA, czy może kombinacja w cache, bo myślę, ze masz cache na nasztomaszow.pl

4. MariuszT napisał: 04.08.09 o godzinie 0:03

   Komentarze zostały wyłączone na życzenie Pana Walczaka.

   Praktycznie wszystko na nasztomaszow.pl siedzi w cache, oprócz komentarzy Na nie nie starczyło już czasu, kiedy indziej się tym zajmę. Do tego stopnia wszystko zcachowałem, że strona działa nawet gdy padnie baza danych. Nie sposób zauważyć różnicy oprócz tego, że nie da się przeglądać i dodawać nowych komentarzy (o czym informuje odpowiedni komunikat).

   Dodając newsa można określić do kiedy mogą być dodawane komentarze (data w przyszłości) lub zupełnie je wyłączyć (w bazie w polu daty jest wtedy 0).

5. Michał napisał: 04.08.09 o godzinie 12:32

   Mhm, no to gratulacje taki portal i wszystko w cache. Ja dawno bym się zagubił w kodzie. Interesuje mnie tylko jedno jak robisz ten cache? Ja robiłęm to w ten sposób, ze wrzucałem poprzez odpowiednią klasę rekord do pliku poszczególne rekordy są oddzielone separatorem, potem explode i mam gotową tablicę. tylko na każdy artykuł 1 plik. zawartość trzymałem w plikach html. gdy zaszła jakaś zmiana(edycja) to skrypt kasował plik, a skrypt na podstawie wpisu do bazy tworzył nowy. Nazbierało się troszkę tych plików. A wiec ty też masz np jeden artykuł w pliku?

6. MariuszT napisał: 04.08.09 o godzinie 12:52

   Napisałem sobie dwie funkcje do zapisu i odczytu cache. Mogę za ich pomocą zapisać tak naprawdę co mi się podoba ale uznałem, że najrozsądniej będzie gdy będę pobierał dane z bazy, tworzył tablicę, serializował ją i wtedy zapisywał do cache. Potem przy odczycie odserializowuje dane i mam ładną tablicę PHP Wszystkie testy wskazują, że takie rozwiązanie jest najszybsze.

   Cache jest trzymany w osobnych plikach, odpowiednio posegregowanych w katalogach. Jest tego dużo ale jak się dobrze stworzy strukturę katalogów to nie ma wielkiego bałaganu

   Ja dodatkowo tworzę na serwerze katalogi, które się nazywają tak jak artykuły. Bo zauważ, że w adresach do artykułów nie jest przekazywany żaden ID określający numer tego artykułu. Gdyby potraktować to standardowo to trzeba robić zapytanie do bazy danych, które najpierw odczyta to ID mając jedynie adres i dopiero wtedy można działać dalej. Ale wtedy gdyby padła baza danych to strona by przestała działać. A tak mam w odpowiednim miejscu stworzoną strukturę katalogów identyczną jak tytuły artykułów i gdy ktoś wchodzi na artykuł to w ogóle nie ma połączenia z bazą danych, jest uruchamiany pliczek w odpowiednim katalogu gdzie jest zapisane ID tego artykułu, potem pobieram cache i gotowe. Bałaganu też nie mam bo ta cała struktura katalogów jest trzymana w odpowiednim katalogu i użytkownik jest tam przekierowywany za pomocą .htaccess. Inaczej musiałbym mieć wiele katalogów w katalogu głównym strony i wtedy faktycznie byłby bajzel.

   Brzmi to może trochę skomplikowanie i trochę posiedziałem żeby osiągnąć taki efekt ale gdybyś zobaczył kod i jak to wszystko wygląda od środka to nie byłoby już takie straszne

   BTW moje funkcje do cache pozwalają ustawiać i potem uwzględniać czas ważności cache. Dzięki temu nie muszę używać crona, ustawiam żeby np. główne newsy na stronie głównej miały pół godziny ważności i gdy minie czas ważności i ktoś wejdzie na stronę to cache automatycznie się generuje na nowo. Natomiast gdy pada baza danych to jest polecenie olania znacznika czasu i jest używany stary cache aż do czasu gdy baza znowu zacznie działać.

   I jeszcze jedna sprawa bo to ważne. Cache nie jest pobierany za pomocą include/require. Pobieram zwyczajnie zawartość pliku i odpowiednio obrabiam (chociażby odczytanie i usunięcie z późniejszych wyników znacznika czasu).

7. Michał napisał: 04.08.09 o godzinie 16:29

   „Cache nie jest pobierany za pomocą include/require” – dokładnie tak myślałem. Ja pobieram file_get_contents() i dopiero działam dalej. Dzięki za wyczerpujące informacje, których, nie musiałeś podawać, ale z dobrej woli podałeś. Też jestem autorem kilku funkcji „cacheujących” i twoje powyższe informację są mi bardzo pomocne.
   PS:
   Przepraszam za OT i życzę dalszych sukcesów w NaszTomaszów.pl

8. kmg napisał: 05.08.09 o godzinie 10:20

   Moze sie myle, ale Mariusz jest wśród osób z którymi utrzymuje kontakt osobą najbardziej zorientowaną w PHP (nie, niczego nie chce i nie potrzebuje od Ciebie niczego – przynajmniej na razie ).

   „BTW moje funkcje do cache pozwalają ustawiać i potem uwzględniać czas ważności cache. Dzięki temu nie muszę używać crona, ustawiam żeby np. główne newsy na stronie głównej miały pół godziny ważności i gdy minie czas ważności i ktoś wejdzie na stronę to cache automatycznie się generuje na nowo. Natomiast gdy pada baza danych to jest polecenie olania znacznika czasu i jest używany stary cache aż do czasu gdy baza znowu zacznie działać.”
   No właśnie – tylko do tego chciałem się odnieść. Oczywiście, rozwiazanie niby ok. Ale czasami z danymi nie trzeba robić nic. Czy nie lepszym rozwiązaniem byłoby:
   jeśli(istnieje plik z cache w html)
   zwykle include()
   jesli nie
   {
   jeśli(istnieje plik z cache)
   obrabiaj()
   jesli nie
   wygeneruj()
   }

   Nie pytam czy to lepsze, podsuwam pomysł Michałowi. Pewnie zależy od obciążenia, przy 50 użytkownikach online niewielkie znaczenie. Przy 5000 w danej chwili – moze juz mieć znaczenie.

   Zadanie dla chętnego: sprawdzić, czy (a raczej o ile – bo to czy tak to pewnie oczywiste) file_exist() zajmie wiecej czasu niż pobranie z pliku zserializowanych danych, deserializacja i sprawdzenie warunku czasowego. Nie chodzi o konkretne wartości, raczej rząd wielkości. Tak, tak – wiem. „Zrób to sam leniu”. Tylko kiedy ;P

9. MariuszT napisał: 05.08.09 o godzinie 10:55

   @Michał – jak tylko będziesz miał jakieś pytania to pisz

   @kmg – Przed podjęciem decyzji jak taki system cache ma wyglądać sporo poczytałem na ten temat. Kolesie robili testy między innymi zserializowanych danych, szybkości odczytu plików ini czy includu pliku z gotowym kodem PHP z wygenerowaną tablicą. Wszystkie testy (często niezależne) wskazały jednoznacznie, że serializacja jest najszybsza. Na drugim miejscu plasują się pliki ini.

   Czemu się tak dzieje? Bo w tych przypadkach nie ma konieczności uruchamiania parsera PHP przy pobieraniu danych. Przy serializacji uruchamiamy tylko jedną funkcję a przy ini korzystamy z tych samych mechanizmów, które są odpowiedzialne między innymi za parsowanie pliku konfiguracyjnego php.ini.

   Oczywiście najszybsza metoda to pewnie wygenerować czysty kod HTML, zapisać go do pliku a potem zaincludować czy tam pobrać jakąś funkcją (do sprawdzenia, też mi się nie chce ). Tylko to jest strasznie niewygodne rozwiązanie bo niewiele z takim cache możesz zrobić, zmienisz coś na stronie i cały cache trzeba generować od nowa.

   A tak sobie deserializuję i mam gotową tablicę PHP, którą mogę dowolnie obrabiać.

   Wszystko zależy od potrzeb. Na upartego w ogóle można generować całe pliki HTML i przy wyświetleniu strony nawet nie odpalać PHP. Ale ja raczej aż takich kombinacji nie potrzebuję Profilowałem nasztomaszow.pl i strona generuje praktycznie żadne obciążenie. Przeważnie wszystko wykonuje się w kilka ms. Dla porównania czysta instalacja Drupal (czyli taka, która właściwie nic nie ma…) uruchamia się u mnie kilkaset ms. Nie wspomnę co się dzieje przy podobnie do nasztomaszow.pl rozbudowanym serwisie na Drupalu….

10. Michał napisał: 05.08.09 o godzinie 16:05

    A jak z paginacją w cache?
    Stronicujesz dane na podstawie folderów, tzn, ze pobierasz listę wszystkich plików w folderze np Aktualności i je stronicujesz, czy masz zapisaną gdzieś w pliku listę artykułów. Drugie rozwiązanie jest chyba gorsze.

    Nasuwa mi się pytanie: Po co serializować tablicę. Jest to wygodne, ale wykorzystuje duży zasób danych, bo klucze tej tablicy są również zapisywane w pliku, a po co.

    ja w swoim cache zrobiłem tak, że odpowiednia funkcja przepuszcza wszystkie elementy tablicy przez urlencode i pomiędzy elementami dodaje separator, który ma odpowiednik w urlencode(żeby uniknąć niespodzianki). Taki plik o wiele mniej zajmuje(nie jest to jakaś zaskakująca wielkość, ale zawsze mniej). przy odczytaniu cache funkcja tworzy tablice przez explode i elementy tablicy przepuszcza przez urldecode. W ten sposób mamy tablicę danych o kluczach 0, 1, 2, 3… itd.

    Nie wiem, które rozwiązanie jest lepsze. Moje zużywa mniej pamięci na dysku, ale więcej mocy obliczeniowej. ;P

11. MariuszT napisał: 06.08.09 o godzinie 0:50

    Z paginacją w cache jeszcze się nie musiałem bawić ale prędzej czy później stanę przed tym problemem dlatego wstępnie mam przemyślaną sprawę. Oprzyjmy to na przykładzie artykułów bo zamierzam w przyszłości wprowadzić mechanizm dzielenia długich artykułów na podstrony.

    Ja to widzę tak, że każdy artykuł ma swój katalog (tak jest teraz u mnie) a tam pliki z cache np. 1.php, 2.php, 3.php itd. W każdym pliku jedna strona i informacja o ilości wszystkich podstron. W ten sposób będę mógł wyświetlić odpowiednią podstronę i wygenerować linki do innych podstron. Oczywiście jeżeli pliku nie będzie to znaczy, że takiej podstrony nie ma i ktoś musiał ręcznie wpisać błędny numerek.

    Ale ostrzegam, że to tylko takie wstępne przemyślenia, może będą zweryfikowane gdy usiądę do problemu

    Serializacja jest szybka. Poza tym wygodniej jest gdy ma się klucze tekstowe, przy kluczach liczbowych można się pogubić w kodzie. Jak bardzo chcesz mieć małe pliki to w serializowanej tablicy również możesz użyć kluczy liczbowych, wtedy strata w objętości pliku będzie minimalna a skrypt zadziała szybciej. Ale moim zdaniem gra nie jest warta świeczki. Nawet przy kluczach tekstowych różnice w objętości cache będą naprawdę minimalne.

    A tak swoją drogą to urlencode powoduje zamianę wszystkich niealfanumerycznych znaków na %XX gdzie XX to liczba. Tak więc naprawdę nie rozumiem dywagacji na temat rozmiarów plików skoro zastosowana przez Ciebie metoda w skrajnych przypadkach może wygenerować znacznie większy plik niż ten z zserializowanymi danymi

    PS
    Moje funkcje do cache są na tyle uniwersalne, że serializacja to jedynie mój wybór ale nic nie stoi na przeszkodzie aby użyć innego sposobu. Nie ma tu żadnych ograniczeń.

12. Michał napisał: 06.08.09 o godzinie 11:18

    Zauważyłem, ze przy stronicowaniu komentarzy dodajesz pewną dodatkową liczbę, jak się domyślałem to numer strony artykułu.

    W cache można dawać pliki 1.php, 2.php, 3.php ale jak zrobić to w bazie. Ja na tekst artykułu mam pole longtext. Dotychczas na zajawkę używałem dodatkowej komórki short. Ale mi się wydaje, ze to nie ma sensu.

    Myślę, że można dodawać , i do tego komentarza miałbym zajawkę, gdybym chciał dzielić tekst na podstrony to nie działoby się to po ilości znaków/wyrazów, tylko spreparowałbym znacznik w FCKeditor i dawałby . Skrypt dzieliłby tekst na podstrony i gitara.

    Co o tym myślisz jako doświadczony programista?

13. MariuszT napisał: 06.08.09 o godzinie 11:27

    Tak, jest dodatkowa liczba przy stronicowaniu komentarzy żebym w przyszłości mógł łatwo wprowadzić stronicowanie pojedynczego artykułu i żeby linki się już nie zmieniły. Po prostu zaprogramowałem to na przyszłość.

    W bazie można różnie kombinować ale jeżeli masz cache to ja bym zrobił zwyczajne pole TEXT i jakiś znacznik rozdzielający podstrony. Potem explode i wygenerowanie cache. Gdyby nie było cache to bym się zastanawiał nad poprawą wydajności ale jeżeli jest cache to jedno explode przy generowaniu nie zaszkodzi Zwłaszcza, że tak będzie najłatwiej dla osób, które mają wprowadzać tekst. Wstawi sobie znacznik i wie, że mu stworzy następną podstronę.

    Dla zajawki mam osobne pole w bazie. Chociażby dlatego, że nie zawsze jest zajawka a czasami jest tylko zajawka.

14. ecco napisał: 24.08.09 o godzinie 14:10

    Mariusz, napisałeś:
    „Przed podjęciem decyzji jak taki system cache ma wyglądać sporo poczytałem na ten temat.”
    czy mógłbyś w związku z tym podać linki do swoich lektur?

15. MariuszT napisał: 24.08.09 o godzinie 14:27

    Niestety jedyne co mi przychodzi teraz do głowy to to: http://www.zyxist.com/pokaz.ph....._benchmark

    Oglądałem też jakieś benchmarki w zagranicznych serwisach ale już nie pamiętam co i gdzie. W sumie to nawet nie musiałem szukać info na ten temat bo na przestrzeni kilku ostatnich lat wielokrotnie napotykałem różnego rodzaju teksty i porównania gdzie zserializowane dane zawsze wiodły prym.

Odpowiedz

• Dlaczego nie używam Google Chrome?
• Firefox, odnośniki do e-maili i GMail
• 
• Firefox Download Day
• Tymczasowy adres e-mail

O blogu

Blog przede wszystkim o Internecie i mojej pasji jaką jest tworzenie stron www. Ale nie ograniczam się do jednej tematyki, piszę o wszystkim o czym mam ochotę :-)

"Nie mam żadnych specjalnych talentów. Jestem tylko namiętnie ciekawy." Albert Einstein

Tagi

Jeśli uważasz, że ten wpis jest ciekawy to umieść link do niego na swojej stronie
Skopiuj poniższy kod i wklej go u siebie (Ctrl+C - kopiowanie)
Będzie to wyglądało tak: Wtyczki do Firefoxa, które musi posiadać każdy webmaster

<a href="http://www.tarnaski.eu/blog/wtyczki-do-firefoxa-ktore-musi-posiadac-kazdy-webmaster/">Wtyczki do Firefoxa, które musi posiadać każdy webmaster</a>