różności

by aljandor on Dump Links, różności, Web

Dump links #8

Zebrało się kilkanaście linków, więc pora kliknąć „opublikuj”.

  • SERWER kafli leaflet https://github.com/klokantech/tileserver-php
  • logowanie beledow z php: http://filp.github.io/whoops/
  • ikony sociali w bootatrap: https://lipis.github.io/bootstrap-social/
  • https://devhints.io/
  • hosting w chmurze: https://zeit.co/
  • https://skyvector.com/
  • https://github.com/dg/rss-php -> RSS czytnik 
  • https://jvns.ca/blog/2019/08/27/curl-exercises/ cURL
  • Jak pisać w nowoczesnym JS: https://dev.to/chrisachard/es6-mini-crash-course-javascript-can-actually-be-fun-to-write-3b9l
  • Amerykański slang korporacyjny: http://alumni.media.mit.edu/~guy/american/
  • ciekawy progress bar: http://ricostacruz.com/nprogress/
  • Jak robić dobre code review: https://google.github.io/eng-practices/review/reviewer/
  • https://blog.jooq.org/2019/09/19/whats-faster-count-or-count1/
  • Ciekawy przewodnik po sekcji <head>: https://htmlhead.dev
  • Debugowanie DNS: https://blog.dnsimple.com/2017/08/debugging-dns/

 

 
by aljandor on Aljandor, Bez kategorii, ISS, PHP, Projekty, różności, Serwisy, Statystyki, Web

Podsumowanie roku 2018

W mijającym już roku 2018 prężnie rozwijały się nasze aplikacje… Dla niektórych z nich trzeba było przygotować dodatkową infrastrukturę, a niektóre z nich przeszły gruntowną reorganizację infrastruktury (przykładowo aplikacja z serwera shared została migrowana na infrastrukturę rozproszoną pracującą na dwóch VPS, a w „sezonie” na trzech + loadbalancer). Wszytko za sprawą ruchu, który z dnia na dzień z 0,5 req/sec urósł do 15 req/sec, a w sezonie do 25 req/sec…

Poniższe screeny pokazują skalę gwałtownego przyrostu – i ciągle rośnie 🙂 

Pushe odbierane przez klientów.

 

Sesje w porównaniu do 2017 roku… w roku obecnym 2k sesji dziennie 🙂

 

Inne aplikacje również doświadczyły sporych zmian, część z nich została migrowania na WP 😉

Rok 2018 kończmy dość dobrze, oby 2019 nie był gorszy!

 

EDIT: 

czy udało się zrealizować plany częstszych  postów (https://aljandor.ovh/blog/nowy-rok-nowe-plany/) ? Chyba tak, choć w 2019 na pewno będzie ich więcej (więcej konkretów!) 🙂 

 
by aljandor on Aljandor, Prace serwisowe, Projekty, różności, Serwisy, Web

Prace serwisowe, okna serwisowe – jak je robimy

Jakiś czas temu pisaliśmy o deploymencie – jak je robimy (https://aljandor.ovh/blog/deployment-jak-je-robimy/). Dziś napiszemy o pracach serwisowych.

Okna serwisowe przeprowadzamy zazwyczaj w nocy (wtedy jest najmniejszy ruch na serwerach). Termin prac serwisowych planujemy conajmniej dwa tygodnie wcześniej. 

Gdy planujemy okno serwisowe dla konkretnej usługi bierzemy pod uwagę wiele czynników. Pierwszym z nich jest ruch – w jakich godzinach jest najmniejszy? Drugim czynnikiem jest możliwość przełączenia na zapasowe środowisko (blue / green). Cześć najwyżej infrastruktury posiada refundowane środowiska produkcyjne  – przeprowadzanie prac na takiej infrastrukturze jest mniej bolesne 🙂

Powyższy wykres przedstawia odwiedziny użytkowników jednej z aplikacji. Prace 

 

 
by aljandor on Aljandor, Kontrola wersji, PHP, PostgreSQL, Projekty, Python, różności, SQL, Web

Deployment – jak je robimy?

Zależnie od inftastruktury aplikacji, jej architektury zawsze planujemy deplyment tak aby był jak najmniej uciążliwy dla użytkownika końcowego systemu. Często nasze stsytemy aktualizujemy podczas nocnych okienek serwisowych. I tak jedna z aplikacji, która ma 20, a w sezonie 30-40 req/sec jest aktualizowana głównie poza sezonem. W trakcie szczytu, gdzie dziennie jest kilkadziesiąt tysięcy wizyt przeprowadzamy jedynie krytyczne poprawki – jeśli są niezbędne do prawidłowego oraz stabilnego działania systemu.

Poza sezonem aplikacja jest aktualizowana we wtorki oraz czwartki, w godzinach 16-18. Zmiany są przygotowywane oraz testowane we wcześniejszym tygodniu. Jeśli trwa sezon, utrzymuje się spory ruch, deployment przeprowadzamy jedynie w nocnych oknach serwisowych – które zaczyna się od 1 w nocy, a kończy o 3 rano.

Każde z wdrożeń niezależnie od pory jest możliwe do cofnięcia w krótkim czasie. Jeśli aktualizujemy większa aplikacje często przepinamy ruch na czas wdrożenia na zapasowe środowisko produkcyjne (które jest w stanie przejęć 100% ruchu w razie problemów z głównym środowiskiem) tak aby zminimalizować ryzyko down time (metoda Blue-Green).