Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Mógłbym prosić i fix'nięcie tego RSS co jest na forum? Bo tutaj jest jakiś skrypt php i sporo klientów RSS tego nie potrafi przetwarzać (chce pobierać ten skrypt php), no a te co już potrafią, to łapią laga i odświeżają RSS raz na parę godzin i nigdy nie udaje się uzyskać nowej treści przy ręcznym wymuszeniu ich pobierania. xD
Offline
Faktycznie coś nie funguje:
time curl -v https://forum.dug.net.pl/rss.php ... real 0m24,422s ...
Trochę długo ten skrypt mieli.
Quiterss nie potrafi przez to kanału dodać, wywala timeout.
Offline
Ja mam tak wrzucone: https://forum.dug.net.pl/extern.php?action=active&type=RSS i to działa. Może bana dostałeś ;)
Offline
Melduję posłusznie, że oba powyższe posty Akregator (ten z KDE) pokazał z całą treścią, ciągnie feeda z adresu:
https://forum.dug.net.pl/rss.php
Więc radziłbym popełnić małą diagnostykę sieciową, cokolwiek miałoby to znaczyć. :P
Ostatnio edytowany przez Jacekalex (2021-04-06 09:51:23)
Offline
Zerkam więc tak spowalnia zapytanie
gdzie bez sortowania wykonuje się 0.0014 a z 10.0126 s (typ sortowanego pola to int)
w postgresql jest na to rozwiązanie szukam alternatywy dla mysqla
dodanie indexu zwiększenie pamięci query_cache_size i sort_buffer_size nic wiele nie daje
po optymalizacji tabeli punbb_posts czas zapytanie spadł do 5.9554 s
dalej nędza ktoś ma jakiś pomysł, ja na codzień korzystam z Postgresa mysql tylko tutaj
Offline
BiExi napisał(-a):
Zerkam więc tak spowalnia zapytanie
gdzie bez sortowania wykonuje się 0.0014 a z 10.0126 s (typ sortowanego pola to int)
w postgresql jest na to rozwiązanie szukam alternatywy dla mysqla
dodanie indexu zwiększenie pamięci query_cache_size i sort_buffer_size nic wiele nie daje
po optymalizacji tabeli punbb_posts czas zapytanie spadł do 5.9554 s
dalej nędza ktoś ma jakiś pomysł, ja na codzień korzystam z Postgresa mysql tylko tutaj
Jeśli chodzi o optymalizację to mysql/mariadb ssie potwornie.
Generalnie, standard tabel sql zakłada że dotning ( ilość rekursywnie nasłanych SAR ) automatycznie przechodzi przez optymalizator, ale różne zjeby uważające się za wszystkowiedzących sprawiły że standard ( kiedyś naprawdę super ) poszedł się *
I tak dobrze że udało się zoptymalizować do okolic 5.
Offline
BiExi napisał(-a):
Zerkam więc tak spowalnia zapytanie
gdzie bez sortowania wykonuje się 0.0014 a z 10.0126 s (typ sortowanego pola to int)
w postgresql jest na to rozwiązanie szukam alternatywy dla mysqla
dodanie indexu zwiększenie pamięci query_cache_size i sort_buffer_size nic wiele nie daje
po optymalizacji tabeli punbb_posts czas zapytanie spadł do 5.9554 s
dalej nędza ktoś ma jakiś pomysł, ja na codzień korzystam z Postgresa mysql tylko tutaj
mysqltuner żadnych sensownych porad w zakresie Mariadb nie podpowiedział?
Proszę nie brać tego za złośliwość, ale z pośród kilku znanych mi skryptów forumowych taki numer z powolnym zapytaniem tabeli widzę pierwszy raz.
Może PunBB domaga się emerytury solidniejszej, niż ta z ZUS?
:P
Albo po prostu tabela z postami osiągnęła o wiele za duży rozmiar, jak na możliwości PunBB.
Wielka Aktualizacja Forum była kiedyś planowana, ale...
"Planujący wyparowali".
Ostatnio edytowany przez Jacekalex (2021-04-09 10:17:18)
Offline
Jacekalex napisał(-a):
Wielka Aktualizacja Forum była kiedyś planowana, ale...
"Planujący wyparowali".
Kogo dokładnie masz na myśli?
mysqltuner zostawia po sobie mega syf. Odradzam.
Offline
Wiem że PunBB to staruszek tutaj problem tkwi w tym że pasowało by zrobić migracje na coś innego.
Co do rozmiaru bazy ro nie jest ona jakoś specjalnie opasła, podejrzewam bardziej o to że wydajność vps jest za niska
Sprawdzę jak ta baza się zachowa na lepszym sprzęcie
Offline
Jeśli szykuje się zrzutka na nowy serwer, to ja 100-150zł mogę dorzucić.
PunBB niby staruszek, ale mnie się DUG bardzo ładnie ładuje - ciekaw jestem jak przy migracji na nowocześniejsze BB wydajność stron będzie wyglądała :)
Offline
Można też zrobić inny sposób.
Sznurek do rssa np:
https://forum.dug.net.pl/feed/feed.xml
A sam feed.xml jest generowany np co godzinę z crona, także przy np 20 klientach RSS robotę robi raz, a nie 20 razy.
Dokładnie tak samo działają wszystkie feedproxy od Googla czy Cloudflare.
Samo pobranie pliku feed.xml trwa tyle, że nawet przez połączenie GPRS czy nawet modemowe 28kbit pójdzie wystarczająco szybko dla Quiterss.
xD
Dokładnie tak samo pracują wtyczki do sklepów internetowych typu ceneo czy skąpiec.
Na małego VPSa będzie jak znalazł bez żadnych wielkich czarów.
Co do problemów z Quiterss, to jak komuś nie przeszkadza zasysanie 3/4 KDE, to polecam Akregatora, radzi sobie dobrze z kulawym RSSem w obecnej formie.
Ostatnio edytowany przez Jacekalex (2021-04-09 13:07:12)
Offline
Ja mam takie nietechniczne pytanie, co to znaczy, że MySQL ssie? I to potwornie?
Offline
Jacekalex napisał(-a):
zasysanie 3/4 KDE
I to mnie w debianie wkurza.......... zaciąganie pierdyliarda zbędnego syfu........
Jak ja nie znoszę KDE.............
Offline
developer napisał(-a):
Jacekalex napisał(-a):
zasysanie 3/4 KDE
I to mnie w debianie wkurza.......... zaciąganie pierdyliarda zbędnego syfu........
Jak ja nie znoszę KDE.............
Znosić to może conieco kura albo kogut, kiedy schodzi po drabinie. :P
Obecna Plasma jest dosyć fajna, biblioteki z kde-frameworks są dość lekkie.
Kłopotem Akregatora jest biblioteka Qtwebengine, która zawiera w brzuchu przeglądarkę Chromium.
Co jednak nie zmienia faktu, że u mnie Akregator zajmuje (RAM):
65.2 MiB + 36.2 MiB = 101.5 MiB QtWebEngineProcess (5) 199.7 MiB + 22.1 MiB = 221.8 MiB akregator
i trzyma kanały RSS w plikach tekstowych.
Gdy na takiej liście kanałów jak u mnie odpalałem Quiterss czy Lifereę, które używają bazy Sqlite, to na dyziu magnetycznym miałem kuźnię, że uszy puchną.
Do tego Quiterss, jak go ostatnio widziałem, potrzebował (oprócz osobnej partycji na SSD),
2 GB RAM, do czego? pojęcia nie mam, jego baza SQLite miała około 400 MB.
Trochę lepiej wypadał RSSGuard który gada z Mysql, ale też miał swoje wady, np niektórych kanałów nie pobierał w ogóle.
Także czy inaczej wróciłem do Akregatora, kiedy tylko ustabilizowała się jego sytuacja po migracji z Qtwebkit na Qtweengine.
:P
Pozdro
Ostatnio edytowany przez Jacekalex (2021-04-09 19:29:37)
Offline
Quiterss i kde, bez przesady:
$ aptitude show quiterss .... Depends: libc6 (>= 2.14), libgcc-s1 (>= 3.0), libqt5core5a (>= 5.12.2), libqt5gui5 (>= 5.8.0) | libqt5gui5-gles (>= 5.8.0), libqt5multimedia5 (>= 5.6.0~beta), libqt5network5 (>= 5.4.0), libqt5printsupport5 (>= 5.0.2), libqt5sql5 (>= 5.10.0), libqt5webkit5 (>= 5.212.0~alpha3), libqt5widgets5 (>= 5.12.2), libqt5xml5 (>= 5.0.2), libsqlite3-0 (>= 3.6.11), libstdc++6 (>= 5), libqt5sql5-sqlite
Widzicie tutaj jakieś zależności od KDE, bo ja ni. xD
Co do zużycia RAM:
262.6 MiB + 12.1 MiB = 274.8 MiB 0.0 KiB quiterss [663674]
Jakby nie patrzeć ja go też wykorzystuję jako przeglądarkę (zasysa m.in. obrazki), no i też mam xxx kanałów ze sporą historią wpisów.
U mnie baza zajmuje 128M ale ja naprawdę mam sporo tego złomu na RSS. Chyba powinienem jaką optymalizację włączyć. xD
Offline
Debian jeszcze ma Qtwebkit?
Po tym, jak developerzy QT zapowiedzieli pożegnanie webkita, z Gentoo wyleciał w kosmos.
Z pozdrowieniami dla Quiterss:
https://doc.qt.io/qt-5/qtwebenginewidgets-qtwebkitportingguide.html
EDIT:
Już przeczytali:
INSTALL napisał(-a):
QuiteRSS requires Qt version 5.9 or higher
Required Qt libraries:
QtQml
QtQuick
QtWebEngine
Sznurek:
https://github.com/QuiteRSS/quiterss2/blob/master/INSTALL
xD
Ostatnio edytowany przez Jacekalex (2021-04-09 20:38:34)
Offline
Akregator w TDE zajmuje 130 M i pobiera komentarze z forum duga - przed chwilą sprawdziłem. Kanały rss od zawsze mam skonfigurowane na thunderbirdzie i tu mam na obecną chwilę 310 M. Kilka kont email + rss na icedove/thunderbird chodzi bezproblemowo mniej więcej od 2012 roku. Pozdrawiam
Ostatnio edytowany przez Andrzej66 (2021-04-10 20:07:20)
Offline