Skocz do zawartości

Archi

Donatorzy
  • Ilość treści

    132
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    14

Archi wygrał w ostatnim dniu 12 Maj

Archi ma najbardziej lubianą zawartość!

Reputacja

66 Excellent

1 obserwujący

Ostatnio na profilu byli

608 wyświetleń profilu
  1. 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.
  2. 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ń.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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".
  11. 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.
  12. 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.
  13. 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ą).
  14. 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.
  15. 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 .
×
×
  • Utwórz nowe...

Ważne informacje

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