Popsute archiwum: popsuliśmy jeszcze bardziej
Archiwum kokpitu to jedna z pięt achillesowych naszego serwisu. Zdaję sobie z tego doskonale sprawę, że po pierwsze nie zawsze można w ogóle do archiwum wejść, a nawet, jeśli się to uda, korzystanie z niego jest bardzo niewygodne. Nie chcę wdawać się w szczegóły, dlaczego tak jest, powiem tylko, że trochę skomplikowaliśmy sprawę dzieląc je na poszczególne strony (po kliknięciu w “archiwum” serwer musi policzyć, ile wpisów macie na kokpicie, uwzględniając rozmowy publiczne i prywatne, obserwowane tagi, osoby ignorowane i mnóstwo innych rzeczy… to trwa)
Mam trzy wiadomości: dobrą i złą i neutralną :)
Dobra jest taka, że poprawienie archiwum jest naszym priorytetem. Zrobimy to, i jest to kwestia tygodni (raczej 2 niż 12 tygodni).
Zła jest taka, że musieliśmy wyłączyć archiwum. Poza tym, że było niewygodne i nie zawsze działało, powodowało bardzo poważne problemy wydajnościowe w pewnych sytuacjach. Przebite opony. Dużo przebitych opon.
Neutralna? Działa archiwum na m.blip.pl i można z niego korzystać.
Przepraszamy wszystkich Blipowiczów za te utrudnienia. Serwis rozwija się tak szybko, że czasem my za nim nie nadążamy.
Od zawsze korzystam z m.blip.pl do przeglądania archiwum, bo szybciej i sprawniej to idzie.
Niemniej jednak, życzę powodzenia w pracach nad nowym archiwum!
Felinity — 30-07-2009 @ 12:18
A nie można zrobić archiwum tak jak jest w m.blip.pl – to całkiem wygodne rozwiązanie.
Bakus — 30-07-2009 @ 12:24
zapewne w tym kierunku będziemy zmierzać.
Marcin Jagodziński — 30-07-2009 @ 12:26
Jakoś wyłączenie archiwum nie pomogło, oponek jest jeszcze więcej niż przedtem ;)
goro — 30-07-2009 @ 12:32
a ktoś jeszcze uzywał tego archiwum?
nie pamietam kiedy ostatnio działało, pomysl żeby je oprzeć na AJAX jest zły
ja podobnie jak inni korzystam z m.blip.pl
czara — 30-07-2009 @ 12:47
To może od razu format archiwum, który sprawia, że pod danym adresem jest zawsze to samo, a nie zmienia się w zależności od napływu nowych informacji?
Przykład zły: …page=5, gdzie page=1 to strona z najnowszymi wpisami. Przykład dobry: …page=505, gdzie page=1 to strona z *najstarszymi* wpisami.
Dzięki temu idąc na następną stronę w historii (w dowolnym kierunku) będę miał pewność, że nic mi nie umknęło; przy aktualnym systemie przechodząc na „sąsiednią” stronę mogę stracić tyle statusów, ile pojawiło się na kokpicie gdy czytałem stronę którą opuszczam (zakładam, że archiwum przegląda się „od trzech dni temu, kiedy byłem ostatnio online, do teraz”).
Shot — 30-07-2009 @ 12:55
Nie musicie wyłączać archiwum. Skoro problemem jest liczenie wpisów to, na czas zmiany podejścia do tej operacji, można każdemu wyświetlać maksymalną liczbę stron archiwum — co najwyżej wchodząc na fafnastą, juzer dostanie puste okienko jeżeli jest na tyle krótko by mieć mniej wiadomości.
rafamiga — 30-07-2009 @ 13:42
@rafamiga: to nie jest jedyny problem, niestety.
Marcin Jagodziński — 30-07-2009 @ 13:44
jak już jesteśmy przy naprawianiu, to dałoby się zrobić tak, by strona z błędem nie była redirectem? W ten sposób, jeżeli coś nie działa, nie mogę przeładować strony, muszę dać back, i kliknąć jeszcze raz w linka…
yacoob — 30-07-2009 @ 13:54
@yacoob: niestety, nie da się tak zrobić: ta strona generowana jest gdy serwer nie jest w stanie obsłużyć żądania. poza tym np. robienie ciągłego reload nie poprawia sytuacji. ale postaramy się, żeby tych stron po prostu nie było.
Marcin Jagodziński — 30-07-2009 @ 14:02
@Shot Spod palców mi to wyjąłeś. Właśnie takie rozwiązanie cachowania archiwum chciałem zaproponować. Wystarczyłoby nawet przechowywać trzy najnowsze strony, bo chyba rzadko kiedy zagląda się dalej, ale to już zależy od badań zachowań Blipowiczów. Albo właśnie jak @Shot sugeruje – trzymać cache archiwum od ostatniego wejścia na Blip.
tomirk — 30-07-2009 @ 16:09
Wskazówka dot. prośby @yacoob: Można sprawdzać referer, jeśli strona wywoływana jest przekazywana jako referer stronie z błędem i wstawiać przynajmniej link do niej na stronie błędu.
Zdaję sobie sprawę, że nie zawsze ref. jest przekazywany, ale przynajmniej część tych problemów z cofaniem byłaby rozwiązana. Tym bardziej, że to nie tylko o strony Blipa chodzi, ale czasem pojawia się ta plansza z błędem, gdy klika się na link zewnętrzny – po otwarciu kilku takich ciurkiem mam tylko strony z błędem bez wskazówki, która to strona wywołała.
tomirk — 30-07-2009 @ 16:16
na pewno mozna to na 100x rozwiązać, ale nie chodzi o to, zeby poprawiać stronę z błędem, tylko, zeby eliminować błędy.
Marcin Jagodziński — 30-07-2009 @ 16:18
to przeliczanie wpisow bylo niepotrzebne, i zabieralo duzo czasu. i powodowalo klopot, bo jesli w ciagu ilus tam sekund nie przyszla odpowiedz to do archiwum nie dawało się dostać. mialem nawet taki snippet js, ktory to wylaczal w cholere, ale niewygodne to było.
aha, stawiam na to, że generowało to chwilowe największe obciążenie serwerów (większe niż dręczenie api przez niektóych)
fajnie, ze to naprawiacie, bo chciałem opublikować kolejną skryptozakładkę która to “poprawiała”.
kambuz — 30-07-2009 @ 18:45
A nie możecie zrobić archiwum w statycznych plikach? To się łatwo da zrobić, a w projektach na statusie startupu nieraz tak robiłem ;)
Mało roboty, a filesystem jest bardzo szybką bazą danych… I się będzie keszować i w ogóle same zalety.
Trzeba chwilę pomyśleć nad układem linków, ale wierzę, że umiecie :)
(wiem statyka ma wady, ale sztuka kompromisu…)
robmar — 30-07-2009 @ 19:28
Czyżby reklama Blipa w Faktach TVN zupełnie go przybiła? Już dłuższy czas nie działa :-)
savka — 30-07-2009 @ 21:54
@reuptake: ależ, to *da* się zrobić :) Tylko pewnie “nie da się w tym co mamy”. To 302 naprawdę unieprzyjemnia i tak już nieprzyjemną sytuację, chociażby vide to co opisał tomirk. Łup i zamiast tego co miało być jest jakiś dziwny url. Po co to 302? Jeżeli jest tam jakiś frontend, który łapie timeouta na gadaniu z… no, z czymkolwiek pod spodem gada, to może po prostu zamiast dawać 302 do statycznej strony wyświetlić statyczną treść?
(ale tak, pewnie zaraz się dowiem że there be dragons i próba zmiany tego co tam jest skutkuje -25 do sanity co 5m pisania kodu :)
yacoob — 30-07-2009 @ 22:00
i tak sobie jeszcze myślę, żeby może napisać ludziom na kokpicie, że archiwum nie działa, bo właśnie chciałem jednemu gupkowi napisać, żeby nie pisał tysięcznego posta o tym, że archiwum nie działa w tagu #blip, tylko żeby najpierw zajrzał do archiwum, czy nie ma już setki postów na ten temat – gdy przyszło mi do głowy, że akurat tym razem…
robmar — 31-07-2009 @ 11:14
@yacoob: 302 to niewygodny ale dobry pomysł — z punktu widzenia administratora zaoranego systemu. Wiem to z autopsji. Marcinowi chodzi właśnie o to, żeby nie wciskać ciągle ^r bo zamiast pomagać — przeszkadza. Zaklikać serwis na śmierć da się — widzaiłeś to wczoraj, po #tvn….
rafamiga — 31-07-2009 @ 19:38
@rafamiga ok, czyli zakładamy że redirect to ochrona przed uzerią odświeżającą w kółko niedziałający serwis? Trudno, idę cierpieć :) (jakiś mod_limit or sth…)
yacoob — 1-08-2009 @ 23:54
http://blip.pl/s/14495322
chinskimandaryn — 8-08-2009 @ 12:20