Author: aljandor

by aljandor on różności, Web

Przekierowanie z WWW na bez WWW + SSL

Często zachodzi potrzeba ustalenia dla naszej aplikacji jednego, głównego adresu pod którym będzie ona dostępna. Ważne jest to nie tylko z uwagi na „wygodę” użytkowników, ma to także wpłwy na SEO naszej strony. Tak więc, posiadamy domenę wraz z certyfikatem SSL. Chcemy aby nasza aplikacja była dostępna jedynie pod adresem https://domena.com

Pomocne okazać się może dość proste przekierowanie utworzone w pliku .htaccess:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^www\.(.*)
RewriteRule ^.*$ https://%1/$1 [R=301,L]

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

Powyższe wpisy przekierują wszystkie odwołania do naszej aplikacji z subdomeny www na domenę główną po protokole https oraz przekierują wszystkie żądania http na https.

 
by aljandor on PHP, Projekty, Web

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.

pomysql
pomysql2
Przechwytywanie
total-day
git-cherry-pick4
git-meowge2
git-puss3
git-purr

[Pokaz zdjęć]
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.

 
by aljandor on PostgreSQL, SQL

TimeStamp w PostgreSQL

Każdy kto pracuje z PostgreSQL używał wbudowanej funkcji NOW() – zwraca ona 'aktualny’ TimeStamp. Jednak czas jaki zwraca funkcja może w niektórych przypadkach nieco zmylić.

poniżej prosty select:

aljandor=# select now();
              now
-------------------------------
 2017-02-28 19:34:50.054909+00
(1 row)

aljandor=# select now();
              now
-------------------------------
 2017-02-28 19:35:23.217189+00
(1 row)

zobaczmy co się stanie jeśli zawrzemy dwa powyższe selecty w transakcji:

aljandor=# BEGIN;
BEGIN

aljandor=# select now();
              now
-------------------------------
 2017-02-28 19:40:28.228707+00
(1 row)

aljandor=# select now();
              now
-------------------------------
 2017-02-28 19:40:28.228707+00
(1 row)

aljandor=# COMMIT;
COMMIT

 

Zdziwiony? Dzieje się tak, iż funkcja now() zwraca time-samp czasu rozpoczęcia transakcji. Tak więc jeśli potrzebny nam dokładny znacznik czasu, użyjmy funkcji clock_timestamp():

aljandor=# BEGIN;
BEGIN

aljandor=# select clock_timestamp();
       clock_timestamp
-----------------------------
 2017-02-28 19:45:38.977532+00
(1 row)

aljandor=# select clock_timestamp();
        clock_timestamp
-------------------------------
 2017-02-28 19:45:43.540535+00
(1 row)

aljandor=# COMMIT;
COMMIT

jak widać, funkcja zwraca zawsze aktualny time-stamp. Nieświadome używanie funkcji now() może powodować bardzo groźne sytuacje w przypadkach dla których ważne jest utrzymanie rzeczywistego znacznika czasu.