Archi

Tego się można było spodziewać

Suma cen używanych podzespołów, które podałeś wyżej -10-20%. Po ceny polecam allegro, olx czy inny podobny serwis, chyba że nie sprzedajesz w Polsce, to wtedy adekwatny serwis dla danego kraju. Obecnie cena dużo lepszego komputera, który można złożyć to ok. 2000 zł wraz z obudową, więc ja bym to oszacował (bez sprawdzania cen Twoich podzespołów) na 1000-1500, i to zakładając, że ktoś się bedzie chciał w to pakować. Realnie (dla osób znających temat) ten zestaw jest warty poniżej 1000, mimo że suma cen pojedynczych podzespołów może być większa.

Logi mogą być buforowane pomiędzy write'ami (parametry buffer, open_log_file_cache), CPU ani wątków na I/O nie zużywasz, bo jest to operacja asynchroniczna. Jeśli twoim bottleneckiem jest logowanie zapytań to spierdzieliłeś konfigurację (a raczej w ogóle nie przeczytałeś dokumentacji) i optymalizujesz problem, który nie istnieje. Jakiś czas temu robiłem benchmarki do 500k requestów na sekundę statyki z włączonym logowaniem, bo akurat sam testowałem faktyczny overhead i conditional logging, i nie jestem w stanie potwierdzić tego co mówisz, tak więc jeśli masz jakieś merytoryczne wskazówki odnośnie tego co robię źle, to z miłą chęcią posłucham. A logi nie przydają się tylko jako moduł rate-limitingu, anti-bruteforce czy wykrywania zagrożeń, jest to również najlepsze źródło statystyk odwiedzin, popularnych podstron i informacji o userach, w szczególności dzisiaj gdy połowa adblocków wycina śmieciowe analytics z miejsca. Jeśli uważasz to za coś zbędnego to prawdopodobnie nigdy nie wykorzystałeś ich potencjału .

Jeśli ich księgowość ma minimum oleju w głowie to powinni odmówić z uwagi na ustawę dot. prania brudnych pieniędzy, nie można wypłacać środków pieniężnych na cudze konta przez firmy trzecie, to tak w skrócie (m.in dlatego mamy wszelkiej maści weryfikacje). Ale z racji, że nazwa robi wszystko nie tak jak trzeba, to pewnie ktoś tam przyklepie na zasadzie "no wreszcie". Nie oczekiwałbym od nich znajomości takich rzeczy, tam dział prawny jest zajęty śledzeniem użytkowników piszących niepochlebne opinie o ich firmie .

A ja nigdy nie twierdziłem, że każde rozwiązanie budżetowe będzie lepsze od dedykowanej usługi, jeśli by tak było to by wszystkie płatne rozwiązania poznikały z rynku. Jedyne co powtarzam to to, że można podobne wyniki osiągnąć we własnym zakresie, zakładając posiadaną wiedzę, czas i umiejętności. Emaillabs jest pewnie dobrą usługą dla osób, które wolą przynajmniej ten segment zlecić komuś innemu, i nie ma w tym nic złego, tak samo jak nie ma nic złego w dedykowanej administracji serwerem dedykowanym czy VPSem, przecież nie każdy wysyłający maile jest jednocześnie adminem . Jednocześnie dalej nie uważam, że takie rozwiązanie z definicji musi być lepsze, jakbym się uparł to pewnie nawet byłbym w stanie merytorycznie udowodnić testując wielu różnych providerów, że jestem w stanie wyrobić więcej dostarczalności niż oni, ale to nie są zawody, a jedynie udowodnienie, że emaillabs nie ma żadnej prywatnej specyfikacji protokołu SMTP, w której filtrowanie spamu jest pomijane, a po prostu sztab ludzi takich jak ja, którzy świadczą taką usługę odpłatnie. Mi nawet nie zależy na byciu lepszym, mi wystarczy, że maile które wychodzą ode mnie zawsze trafiają tam gdzie trzeba, a czy to jest 99.95% czy zaledwie 90% to już mi wszystko jedno, tak długo póki spełnia moje oczekiwania i jednocześnie jest tańsze niż alternatywy, bo w końcu o to chodzi. Podsumowując, bo nie odpowiedziałem na pytanie z wątku, jeśli masz wiedzę lub osoby, które są ogarnięte w temacie to taniej można osiągnąć podobne rezultaty we własnym zakresie i środowisku, ale żadne rozwiązanie nie gwarantuje 100% dostarczalności, a co najwyżej konkretną dostarczalność w obrębie testowanych providerów (i też nie do końca, bo treść maila, jego konstrukcja, nagłówki i pozostała część są co najmniej równie ważne jak serwer, z którego się wysyła, jeśli nie ważniejsze).

Ponoć "żaden inny dostawca nie ma 100%" według twojego jedynego słusznego mail testera, no to już masz dwa. Koszt powyższego rozwiązania: 4 zł na miesiąc za IP (które ma jeszcze inne zadania), chyba że liczysz jeszcze najtańszego VPSa, który uciągnie wysyłkę maili, no to będzie może z dyszka . Nie wiem co test wyżej ma potwierdzić, ale skoro mi rzuciłeś wyzwanie to proszę bardzo.

Nigdzie nie napisałem, że dedykowany IP zastępuje ludzi i umowy z providerami. Napisałem, że dedykowany IP z odpowiednim środowiskiem jest w stanie działać porównywalnie lub nawet lepiej do emaillabs, jednocześnie kosztując ułamek jego ceny, z racji że sam IP to koszt ok 4 zł netto na miesiąc. Jestem w stanie zbudować takie środowisko (a nawet już takie mam na produkcji), i o ile ciężko mi oszacować procentową dostarczalność maili, tak nigdy nie miałem informacji o żadnej zwrotce, wylądowaniu w spamie czy zagubieniu, i w pełni uważam, że wszystko co oferuje emaillabs jesteś w stanie osiągnąć samemu, zakładając że wiesz co robisz. Oferta dedykowanych providerów do poczty niczym się nie różni od oferty zarządzanych VPSów czy dedyków. Próbujesz mi udowodnić, że serwer WWW postawiony na dedyku przez profesjonalnego administratora, z usługą kosztującą 999 miesięcznie musi być z definicji lepszy od dedyka, którego postawię sam, a prawda jest taka że nie dość, że jestem w stanie postawić identyczny w cenie 200 zł na miesiąc, to jeszcze i lepszy. Tutaj jest bardzo podobnie, i jedyny argument jaki w ogóle możesz podnieść to właśnie umowy z partnerami, które w pełni rozwiązuje długofalowa reputacja danego IP jako serwera SMTP, i jest czasem nawet wyżej punktowana niż whitelisty, właśnie z tego powodu, że w przypadku emaillabs każdy może zapłacić i zacząć wysyłać spam, a do mojego serwera dostęp mam wyłącznie ja sam. Polecam zobaczyć jak te umowy i whitelisty wyglądają w praktyce, to zobaczysz że jest to wyłącznie wyższy score w ogólnym zestawieniu, a nie żadna biała lista 100% dostarczalności (które nie istnieje, jak już omówiono powyżej). Umowa polega na wzajemnym informowaniu siebie i punktowaniu, a nie na żadnym "dobra to my puścimy wszystko od was i załatwione". Co więcej Ci powiem, nie zastąpiłbym swojego rozwiązania Twoją usługą emaillabs nawet gdyby kosztowała tyle samo, właśnie dlatego że mam pewność co do historii mojego IP, jego rejestracji oraz użycia, czego nie mogę powiedzieć o firmie, która będzie nad tym czuwać w moim imieniu. Wystarczy, że jeden użytkownik kiedyś wysłał spam z emaillabs (i to zupełnie innego IP), i już w tym momencie ma rekord gorszy niż mój serwer, który spamu nie wysłał nigdy, a historia wzajemnego zaufania sięga lata wstecz. I dlatego usługi takie jak emaillabs istnieją, tak samo jak serwery dedykowane z administracją czy zarządzane serwery VPS. Problem zaczyna się wtedy, kiedy próbujesz wmówić doświadczonym, dedykowanym administratorom i developerom, że Twoje rozwiązanie jest najlepsze, powołując się na ładny obrazek, zapewnienia firmy i statystyki z czapy, zamiast na wartości merytoryczne, które punktuje ja. To tak jakby nazwa.pl napisała, że ma najlepszy krajowy system do rejestracji domen, no bo przecież ma najwięcej zarejestrowanych .plek w Polsce. Emaillabs to usługa jak każda inna, i nie jest w stanie w żaden sposób wspiąć się powyżej własnych, dedykowanych, często autorskich rozwiązań, a co najwyżej zrównać się z nimi i oferować względnie dobrą usługę za odpowiednią cenę. Jeśli nie masz doświadczenia, możliwości lub pieniędzy stworzyć takiego sam, lub po prostu jest Ci emaillabs na rękę, to nikt tutaj nie będzie się z Tobą kłócił, bo nie wątpię że są w stanie robić swoją robotę dobrze, ale nie zapędzaj się ze stwierdzeniami niższości własnych rozwiązań, chyba że masz merytoryczne argumenty i doświadczenie, które z miłą chęcia mogę zweryfikować z własnymi.

To polecam tylko żyć w swoim świecie, bo widocznie wszyscy się zgadaliśmy, że będziemy na forum bullshit wypisywać .

Emaillabs z dedykowanym IP nie gwarantuje Ci, że wczoraj z tego samego IP nie wysłałem setki spamu. Nawet jak podepniesz swoje własne IP to również nie gwarantuje, że wczoraj z tego samego IP nie wysłałem niechcianego mailingu, przed zwróceniem go do odpowiedniego ISP. Poczta ze 100% dostarczalnością nie istnieje, można jedynie wyposażyć się w dedykowany adres IP i o niego dbać, a dbanie o niego to posiadanie go przez kilka dobrych lat i upewnienie się, że żaden spam z niego nigdy nie wyjdzie. Pewnie, są firmy które w Twoim imieniu dbają o własne adresy, i dlatego takie emaillabs może mieć wyższe współczynniki dostarczalności niż losowy shared hosting z brzegu, ale to wciąż nic nie gwarantuje, a jedynie zwiększa szansę. Jak @patrys napisał wyżej, własne środowisko, własne IP i własne rozwiązania mają największą skuteczność, ale reputację się buduje latami, a nie w jeden dzień. Nawet 100% czyste dopiero co zarejestrowane IP nie daje żadnej gwarancji, a raczej właśnie takie z dużą ilością zaufanych maili, które były wysyłane i weryfikowane przez ostatnie lata. Ja osobiście stosuje mix, i mój SPF ma zadeklarowane kilka serwerów, które są uprawnione do podpisywania się daną domeną, a serwer z którego wychodzi mail jest niejako powiązany z jego ważnością i źródłem, przy czym wszystkie serwery są trzymane na najwyższym poziomie (ale jednocześnie jest oczywista różnica między np. SMTP dla całej firmy, a SMTP tylko dla dyrekcji).

Prawidłowym rozwiązaniem jest nie używać w ogóle CURLOPT_FOLLOWLOCATION, a zamiast tego poprawić swój kod, żeby nie używał linków, które redirectują 3xx (co nie jest zbyt bezpieczne jeśli mowa o wykonywaniu requestów curlem). Jeśli dhosting chce używać open_basedir'a (co jest wskazane), to jest to w zasadzie jedyna słuszna opcja. safe_mode jest deprecated od bardzo dawna i wątpię, żeby ktokolwiek go jeszcze dzisiaj używał, nie wspominając nawet o tym, że od PHP 5.4 w ogóle go nie ma.

Zależy co konkretnie chcesz ograniczać, bo ograniczenie pamięci dla poola PHP osiąga się zupełnie inaczej niż ograniczenie limitów na całego usera. Jak usługa, to warto najpierw pogrzebać w niej samej i sprawdzić czy ma jakieś ustawienie, które osiągnie to co chcesz. Jeśli nie, możesz zastosować cgroups z limitami per proces, które działa bardzo fajnie i sprytnie. Jeśli chcesz limitować całego usera czyli wszystkie jego procesy, to raczej ulimits, chociaż cgrupy również się sprawdzą. CPU nie polecam w żaden sposób ograniczać, a raczej odpowiednio ustawić priorytety i depriorytetyzować userów. Jednak jeśli chcesz, to polecam znowu cgroups, ewentualnie cpulimit, ale do niego mam sporo technicznych zastrzeżeń.

To też zauważyłem. Generalnie nie uważam tego za złe biorąc pod uwagę, że sztucznie nie ograniczają, a jedynie dowalają oszczędność mocy jak tylko mocno się da, ale faktem jest że każdy świadomy administrator pierwsze co powinien zrobić to albo wywalić to jądro całkowicie, albo zrekompilować pod siebie, bo części z tych opcji podczas runtime'a nie ruszysz.

Kompilacją nie benchmarkuje się ani CPU and I/O z powodu niejednoznaczności kompilowanych źródeł, użytego kompilatora oraz maści czynników trzecich. Benchmark CPU czy I/O dokonuje się programami do tego służącymi, które używają tych samych kryteriów aby wygenerować sensowny wynik. GCC, który na jednym CPU użyje instrukcji SSE 4.2 żeby przyspieszyć proces translacji kodu źródłowego na binarny, a na drugim AVX2 nie jest obiektywne i w żaden sposób nie przekłada się na rzeczywistą wydajność obydwu maszyn w starciu z np. ilością requestów na sekundę nginxa. Więc nie, jeśli robisz benchmark maszyny przez puszczenie kompilacji php to robisz to źle i nie masz zielonego pojęcia o zasadzie działania benchmarków i czym się różni benchmarkowy test od kodowania wideo, obsługi requestów na socketach czy kompilacji właśnie. Jak chcesz się kurczowo trzymać swojego przykładu z samochodem to w tym momencie stwierdzasz, że samochód który maksymalnie jedzie 200 km/h jest szybszy od tego co ma na liczniku 190 km/h, a to że pierwszy dobija do dwusetki w 5 minut i przejedzie krótszy dystans w ciągu minuty niż drugi, który dobija do 190 km/h w 3 sekundy już całkowicie ignorujesz, bo nie patrzysz na żaden inny współczynnik ani sam fakt, że maksymalna prędkość może nie mieć nic do gadania w sytuacji, gdy test trwa 3 sekundy i nigdy jej nie uświadczysz. I właśnie taką zasadniczą różnicą jest np. wielkość cache L1/L2/L3 w CPU, który w kompilacji odgrywa znacznie większą rolę niż w wykonywaniu kodu już skompilowanego. To, że jedna maszyna radzi sobie lepiej z A nie oznacza, że jednocześnie radzi sobie lepiej z B, i to nawet porównując kompilację dwóch różnych projektów, a co dopiero kompilację z zupełnie innym zadaniem.

Ja już od dawna jadę na oficjalnym kernelu dystrybucyjnym, czasem jeszcze na własnym. Kernel od OVH ma zbyt dużo generycznych śmieci, które są ładowane w każdym wypadku. Zakładając, że twoja maszyna potrzebuje 30% kernela, w kernelu debiana załaduje się core 5% bez którego kernel w ogóle działać nie może, a pozostałe 25% dociągnie się z modułów, gdzie w kernelu ovh na siłę leci 40% czy Ci się to podoba czy nie, bo wszyscy w OVH boją się modularnego kernela jak ognia. W efekcie końcowym nie tylko jesteś podatny na o wiele więcej bugów niż zwykle (bo każda linijka kodu ma szanse na konflikt), ale sam kernel działa dużo wolniej i potrzebuje więcej pamięci bo ma na twardo załadowane co najmniej kilkadziesiąt modułów, które na twojej aktualnej maszynie do niczego nie są używane.

KVM nie jest potrzebny do niczego mając tryb rescue. Administrator który zna się na swojej robocie wie o istnieniu takich rzeczy jak /proc/last_kmsg (ew. pstore) i nie potrzebuje bezpośredniego dostępu do konsoli. I to zakładając, że chcesz znać przyczynę problemu, bo zwykłe "kernel nie wstaje" załatwia grub fallback.

Jeśli bottleneckiem jest I/O to warto rozważyć fs, który oferuje natywnie kompresję, ZFS będzie bardzo dobrym wyborem pod storage, i kompresję również oferuje.

Punkt 2 w dużej mierze zależy od firmy/osoby zajmującej się tym serwisem. Jeśli jest to znak towarowy to sądownie można rządać zdjęcia Twojej domeny. Do tego dochodzi jeszcze sporo artykułów z zakresu zwalczania nieuczciwej konkurencji, w tym przede wszystkim w tym wypadku podszywanie się pod daną markę w celu wprowadzenia klienta w błąd. Nie sugerowałbym pójscia w tym kierunku, nawet jeśli Twój serwis nie byłby powiązany w żaden sposób z oryginalnym, a zajmowanie się dokładnie tym samym, o ile nie masz naprawdę dobrych argumentów na swoją obronę, może być bardzo łatwo potraktowane jako próba wyłudzenia. Oczywiście decyzję może wydać wyłącznie sąd i zdarzały się co najmniej "dziwne" wyroki w tych kwestiach, ale na ogół powinieneś się starać uniknąć problemów, a nie tworzyć z nadzieją, że nic z nich nie wyniknie, przynajmniej z biznesowego punktu widzenia.

W zależności od wymagań i oczekiwań, PHP nie musi być wymagany. Sam ostatnio odkrywam ile rzeczy potrafi zrobić webpack z vue, i tak długo póki nie wchodzimy w tematykę baz danych i klasycznej wizji strony internetowej, tak długo można naprawdę sporo osiągnąć statycznym kodem generowanym dynamicznie w oparciu o bardzo skomplikowane czasem źródła.

Też korzystam z keepassa - mając trochę umiejętności jesteś w stanie bez problemu zrobić sobie własną chmurę synchronizując bazę z hasłami tam gdzie trzeba. Do tego jest sporo dodatków, które automatycznie łatają niewygodne dziury (mam tu na myśli przede wszystkim chromeipass dla chrome'a i chromium), przez co jest to bardzo fajne, otwarto-źródłowe rozwiązanie, całkowite niezależne od czegokolwiek i oferujące Ci wybór na ew. rozszerzenia we własnym zakresie. Nic nie stoi na przeszkodzie w używaniu keepassa np. z nextcloudem, wraz z apką na androida. Na pewno mam większe zaufanie do takiego rozwiązania niż do czegokolwiek "online".

Zbyt dużo zależy od domeny. Nie wyobrażam sobie jakiegoś portalu informacyjnego na czymś pokroju x7z.pl i na ogół domeny z liczbą są dość rzadko spotykane, żeby nie powiedzieć, że w ogóle. Wyjątkiem jest nazwa jakiegoś brandu lub sama firma, bo tutaj domena jest tylko odnośnikiem po więcej informacji, a nie własnym niezależnym serwisem (np. h88.pl). Są jednak domeny gdzie cyfra na początku, albo na końcu nie robi aż tak kolosalnej różnicy, ale chyba nadal uważam, że o wiele lepiej tego unikać - jakiekolwiek pozycjonowanie czy budowanie marki/brandu na czymś takim jest o ile nie skazane na porażkę, to na pewno mocno pod górkę w stosunku do innych.

Polecam postawić sobie jakiś prosty panel do zarządzania subdomenami, czasy gdy z palca się robiło configi nieco odeszły już do lamusa. ISPConfig świetnie współgra z nginxem, korzystam i sobie chwalę. Wszystkie regułki możesz sobie wpisać do panelu, a i sporo rzeczy masz z automatu, chociażby certyfikaty LE. Sam nie przepadam za większością paneli hostingowych, a niektóre z nich (np. VestaCP) powinno się wręcz wymazać z historii. M.in dlatego lubię ISPConfig, bo nadal masz pełną kontrolę nad tym co panel ma robić, a co chcesz robić manualnie, więc pomagasz sobie tam gdzie chcesz, a nie tam gdzie musisz. Jest to też jeden z niewielu paneli, który działa dosłownie z każdą, nawet najbardziej egzotyczną konfiguracją, w tym z moją produkcją na debianie testingu opartej właśnie o nginxa. Zero problemów.

Rzeczywiście trudno będzie znaleźć coś taniej i lepiej niż aruba, przynajmniej za tę cenę. Oczko wyżej będą najtańsze kimsufi, ale to już koszt co najmniej 20 zł / mc, co najmniej czterokrotnie więcej, więc jeśli będzie działać OK to nie ma sensu zmieniać (sam nigdy nie testowałem jak u nich ze stabilnością).

GZIP na ogół działa na plikach tekstowych gdzie możesz osiągnąć kompresję wynoszącą ułamek pliku docelowego - w przypadku perfekcyjnie kompresowalnych danych rzędu 1/1032. Nawet z przeciętnymi plikami html jesteś w stanie bez większych problemów osiągnąć od 1/5 do 1/20 rozmiaru docelowego. Samo przesłanie tych danych może kosztować Cię więcej niż ich skompresowanie, i jak najbardziej mówię tutaj o CPU na transmisję TCP - wyliczanie sum kontrolnych pakietów również swoje kosztuje. Użycie gzip -1 na dobrze kompresowalnych plikach (text/html, text/css, text/plain, application/javascript itp) niemal zawsze poprawia lub przynajmniej zrównuje wydajność zarówno po stronie użytkownika jak i serwera. Nie ma żadnego logicznego powodu na rezygnowanie z kompresji dobrze kompresowalnych plików, musiałbyś serwować miliony plików o wielkości pojedynczych bajtów, żeby koszt ich kompresji przewyższył ich przesył. Jak ostatnio sprawdzałem benchmarki to już przy 130 KB (skompresowanych do ~13 KB) plikach gzip się zrównuje z CPU na TCP. Do tego poza samym CPU dochodzi Ci jeszcze koszt przesłania tych danych, odebrania ich po drugiej stronie i sparsowanie - coś co również będzie o wiele szybsze po stronie klienta gdy odbierze 13 KB i zdekompresuje niż sparsuje pełny ciąg 130 KB.

Nie zapominaj o "pomyłkach systemu" i dostawaniu nieprawidłowych kodów authinfo, które co najmniej kilku użytkowników zgłaszało w przypadku nie tylko tej firmy .

TLS 1.3 prawdopodobnie rozwiąże ten problem. Poza tym w wielu przypadkach (np. Cloudflare) w żaden sposób nie identyfikuje to końcowej strony.