Wpis z mikrobloga

@outkay: Jeśli zastanawiasz się nad ofertą nazwa.pl i masz jakieś pytania, nasza infolinia działa 24/7 pod numerem 22 454 48 10, a z kodem rabatowym pe63-2792-2945 zyskasz dodatkowe 20% zniżki. Zapraszamy!
  • Odpowiedz
@outkay: To może być mylące, bo wartość metryki TTFB jest zależna od kilku czynników, o czym zresztą wspominają na tej stronie w zakładce "O projekcie":

serwer jest zbyt wolny/obciążony,

strona może być źle zoptymalizowana.

Ze swojego doświadczenia, zazwyczaj problem jest z tym drugim (Wordpress obładowany wtyczkami, z jakimś ciężkim motywem, bez zastosowanych żadnych technik optymalizacyjnych). W takiej sytuacji nawet mając szybki hosting strona będzie "zamulać", bo aplikacja będzie zajmowała sporo
  • Odpowiedz
@outkay: Zacząłbym od identyfikacji problemu, bo może serwer nim nie jest. Nazwy, Home i spółek z grup H88 (CyberFolks) i R22 unikaj jak ognia, ceny potrafią wzrosnąć kilkaset procent w ciągu roku, ceny za pierwszy rok drastycznie inne niż kontynuacja, do tego oczywiście utrudnianie jak się da migracji na zewnątrz.
  • Odpowiedz
  • 0
@januzi: @Krylan
Wordpressa optymalizowałem przez 3 tygodnie (jeszcze będąc u cyberfolks). Może po prostu mam jakąś felerną instalacje tego WP, ale po przenosinach do dhostu automatycznie zrobiło się tak 2x lepiej. Ale wciąż czasy ładowania ok 3-4 sek dla statycznych stron+woocommerce mnie niezadowalają, mimo, że już naprawdę mam poblokowane nawet JSy poszczególnych wtyczek na poszczególnych stronach (tam gdzie nie muszą być ładowane).

@theqkash
Testowałeś to webh? Spoko działa?
  • Odpowiedz
@outkay: Czy jako czas ładowania masz na myśli czas oczekiwania na zawartość html strony, nie wliczając obrazków/css/js? Jeżeli tak, to lokalnie zainstaluj xampa, wampa, albo pojedynczo apache+php+mysql. Do tego dorzuć xdebuga i ustaw go do profilowania. Skopiuj wp-contents na swój serwer (możesz pominąć podkatalog uploads) i pochodź po stronach. Xdebug wygeneruje pliki cachegrind, które możesz załadować w qcachegrind (jest wersja dla windowsa) i przeanalizować co tak właściwie zajmuje najwięcej czasu.
  • Odpowiedz
@outkay: mam tam sporo rzeczy, ale nie będę ukrywał że także współpracuję z nimi. Redisa nie mają bo do 99% witryn nie jest on potrzebny żeby działały jak należy, choć wiele firm hostingowych taką narrację wyprowadziło.

Co do skalowania 72 godziny - chodzi o to że przez 72 godziny w miesiącu możesz wykorzystać więcej zasobów niż przysługuje Ci w pakiecie jeśli chodzi o cpu i ram, czyli jakieś wykop effecty
  • Odpowiedz
via Wypiek
  • 0
@januzi wow brzmi jak dobry kompletny spsosb, czemu nigdzie indziej o tym nie mogłem przeczytać :o dzięki
@theqkash
Rozumiem, choć nie rozumiem jak wiele zasobów ma się "w standardzie" i jak wiele można zużyć podczas tego skalowania. Ile godzin zużywa ci mały - średni sklep, lub coś podobnego?
I dzięki za info z reddisem. Rzeczywiście, kiedyś się dało bez reddisa a nie wydaje mi się, żeby strony były dużo lżejsze
  • Odpowiedz
@outkay: w standardzie masz 1vCPU, 2GB RAM, możesz się natomiast rozpędzić bez problemu do 6vCPU i 8GB RAM przez te 72 godziny w miesiącu. Sądzę że bez problemu się "zmieścisz". :)
  • Odpowiedz
@outkay: No to jeszcze odnośnie qcachegrinda (jest jakiś klon stricte pod windowsa, wincachegrind czy coś takiego, ale prezentacja danych w nim ssie na maksa) to po załadowaniu pliku będziesz mieć po lewej tabelkę z danymi liczbowymi (ilość wywołań, czas własny, czas podrzędnych rzeczy) oraz graf z 3-5 elementami mającymi największy procentowy udział w czasie. Każdy element, czy to w tabelce czy na grafie, można kliknąć i zobaczyć jak wygląda sytuacja
  • Odpowiedz
@outkay: Udało mi się znaleźć zrzut ekranu. Czerwonymi prostokątami zaznaczone są elementy, które wyglądają przyjrzenia się. Unserialize i strreplace znajdowały się w środku "it get settings", które było zaszyte w szablonie i wywoływane w celu pobrania ustawień. Po małej zmianie w tej funkcji czas ładowania strony spadł z 8 sekund do trochę ponad 1s.
januzi - @outkay: Udało mi się znaleźć zrzut ekranu. Czerwonymi prostokątami zaznaczo...

źródło: xdebug

Pobierz
  • Odpowiedz
  • 0
@januzi: Dzieki za zaangażowanie! spróbuję z tym powalczyć w wolnej chwili, mam nadzieję, że mi się uda
tymczasem tak czy siak przenosze na webh, bo dla testu wrzuciłem tam backup i mimo, że nie jest ekstra, to jednak czas ładowania spadł z ~8sek do ~3sek , dzięki @theqkash !
  • Odpowiedz
@outkay super, bardzo się cieszę, ale to i tak paskudny czas i może to wynikać z zawartości witryny. Jak coś to napisz zgłoszenie na support i powołaj się na tą rozmowę to spróbujemy coś zaradzić :)
  • Odpowiedz