Podstrony
- telcocafe
- [PHP[ Upload plików :/ Looknij !!
- [MySQL] Przeniesienie plików bazy danych ukrycie danych
- Przesyłanie plikow z serwera na serwer przez shell lub inny program
- [httacces?] blokowanie dostępu do plików - dostep tylko z php?
- include(); - aby kilka plików mogło korzystać. Problemik z include(); PHP
- [PHP i chyba JS]Psaek stanu uploadu na mojej stronie o uploadowaniu plików
- [XHTML/CSS] Efekt rollover efekt rollover i kilka plikow graficznych
- [php/mysql] przerobienie kodu aby używał mysql zamiast plików tekstowych
- [PHP] Edycja skryptu do wysyłania plików Zmiana nazwy pliku, jeśli plik już istnieje
- [PHP]Problem z otwieraniem plików doc txt pdf PHP własciwie to nie wiem jak to wytłumaczyć :)
- zanotowane.pl
- doc.pisz.pl
- pdf.pisz.pl
- kudrzwi.htw.pl
telcocafe
Co jest szybsze?1. Wczytanie 5 plików po 1kB
2. Wczytanie 1 pliku po 5kB - nie wszystkie dane/funkcje będą używane zawsze
Jak wg. was będzie szybciej? Może ktoś coś na ten temat wie?
1. Otwieranie dużej ilości plików z potrzebnymi danymi.
2. Otwieranie mniejszej ilości plików z kompletem funkcji, danych...
Użytkownik Ferrari edytował ten post 29 marzec 2005, 16:49
Co jest szybsze?
1. Wczytanie 5 plików po 1kB
2. Wczytanie 1 pliku po 0,2kB
Jak wg. was będzie szybciej? Może ktoś coś na ten temat wie?
1. Otwieranie dużej ilości plików z potrzebnymi danymi.
2. Otwieranie mniejszej ilości plików z kompletem funkcji, danych...
pewnie że jeden... najlepiej to całą strone spakuj w jeden plik :blink: bedzie najszybciej :D
NOWOŚCI w plikach tekstowych
Jak to najlepiej zrobić? Gdyby DANE (nie treści) nowości były w jednym pliku, nie spowolniałoby tak pewnie generowania, lecz co z tymi serwisami, co trzymają po 2000,3000 nowości?
wczytanie 1 większego pliku jest szybsze ale zajmuje więcej pamięci serwera.
Jak proponujecie rozmieścić listę nowości (nie treści!) w plikach?
a) max. 30 nowości w jednym pliku
B) każdy miesiąc = nowy plik = nowości w nim napisane
c) wszystkie w jednym pliku (ja to bym odradzał)
d) inny... jaki?
Oczywiście że szybszym sposobem jest sposób numer 2 :blink:
http://chibiguy.dotgeek.org/
Gdyby nie było tak, że trzeba nieraz wyświetlać tylko tytuły wraz z datą (archiwum, itd...), dobrym rozwiązainem byłoby przechowywanie danych wraz z treścią mniejszą (nie pelną). Może i tak będzie dobre (gdyby wstawić tak możliwość wyświetlania fragmentu treści w archiwum).
Przechowywanie danych o wszystkich nowościach (tytuł, data...) w jednym pliku to też obciążenie dla serwera.
Co więc proponujecie? W jaki sposób powinny być zapisywane dane o nowościach?
Nowy miesiąc = nowy plik?
(50) nowości = nowy plik?
Każda nowość = nowy plik (czyli w celu wyświetlenia 10 nowości na stronie otwieranych jest 20 plików)?
Inaczej???
Chcę uzyskać opinie różnych osób. Jak będzie najlepiej?
TxtSQL? Podobno odczyt z tego jest wolniejszy, a na dodatek po co faszerować CMSa dodatkowymi skryptami (też spowolnienie)? I tak plik tabeli musi zostać wczytany.
Użytkownik Ferrari edytował ten post 17 kwiecień 2005, 18:57
TxtSQL? Podobno odczyt z tego jest wolniejszy, a na dodatek po co faszerować CMSa dodatkowymi skryptami (też spowolnienie)? I tak plik tabeli musi zostać wczytany.
Jeszcze odnośnie txtSQL...
1. Co z tymi, co mają ograniczony transfer (jeśli wczytywane są całe tabele)? - dodatkowe obciążenie serwera.
2. CMS ma być szybki, więc nie będę faszerował go dodatkowo.
3. Ktoś używa tego skryptu? - niech się wypowie coś o nim.
4. Jak wielkie jest spowolnienie?
Dodaj / edytuj / usuń - to już jest w zarządzaniu menu nawigacyjnym (tyle narazie zrobione jest w PA). Trochę kodu trzeba pisać, lecz przy napisaniu funkcji użytecznych także w innych modułach można go zmniejszyć.
Gdyby był sam SQL, byłoby tego mniej, ale coś za coś.
Oczekuję jeszcze odpowiedzi użytkowników na temat rozmieszczenia danych nowości w plikach.
Użytkownik Ferrari edytował ten post 17 kwiecień 2005, 20:36
Nikt nic nie może doradzić?
Przeczytajcie powyższy post i napiszcie, jak wg. was jest lepiej. Może ktoś z was już system nowości na txt i wie, jak najlepiej?
Narazie to chyba najlepszym sposobem jest trzymanie w osobnych plikach informacji typu tytuł, data, wraz z ich mniejszymi treściami.
Wracając jeszcze do SQL...
Racja, że SQL jest prostszy, jeśli chodzi np. o wyszukiwanie... Zastosowanie txtSQL w tym przypadku to to samo, jakby WSZYSTKO (treści, itp. - wszystkie nowości) było w jednym pliku, czyli jeszcze większe obciążenie.
dlaczego jak biorę np. numery ID z tabeli-pliku to działa to znacznie szybciej niż gdy np. pobieram treść wpisów? (oznacza to że nie jest czytany cały plik) :P txtSQL ma dość zaawansowany sposób łączenia się z plikiem :P przyjżyj się klasie.
Użytkownik Riklaunim edytował ten post 20 kwiecień 2005, 17:10
Zastanowię się jeszcze, przepatrzę, co można wywalić z narzędzi txtSQL... Mam za mało opinii na temat tego skryptu (więc utworzę nowy temat).
Wprawdzie ustawienia i tak byłyby zapisywane do pliku .php jako zmienne (funkcja odczytu formularza i zapisu do pliku jest prosta - użycie FOREACH ( $_POST as $data1 => $data2 )... oraz Zapisz() - funkcja już zdefinowana wcześniej).
Zdecydowana większość to dane... Jeśli spowolnienie nie jest duże (do 0,1s), skorzystam z tego.
Użytkownik Ferrari edytował ten post 20 kwiecień 2005, 21:08