Oprogramowanie Forum zostało zaktualizowane z wersji 3.0.0 do najnowezej stabilnej wersji 3.0.6 (z lenistwa nie było pośrednich aktualizacji). Wygląda na to, ze wszystko działa.
Co do reklam to miałem na myśli po prostu statyczny wąski pasek googla wyłącznie na pierwszej stronie Forum - żadnych wyskakujących reklam, animacji itp. W ramach programu AdSense za klikanie na ten pasek mozna by zmniejszyć obciązenia finansowe związane z Forum. To jednak na razie sprawa przyszłości. Teraz ważne jest bieżące funkcjonowanie Forum - zapraszam do dyskusji merytorycznych na termat lamp .
P.S. Pracuję nad optymalnym odbudowaniem indeksu wyszukiwarki, więc przez jakiś czas jej funkcjonalność będzie ograniczona.
Wydaje mi sie, ze to chodzi o rozmiar pliku bazy, ktory nie moze przekroczyc 500MB i usuwanie zalacznikow albo/i zawieszanie galerii Triody srednio chyba pomoze w tej kwestii... Admin pisal o 500MB pliku MySQL a samych zalacznikow na Triodzie jest pewnie z 5-6GB.
Pozdr,
-Tomek Drabas
________ "One should not pursue goals that are easily achieved. One must develop an instinct for what one can just barely achieve through one's greatest efforts."
—Albert Einstein tomdrabas.com
A od kiedy MySQL ma takie ograniczenia? Jak ostatnio coś na nim robiłem (wieki temu, wersja 3), to pojedyncza tabela musiała się mieścić w dwóch albo czterech giga.
Czy może jest to ograniczenie pochodzące od dostawcy hostingu?
Ograniczenia narzucane przez firmy hostingowe na bazy danych biorą się stąd, że wraz z ich wielkością drastycznie rośnie ilość zasobów potrzebnych do pracy z taką bazą.
Kto nie wierzy niech sobie zrobi tabelę z paroma kolumnami zawierającą np. 10,000 rekordów i zobaczy jaki jest czas wyszukania jednego wiersza, a następnie eksperyment powtórzy zwiększając za każdym razem tę liczbę kilkukrotnie. Do pewnego momentu, wyznaczonego głównie ilością pamięci przydzielonej dla serwera MySQL/użytkownika lub całkowitą ilością systemowej pamięci, spadek wydajności będzie w przybliżeniu liniowy. Powyżej tego punktu, kiedy baza jest już tak duża, że nie obejmuje jej systemowy bufor ani wewnętrzne bufory MySQLa, następuje drastyczne załamanie 'charakterystyki wydajności' i dalszy wzrost objętości powoduje lawinowo-katastrofalny spadek prędkości działania, aż do wysypania się włącznie.
Samego odgórnego narzucenia wielkości plików z bazami chyba już nie ma, z tego co wiem teraz głównym limitem jest limit systemu plików na jakim leżą tabele.
Dokładnie tak jest. W związku z tym mogę założyć dowolną liczbę baz w ramach dostępnej przestrzeni dyskowej - warunkiem jest jednak, że pojedyncza baza ine przekracza rozmiarem 500MB. Galeria, o której jest mowa powyżej działa na innej bazie więc jej usuwanie lub ograniczanie nic nie wnosi. Problem na szczęście został zwalczony i nie ma potrzeby się nim na razie zajmować
admin pisze:[...]Problem na szczęście został zwalczony i nie ma potrzeby się nim na razie zajmować
...ale prędzej czy później pojawi się ponownie. Może warto by napisać co wpływa na wielkość tej bazy. Z tego co mi dzieciak wytłumaczył są tam przede wszystkim posty i wiadomości prywatne. Z usuwaniem postów trzeba być ostrożnym, bo forum robi się dziurawe, z pustymi odnośnikami i dezaktualizują się wskazania do numeru strony w wątku. Proponuję regularnie czyścić tylko określone działy i na bieżąco usuwać posty o "dupie Maryni". Do tego każdy może przejrzeć swoje foldery z wiadomościami prywatnymi.
Z kolei dopasowanie załączanych obrazków do niezbędnej wielkości, powinno znacząco zmniejszyć transfer.
Czy mamy rozumieć, że każde podforum dostało nową bazę? Jeśli tak, to chyba możemy przewidywać, kiedy znów pojawi się problem Jeśli problem dosięgnąć ma dopiero nasze wnuki to możemy się chyba tym rzeczywiście nie przejmować. W przeciwnym razie trzeba złu zaradzić. Jeśli usuwać wstecz, to lepiej zająć się tym już dziś, bo z upływającym czasem to będzie coraz bardziej podobne do mieszania stwardniałego gipsu...
Furman Zenobiusz pisze:Ograniczenia narzucane przez firmy hostingowe na bazy danych biorą się stąd, że wraz z ich wielkością drastycznie rośnie ilość zasobów potrzebnych do pracy z taką bazą.
Kto nie wierzy niech sobie zrobi tabelę z paroma kolumnami zawierającą np. 10,000 rekordów i zobaczy jaki jest czas wyszukania jednego wiersza, a następnie eksperyment powtórzy zwiększając za każdym razem tę liczbę kilkukrotnie. Do pewnego momentu, wyznaczonego głównie ilością pamięci przydzielonej dla serwera MySQL/użytkownika lub całkowitą ilością systemowej pamięci, spadek wydajności będzie w przybliżeniu liniowy. Powyżej tego punktu, kiedy baza jest już tak duża, że nie obejmuje jej systemowy bufor ani wewnętrzne bufory MySQLa, następuje drastyczne załamanie 'charakterystyki wydajności' i dalszy wzrost objętości powoduje lawinowo-katastrofalny spadek prędkości działania, aż do wysypania się włącznie.
Ale tak jak mówisz to jest jeśli wyszukiwanie jest przeprowadzane metodą full table scanu, czyli w dobrze zaprojektowanym sofcie właściwie nigdy.
Ale tak jak mówisz to jest jeśli wyszukiwanie jest przeprowadzane metodą full table scanu, czyli w dobrze zaprojektowanym sofcie właściwie nigdy.
Niestety nie mogę się z tym zgodzić. Stosowanie indeksów oczywiście przyspiesza wszelkiego rodzaju wyszukiwanie. Niestety raczej nie redukuje zasobów potrzebnych do pracy z bazą danych, a wręcz przeciwnie - może jeszcze je zwiększyć. Indeksy również zajmują miejsce na dysku, często nawet więcej niż oryginalna tabela; są fizycznymi plikami (lub częścią innego pliku), a co za tym idzie - dla sprawnego działania całości najlepiej gdyby również były trzymane w pamięci (systemowy cache) - wtedy wszystko działa najszybciej.
Ogólnie przyjmuje się, że dla mocno obciążonego serwera baz danych wielkość dostepnej, wolnej pamięci fizycznej powinna być co najmniej równa wielkości bazy danych. Na shared hostingu to jednak nierealne do wykonania (tzn realne, ale nie za małe pieniądze). Dlatego dość dobrym rozwiązaniem są VPSy, gdzie dostaje się na stałe część zasobów dla siebie, a np. drugie tyle można wykorzystywać chwilowo. Wtedy 'sąsiedzi' z tego samego hosta nie mają żadnego wpływu na wydajność - jeśli zamulają, to tylko swoją maszynę, a jeśli zbyt długo zajmują dodatkowe zasoby, automatyka ich przycina.
Kupię radia firmy PZT i Elektrit, stan obojętny; najchętniej całe chassis E. Kordial może być zniszczone, tr. sieciowy - Elektrit Rival, PZT Echo 124Z - cewki i ramkę
e-mail piotrostrowski81@wp.pl + PW
.
są tam przede wszystkim posty i wiadomości prywatne. Z usuwaniem postów trzeba być ostrożnym, bo forum robi się dziurawe, z pustymi odnośnikami i dezaktualizują się wskazania do numeru strony w wątku. Proponuję regularnie czyścić tylko określone działy i na bieżąco usuwać posty o "dupie Maryni". Do tego każdy może przejrzeć swoje foldery z wiadomościami prywatnymi. 
Jeśli problem dosięgnąć ma dopiero nasze wnuki to możemy się chyba tym rzeczywiście nie przejmować. W przeciwnym razie trzeba złu zaradzić. Jeśli usuwać wstecz, to lepiej zająć się tym już dziś, bo z upływającym czasem to będzie coraz bardziej podobne do mieszania stwardniałego gipsu...
