Dump links #30

Tym razem okrągły dump, bo #30. 

  • https://dennylesmana.medium.com/what-is-database-caching-ceebe57de9ba
  • https://brandur.org/fragments/postgres-table-rename
  • https://dmarc.postmarkapp.com/
  • https://www.postgresql.org/docs/current/sql-merge.html
  • https://mailcatcher.me/
  • https://github.com/mailhog/MailHog
  • https://codeception.com/12-15-2013/testing-emails-in-php.html
  • https://tria.ge/login
  • https://jolicode.com/blog/how-to-dynamically-validate-some-data-with-symfony-validator
  • https://archiv.pehapkari.cz/blog/2017/02/24/symfony-validator-dynamic-constraints/
  • https://austingil.com/automatically-deploy-from-git/
  • https://chenhuijing.com/blog/understanding-browser-cookies/
  • https://wcedmisten.fyi/post/self-hosting-osm/
  • https://www.crunchydata.com/blog/postgres-query-boost-using-any-instead-of-in
  • https://www.postgresql.org/docs/current/sql-merge.html
  • https://cachethq.io/
  • https://dencode.com/
  • https://hazelweakly.me/blog/scaling-mastodon/
 

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!) 🙂 

 

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).

 

PHP7 ma potencjał !

Niedawno mieliśmy okazję migrować aplikację pracującą pod PHP w wersji 5.6 na PHP 7. Jest to aplikacja średnia (dostaje max 10 req na sekundę) i UU na poziomie 10k / mc.
Z uwagi na to iż warstwa prezentacji obsługiwana była w starszej wersji Smarty, które nie pracuje pod PHP7 na początek potrzeba było przepisać wrapper Smarty dla tej aplikacji. Na szczęście obyło się bez większych problemów (Smarty 3.1.21 niewiele różni się od wersji 3.1.31 co można sprawdzić https://github.com/smarty-php/smarty/blob/master/NEW_FEATURES.txt). Przy okazji refaktoringu wrappera został on lekko zoptymalizowany.
Po pomyślnych testach nastała pora na wdrożenie zmian dla środowiska produkcyjnego.
Cały etap obył się bez większych problemów, a efekt wdrożonych zmian był widoczny od razu na wykresach.

Widać dużą różnicę pomiędzy czasem generowania strony. Pragniemy podkreślić iż samej w aplikacji nie zostało zmienione nic prócz wrappera dla Smarty. Dalsze prace optymalizacyjne pozwolą na kolejne redukcje czasu generowania strony.

 

funkcja generująca hasło

Często w naszych systemach potrzebujemy wygenerować hasło/hasła.

Napisałem przydatną funkcję generującą hasło – używam jej przy generowaniu haseł generatorem http://aljandor.unixstorm.org/pwgen/ oraz w innych miejscach.

/**
 * generowanie hasła
 * dostępne $zestawy znaków: 'l' - małe listery
                             'u' - duże litery
                             'd' - cyfry
                             's' - znaki specjalne
 * @param int $dlugosc
 * @param array $zestawy
 */
function generujHaslo($dlugosc=25, $zestawy=array('l','u','d','s'))
{
 $sets = array();
 if(in_array('l', $zestawy) !== false) 
 $sets[] = 'abcdefghjkmnpqrstuvwxyz'; 
 
 if(in_array('u', $zestawy) !== false) 
 $sets[] = 'ABCDEFGHJKMNPQRSTUVWXYZ';

 if(in_array('d', $zestawy) !== false)
 $sets[] = '23456789';

 if(in_array('s', $zestawy) !== false)
 $sets[] = '!@#$%&*?';
 

 $wszystkie = '';
 $haslo = '';
 
 foreach($sets as $set)
 {
 $haslo.= $set[array_rand(str_split($set))];
 $wszystkie .= $set;
 }
 $wszystkie = str_split($wszystkie);
 for($i = 0; $i < $dlugosc - count($sets); $i++)
 {
 $haslo .= $wszystkie[array_rand($wszystkie)];
 }
 $password = str_shuffle($haslo);
 
 return $haslo; 
}

przykładowe wywołanie:

echo generujHaslo(25, array('l', 'u','d','s'));