Skocz do zawartości

Maxx

Zbanowani
  • Postów

    69
  • Dołączył

  • Ostatnia wizyta

  • Wygrane w rankingu

    3

Treść opublikowana przez Maxx

  1. Za 3,20 EUR miesięcznie w Hetznerze masz StorageBox o pojemności 1TB. Można podpiąć go/synchronizować na wiele sposobów (FTP/FTPS/SFTP/SCP/Samba/CIFS/BorgBackup/Restic/Rclone/Rsync/WebDAV/NetworkDrive) zarówno z kompem jak i jako katalog na dowolnym serwerze, dzięki czemu bez jakichkolwiek wtyczek może zastąpić folder uploads dla WP. StorageBox najlepiej wziąść razem z Cloud VPS Hetznera w tej samej serwerowni, dzięki czemu nie będzie praktycznie żadnych opóźnień a razem z VPS-em otrzymasz aż 20 TB ruchu co przy plikach po 300 MB oraz ilości zasobów ma duże znaczenie, choćby ze względu na samą indeksację przez Google. VPS-y rozliczane są godzinowo/miesięcznie (od € 3.79) i jak na profesjonalne usługi Cloud hostingu przystało - Hetzner ma API na pokładzie.
  2. Dobry administrator w cenie ~ 400-500 PLN brutto znajdzie Ci odpowiedni serwer, przeniesie wszystko, zoptymalizuje i będzie się opiekował Twoim dobytkiem online. Dzięki czemu zgodnie z Twoimi oczekiwaniami strony będą działać dużo szybciej niż poprzednio ( bo nie ma co ukrywać iż procesor który wymieniłeś jest już mocno przestarzały że już o braku optymalizacji nie wspomnę) a jedyną Twoją interakcją będzie opłacenie usługi zgodnie z Twoimi oczekiwaniami. I jest to najlepsza z możliwych opcji w opisanej przez Ciebie sytuacji która pozwoli Ci spać spokojnie a odwiedzającym Twoje strony powiedzieć: WOW - ta strona jest naprawdę mega szybka. A o wspomnianej wyżej optymalizacji mało kto ma realne pojęcie, dlatego np. blog Nazwa.pl ślimaczy się odkąd powstał pomimo użycia bardzo szybkich procesorów a reprezentujący na tym forum Nazwa.pl @itomek wciska kit, że nie może działać szybciej "bo to strona dynamiczna", choć zawartość postów nie zmieniła się od momentu ich napisania. Tymczasem Ci którzy mają pojęcie o optymalizacji np. wspomnianego WP zejdą z czasem wysłania odpowiedzi z serwera do użytkownika do kilku ms, zamiast 500 ms - czyli ponad 100 RAZY SZYBCIEJ. Więc przy właściwym wyborze możesz nie tylko sporo zaoszczędzić ale i w niższej cenie mieć znacząco wyższe standardy a tym samym wyróżnić się na tle konkurencji która będzie mogła jedynie przełykać ślinę z wrażenia
  3. Wystarczy VPS za 40 PLN z 2vCore od OVH który z tego co widzę może wykonać ponad 14,000 INSERT-ów i ponad 12,000 UPDATE-ów NA SEKUNDĘ, co w przypadku 300 osób będących jednocześnie na stronie daje realnie grubo ponad 100 KROTNY zapas zasobów, jeśli chodzi o samą bazę danych. Ponadto przez to iż na hostingach jest ograniczony dostęp do logów - w przypadku "nie sprostania obciążeniu" o którym wspomniałeś będzie trudno ustalić co stanowiło wąskie gardło a w przypadku VPS-a bez problemu można znaleźć odpowiedź w logach. Gdyż chcąc cokolwiek zmienić "na lepsze" trzeba znać przyczynę a nie działać na oślep. Gdyż dość często okazuje się, że to sam skrypt/źle zaprojektowane tabele są źródłem problemu. I dlatego to właśnie VPS będzie najlepszym wyborem pod każdym względem w tym przypadku. Ale po co robić sobie pod górkę mając tak gigantyczny zapas zasobów jeśli chodzi o bazę ? Z Redisa korzysta się tam, gdzie jego użycie ma sens, a przy 100 krotnym zapasie zasobów tego sensu absolutnie nie ma, zwłaszcza iż jeszcze musieliby przerabiać aplikację/skrypt.
  4. Tym razem tak, a co było poprzednio i jeszcze wcześniej ? A w tym roku NASK otworzył PADY 2024 już w styczniu Takie porównanie absolutnie nie ma sensu, Gdyż usługa wyszukiwania jest serwowana w czasie rzeczywistym a zapytania DNS w zależności od ustawień nawet do 24 godzin z cache. A więc aby spowodować brak działania usługi WWW przez nieosiągalność strefy pl dla 100% klientów, musiałaby nie działać ona co najmniej 1 dobę. A w przypadku usług serwowanych w czasie rzeczywistym jak przytoczona wyszukiwarka - jakiekolwiek błędy / niedostępność są natychmiast widoczne. Dlatego między innymi od Google się nauczyłem jak tworzyć projekty niewrażliwe na SPOF - czyli SINGLE POINT OF FAILURE. Dzięki czemu jakikolwiek zonk, podobnie jak w przypadku Google dotknie zaledwie mały ułamek klientów chcących skorzystać z danej usługi w danym momencie a nie 100% osób jak to zwykle jest z NASK. Ale to wyższa szkoła jazdy i dlatego bardzo mała ilość stron może się takim rozwiązaniem pochwalić.
  5. To było blisko półtora roku temu a w artykule mowa iż zauważyło to zaledwie 40,000 ludzi w USA spośród 330,000,000 czyli ~ 0.01 % i to przez krótką chwile. A to nie to samo co klęcząca usługa przez pół dnia dla 100% klientów jak w przypadku hobbystycznego rejestru NASK
  6. Ale zdarzyło Ci się osobiście to widzieć oraz zmierzyć czas ? Chodzi mi oczywiście stricte o wyszukiwarkę. Bo mi osobiście pomimo iż korzystam często i gęsto z google.com od 3 dekad ani raz nie zdarzyło się widzieć nawet 1 minutowego padu. I nie chodzi mi o inne "globalne" domeny ale stricte o google.com, którego ilość serwerów ma 6 zer. I gdyby całość działała jak hobbystyczny projekt NASK to byśmy świętowali miesięcznice padu
  7. Bo NASK to taki hobbystyczny rejestr który bardziej przypomina jakiś niesmaczny żart klęczący czasem pół dnia przy jakiejkolwiek zmianie / padzie a obsługując zaledwie 2,5 mln domen. Widzieliście kiedyś aby Google do którego spływają miliardy zapytań a wszystkie zmiany są robione w czasie rzeczywistym klęczało choć 5 min ?
  8. Google nawet nie widziało sensu stania się partnerem NASK w przypadku domen pl. I jak się okazało, całkiem słusznie - po prostu nie chciało się ośmieszać
  9. I to był ostatni dzwonek aby się wynosić ze swoim domenowym dobytkiem z Gnum, bo zazwyczaj DG przekształca się w spółkę celem jest sprzedaży. Po prostu naiwni klienci zostali sprzedani wraz ze swoimi domenami, pomimo zapewnień poprzedniego właściciela że: Niestety niektórzy dla paru groszy potrafią sprzedać nawet własną matkę a co dopiero klientów i dlatego do samego końca będą im opowiadać bajki o wspaniałym rozwoju i świetlanej przyszłości podczas gdy w tym samym czasie po cichu dobijają targu aby jak najdrożej sprzedać tych, którzy im zaufali zanim zorientują się co się dzieje. A że główną grupą odbiorczą byli seowcy, którzy sprzedają głównie obietnice - to że tak powiem - trafił swój na swojego
  10. Proponuje Ci Tomku udanie się do NASK z pytaniem w tej kwestii, ale jeszcze wcześniej sugeruję jednak sprawdzić jak się sprawy mają w rzeczywistości zamiast zaśmiecać wątek: https://dns.pl/whois i sprawdź też np. nazwa.pl abyś mógł dostrzec różnicę. A później przyjdź i po prostu powiedz "przepraszam, myliłem się"
  11. Zbyt pochopne wnioski wyciągasz bro i znów dostaniesz kolejną ocenę niedostateczną z tegoż powodu. Rzuć okiem tym razem na domenę carcode.pl a zobaczysz iż Twoje uznawanie ma się nijak z rzeczywistością (whois carcode.pl | grep dnssec) Bo nie podałem przykładu zapytania do whois abyś śmieszkował czy też się krztusił - tylko się czegoś nauczył Jeśli statystyka miała by dotyczyć ilości domen z kluczami - to absolutnie się zgadzam. Ale statystyka dotyczy domen z AKTYWNYM DNSSEC a w tym przypadku metoda @kafi jest obarczona 400 % błędem. Być może przywykliście tutaj do błędów na takim poziomie ale u mnie są one niedopuszczalne i za tak gigantyczne błędy w "badaniach" otrzymuje się niestety ocenę niedostateczną do czego wyżej się żartobliwie odniosłem
  12. Oto i więc obiecany miażdżący raport odnośnie skorzystania użytkowników Hostido.pl z łatwego włączenia DNSSEC w panelu. Sprawdzono: 6,000 domen dla równego rachunku Klucze mają: 24 domeny (dig DNSKEY nazwadomena.pl +short) Z czego podpisane w rejestrze jest: 6 DOMEN czyli JEDNA na TYSIĄC (whois nazwadomeny.pl | grep dnssec) Więc wybacz @kafi ale otrzymujesz ocenę niedostateczną za zbyt prymitywną metodologię przez którą oblałbyś test już za stwierdzenie iż "wystarczy odpytać o klucze i tyle". A żebyś nie miał żadnych złudzeń sprawdź np. domenę blazar.pl która co prawda klucze ma, ale nie jest podpisana w rejestrze podobnie jak pozostałe 17 z 24 domen. To teraz już wiesz @psz ile osób tak naprawdę korzysta z włączenia DNSSEC jednym kliknięciem w panelu mając taką możliwość. Bo szkoda abyś pozostawał wciąż w ciemnościach a co gorsza zarażał tą ciemnotą innych, podczas gdy fakty nie pozostawiają absolutnie żadnych złudzeń. A tymczasem miłego dnia
  13. Na powyższej statystyce również doskonale widać, iż po tym haniebnym i samowolnym czynie Nazwa.pl - w zaledwie rok wyłączono DNSSEC aż na 120,000 domen. Czyli ułamek z tej liczby to ludzie w miarę rozumni i coś mi mówi że to właśnie oni olali Nazwa.pl która jeszcze wtedy (czyli w 2018 roku) miała około pół miliona domen a dziś nie ma ani 1/3 z tego, jak doniosi top100.rootnode.pl Tak kończą się samowolki. A CloudFlare już stoi w kolejce, gdyż jak mówi powiedzenie: człowiek mądry uczy się na błędach innych - głupiec na swoich Praktyczny sposób sprawdzania, to jest parsowanie pliku strefy, zwłaszcza jak masz do sprawdzenia grubo ponad 200 MILIONÓW DOMEN dziennie - to życzę powodzenia z DIG Natomiast jako że DNSSEC ma dla mnie jedynie walor humorystyczny, z zapytania WHOIS (bez grep-a) wyciągniesz o wiele więcej informacji w tym również serwery nazw dla których dig klęka przy niektórych domenach. I nie ma też wątpliwości kto jest rzeczywistym rejestratorem danej domeny.
  14. Tak samo jak i Ty mam listę domen wraz z serwerami nazw, więc jednym zapytaniem do bazy wyciągam listę domen z Hostido. Co w tym takiego skomplikowanego czy też niejasnego ? PS: Natomiast ze względu na to iż informacja ta ma dla mnie tylko walor humorystyczny - ma znacznie niższy priorytet niż dużo ciekawsze zajęcia. Ale zaiste będzie to dołująca statystyka dla @psz w kwestii DNSSEC. Zwłaszcza że, zanim Nazwa.pl dokonała niezwykle haniebnego czynu, włączając DNSSEC swoim klientom bez pytania i zgody, od 2013 roku do 2017 roku DNSSEC był włączony tylko dla 40,679 domen z końcówką PL jak mówi statystyka NASK. I jeszcze ta śmieszna liczba domen (~1,6%) była rozłożona na wszystkich rejestratorów.
  15. Banalnie prosto: dig nazwa.pl +dnssec +short Tylko uważaj bo jest limit zapytań w czasie i już drugie zapytanie odnośnie tej samej domeny będzie pozbawione ostatniej linii z wszystkimi informacjami odnośnie DNSSEC. Możesz również i przez whois jeśli masz dużą liczbę IP, bo w przypadku domen PL masz ograniczenie do 100 zapytań na dobę. whois nazwa.pl | grep dnssec Więc jak już wiesz jak, to możesz mnie wyręczyć a listę domen masz wraz z NS więc nie trudno wybrać te z Hostido
  16. Zaraz to sprawdzę w logach, czy zaiste tak się sprawy mają czy brniesz w kolejną utopię. Gdyż logiczne jest, iż pomiędzy zapytaniami o czas wczytywania strony umieszczonymi na wykresach powinno znajdować się zapytanie o wielkość strony. Ponadto zadałem Ci konkretne pytanie odnośnie cytatu powyżej a z którego wynika iż powinieneś mieć w najgorszym wypadku (sprawdzając czas wczytywania zaledwie raz dziennie) co najmniej po 10 próbek odnośnie wielkości strony zarówno przed jak i po migracji zgodnie z tym co napisałeś i co zacytowałem i co znajduje się na wykresie . Zgadza się ? Również na wykresie wstawionym przez Tomka są dane z 10 dni zarówno przed jak i po migracji ale nie ma informacji odnośnie wielkości strony. Więc powtarzam moje pytanie: GDZIE SĄ TE DANE zbierane "w przerwie między kolejnymi odpytywaniami o czas wczytywania strony", gdyż od strzała widać że coś tu nie gra, zwłaszcza iż podobnie jak Tomek unikasz odpowiedzi na banalne pytanie.
  17. Czy uważasz że to jest logiczne ? Bo dla mnie logiczne jest zebranie tych informacji w jednym zapytaniu, zarówno odnośnie IP, wielkości strony jak i czasu jej wczytywania. A to że nie potrafisz sobie z tym poradzić wynika jedynie z braku doświadczenia. Co nie zmienia jednak faktu, iż rezultatem tak prymitywnej metodologii zbierania danych może być wyłącznie chaos i zamieszanie. Z tego co widzę, wykresy bazują na 10 dniach przed i 10 dniach po migracji. A więc logiczne jest iż powinieneś mieć po 10 próbek wielkości strony zarówno przed jak i po migracji zgodnie z tym co wyżej napisałeś. Moje pytanie więc brzmi: gdzie one są ? Bo starasz się powoływać na logikę, której Twoje pokrętne tłumaczenia całkowicie zaprzeczają. A jest oczywiste iż miałeś dane aby zrobić porównanie rozmiaru strony, więc proszę nie wciskaj ciemnoty użytkownikom forum, że coś tam jeszcze nie zdążyło się zrobić, bo było to wiele dni temu. No ale może masz kolejne wytłumaczenie odnośnie poruszonych kwestii - chętnie posłucham
  18. No właśnie dałeś tego przykład swoją wypowiedzią A gdy odniosłem się do konkretnej rzeczy w kwestii IPV6 oczekując konkretnego stanowiska (zmienimy/przemyślimy) to napisałeś: Więc przestań opowiadać bajki o "doceniamy", bo Twoja wypowiedź dobitnie potwierdziła iż jest dokładnie na odwrót (przynajmniej w Twoim przypadku). Nie wiem tylko czy wynikło to z braku zrozumienia tego co napisałem, czy też samej krytyki odnośnie ograniczania użytkownikowi możliwości wyłączenia IPV6 z poziomu panelu. Tak czy owak zamiast "docenienia konstruktywnej krytyki" i odniesieniu się do niej - zaprezentowałeś dno i dwa metry mułu plus nieco wcześniej odgrzałeś stary kotlet sprzed 5 lat odnośnie DNSSEC, który nie zrobił wrażenia ani na mnie a tym bardziej na Amazonie mającego od zawsze DNSSEC głęboko w zadzie podobnie jak wszyscy inni z TOP 100 Alexa. A jak wiesz CloudFlare nie gra w tej klasie i grał nie będzie, zwłaszcza po tym co tu przeczytałem. To nie koncert życzeń bro. Uderz więc najpierw do firm z TOP 100 Alexa - no chyba że nie chcesz zostać zabity śmiechem gdyż nikt z nich nie jest zainteresowany tak straszliwym dziadostwem jakim bez wątpienia jest DNSSEC. Ale z ciekawości sprawdzę, jak dużo osób skorzystało z łatwego włączenia tego dziadostwa jednym kliknięciem w przypadku Hostido.pl oferującego taką możliwość ale nie będącego tak straszliwym głupcem aby komuś włączyć go domyślnie. Oczywiście sprawdzę wyłącznie w celach humorystycznych
  19. Właśnie o tym pisałem wyżej, że w CF da się go wyłączyć jedynie poprzez API co zazwyczaj robię w pierwszej kolejności ze względu na niesłychaną mułowatość IPV6. Bo nie po to rozkładam serwery w różnych miejscach na świecie aby następnie zepsuć cały efekt przez IPV6. I dlatego jak również wyżej napisałem - jeśli tego IPV6 nie będę mógł wyłączyć to pożegnam się z CF. Nie widzę natomiast przeszkody, aby inni mogli korzystać z muła IPV6. Jeśli chodzi o IPV6 - proponuję zacząć od najbardziej zacofanej technologicznie firmy w tej kwestii - Nazwa.pl
  20. CloudFlare stara się też nachalnie i bezskutecznie promować IPV6. Więc przekaż swoim pracodawcom, że tak drobny szczegół jak wymuszanie wyłączenia IPV6 wyłącznie przez API doprowadzi w końcu do tego, iż część płatnych użytkowników Was oleje jeśli dojdą kolejne podobne wybryki (np. wymuszanie DNSSEC) a ja będę jednym z pierwszych bo nie potrzebuje tatusiów i mamusiek z CloudFlare tylko konkretne usługi. A jak wiesz, dziś na rynku jest masę alternatyw i ani opinia ani zaangażowanie CloudFlare zupełnie mnie nie interesują ani w kwestii DNSSEC ani w kwestii IPV6. A jak ktoś na siłę stara wpychać komuś swoje pomysły - zawsze kończy się to fatalnie. Więc to że wciąż jeszcze jestem Waszym klientem zawdzięczacie wyłącznie temu, że IPV6 wciąż da się jeszcze wyłączyć przez API. A jak się go wyłączyć nie będzie dało to po prostu oleje CloudFlare i tak się zakończy Wasza promocja IPV6, które przy okazji zostanie jeszcze bardziej znienawidzone. Tak więc sugeruje jednak skupienie się na core biznesu zamiast największym dziadostwie jakie przez ostatnią dekadę nie udało się przeforsować. Bo za chwile stracicie zarówno dochód jak i darmową promocję ze swoimi idiotycznymi pomysłami w zakresie IPV6 i DNSSEC. Więc moja sugestia jest następująca: jak już przekonacie te skromne 60 firm z Alexa Top 100 to wrócimy do tematu. A do tego czasu sugeruję nie drażnić klientów dziadostwem DNSSEC czy też zamulonym IPV6. PS. Wybacz więc @psz że tym razem nie było ochów i achów odnośnie CloudFlare, ale staram się być obiektywny niezależnie od tego, czy danego usługodawcę lubię czy też nie. Po prostu mojej opinii nie da się kupić ponieważ sprzedają się wyłącznie prostytutki. A na dobrą opinię długo trzeba pracować ale za to można ją stracić w kilka sekund.
  21. To właśnie ta awaria w Kylosie przypomniała mi tą w Nazwie. Tyle, że Kylos nie robi z siebie pośmiewiska tak jak Nazwa.pl która ma przypał za przypałem a rżnie lydera będąc jedynie naśladowcą i to wyjątkowo nieudolnym w niektórych kwestiach Znów straszliwe głupoty opowiadasz. DNSSEC nikogo nie zabezpieczy przed przejęciem domeny czyli domain hijacking, gdyż żeby doszło do przejęcia domeny potrzebny jest kod Auth-info. A jak ktoś ma Auth-info to dziadostwem DNSSEC można sobie tyłek utrzeć. Jeśli zaś chodzi o Twoją ostatnią deskę ratunku - czyli cache poisoning - nikt tego nie używa, gdyż nikt nie burzy muru głową jeśli ma na oścież drzwi otwarte. Dokładnie tak robi Nazwa.pl a co gorsza wprowadza użytkowników mających wszystkie drzwi i okna pootwierane w fałszywe przekonanie że ich strony są bezpieczne gdyż klucze do klatki z kanarkiem są wymieniane. Więc defacto działalność Nazwa.pl jest szkodliwa społecznie. No ale jak ktoś nie ma pomysłów na "byznes", to musi się promować przestarzałym i kompletnie bezużytecznym dziadostwem którego nie używa już nikt, kto ma choć minimalne pojęcie o wektorach ataków w sieci.
  22. Maxx

    VestaCP Wildcard

    @rakija Podeślij mi proszę na PM nazwę tej domeny dla której chcesz uruchomić wildcard, sprawdzę jak to wygląda z zewnątrz zarówno odnośnie DNS jak i tego co dzieje się z z serwerem.
  23. Kogo Ty Tomku chcesz w balona zrobić i po raz już któryś z kolei oszukać użytkowników forum ? Wszędzie są podane rozmiary strony przed i po przenosinach. Wszędzie ... za wyjątkiem Twojego przykładu. Czym tylko potwierdziłeś moje podejrzenia odnośnie "niezależności" tego "narzędzia" które również przez "przypadek" Ty wypromowałeś. https://webspeed.pl/wakacjedd.pl https://webspeed.pl/topnetonline24.pl Nie wiedziałem że upadniesz tak nisko, ale jak widać nie ma dla pracowników Nazwa.pl rzeczy niemożliwych. Bo chyba nie jesteś aż tak bezgranicznie głupi aby z 20 letnim doświadczeniem podawać przykłady kiedy nie wiesz co było wcześniej pod tą domeną.
  24. Maxx

    VestaCP Wildcard

    Z opisu wynika, iż brak jest odpowiedniej konfiguracji Nginx-a dla domeny do której chcesz dodać wildcard. Poszukaj pliku dla tej domeny w /etc/nginx/conf.d/ (np. mojadomena.pl.conf) i sprawdź czy zawiera on poprawną konfigurację dla wildcard: server_name *.mojadomena.pl mojadomena.pl; Jeśli nie, dodaj *.mojadomena.pl na początku a następnie wydaj komendę: systemctl restart nginx.service Możesz mieć dwa bloki konfiguracyjne w tym pliku dla tej domeny, jeden dla http (:80) i drugi dla https (:443). Sprawdź czy oba mają poprawną konfigurację. I daj znać czy problem został rozwiązany.
  25. Maxx

    VestaCP Wildcard

    @rakija Korzystasz z Apache czy Nginx ?
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.