Query Store, sorguların, query plan’ların ve çalışma zamanı istatistiklerinin geçmişini saklar. Böylece query plan değişikliği nedeniyle oluşan sorunları kolay bir şekilde fark edebiliriz. Bazı durumlarda SQL Server tarafından Execution Plan’lar silinir ve tekrar hesaplanır, Execution Plan’ın kullandığı istatistik objesinin güncellenmesi gerçekleşebilir, Yeni bir index oluşturulmuş olabilir, Execution Plan’ın kullandığı indeksi silmesi yahut güncellemesi olabilir, SQL Server’ın restart edilmesi olabilir. vs.. vs… İşte bu saydığımız olası sebeplerden dolayı optimum Execution Plan’ımızı kaybetmemeli, bir yerde kaydedebilmeli ve yeri ve zamanı gelince kullanabilmeliyiz. Bir sorguya ait query plan zaman içersinde bir çok nedenle değişir. Bazı durumlarda bu değişiklik sorgunun yavaş çalışmasına neden olur. Query Store özelliği gelmeden önce sorgunun yavaş çalışmaya başlamasının sebebinin query plan değişikliğinden dolayı olduğunu bulmak zor bir işti. Query Store ile artık bu işlem çok basit bir hale geldi. SQL Server 2017 ile gelen yeni dmw’nin yardımıyla aşağıdaki gibi hangi sorgu hangi query plan hangi bekleme tiplerini yaşıyor görebiliriz.
SQL Server TempDB
Sistem veritabanlarından olan ve her instance için bir tane olan TempDb'de aşağıdaki veriler tutulur. Cursor, Temp Table , Join , Aggregation ve INSTEAD OF Trigger gibi objeler Read Commited Snapshot Isolation ,Snapshot Isolation ve Online Index işleminde tutulan row version bilgileri Sorting, Hash Matches ve spools işlemleri için oluşturulan tablolar XML variables ve LOB kullanımında oluşturulan sorgular Diskler yüksek oranda I/O yapacağı için hızlı bir I/O sistemi üzerine konulması tavsiye edilir. Bu disklerin yapılandırması stripping olması önerilmektedir. Ayrıca Tempdb veritabanı diğer kullanıcı veritabanlarından farklı alanlar üzerine konulmalıdır ve tempdb data dosyaları ve log dosyalarıda bir birinden farklı disklere konulmalıdır. Bu sayede yüksek I/O elde ederek maksimum performans elde etmiş oluruz.
SQL SERVER Execution Plan Incelemesi
Execution plan en basit ifadesiyle Query Optimizer tarafından hesaplanan ve bir sorgunun en ideal şekilde çalışması için bize önerilen en optimum yoldur. Diğer bir ifadeyle bir Execution plan bize bir sorgunun çağrıldığında nasıl çalışacağını gösterir. Hangi indexleri oluşturmamız gerektiğine missing indexlerin tespitine bu incelemeyi yaparak bakabiliriz.
SQL Server 2016 In-Memory
1-) In Memory OLTP
In Memory OLTP SQL Server 2014 ile birlikte gelen bir özelliktir. Bu özellik ile verilerimizi artık memory’de tutabiliyoruz.Tabi tüm verimizi memory’de tutmamız çoğunlukla olası değildir. Çok yoğun transaction alan tablolar için ya da çok hızlı cevap almak istediğimzi tablolar için bu özelliği kullanabiliriz. In Memory OLTP ile ilgili karşımıza gelen ilk özellik memory’de tutulan tablolar olarak bilinen memory optimized table’lardır. Memory optimized table'lar SQL server 2017' de daha stabil ve daha sorunsuz çalışmaktadır.
Bu teknoloji sayesinde INSERT, UPDATE, DELETE işlemlerinde 30 kata varan performans elde etmek mümkün oldu. SELECT performansında da dikkat çekici bir artış sağlıyor. Ancak SELECT performansını asıl arttıran In-Memory DW başlığı ile gelen ColumnStore indexler olmuştur. Bu indexlerin sunduğu performans artışı ise yaklaşık olarak 100 kattır.
Git & Github Detaylı Rehber
Sürüm Kontrolü Hakkında Sürüm kontrolü, bir ya da daha fazla dosya üzerinde yapılan değişiklikleri kaydeden ve daha sonra belirli bir sürüme geri dönebilmenizi sağlayan bir sistemdir. Bu kitaptaki örneklerde yazılım kaynak kod dosyalarının sürüm kontrolünü yapacaksınız, ne var ki gerçekte sürüm kontrolünü neredeyse her türden dosya için kullanabilirsiniz. Linux’da git kurulumu Debian tabanlı linux dağıtımları için :apt-get install gitFedora için:yum install gitBu kurulumları yapmadan önce root olmak gerekir ya da sudo komutunun ardından bu komutları girmek gerekiyor.Sudo komutu girerek kök dizinde her hangi bir değişiklik yapmak istediğimizde yetkili kişi olduğumuzu bildiriyoruz. Windows’da git kurulumu Tek yapmamız gereken: bu adrese gidip işletim sisteminiz kaç birlikte uygun olanı indirip kurmak. Artık Git sisteminizde kurulu olduğuna göre, onu ihtiyacınıza göre uyarlamak için bazı düzenlemeler yapabilirsiniz. Bunları yalnızca bir kere yapmanız yeterli olacaktır: güncellemelerden etkilenmeyeceklerdir. Ayrıca istediğiniz zaman komutları yeniden çalıştırarak ayarları değiştirebilirsiniz. Git, Git'in nasıl görüneceğini ve çalışacağını belirleyen bütün konfigürasyon değişkenlerini görmenizi ve değiştirmenizi sağlayan git config adında bir araçla birlikte gelir. Bu değişkenler üç farklı yerde depolanabilirler:/etc/gitconfigdosyası: Sistemdeki bütün kullanıcılar ve onların bütün yazılım havuzları için geçerli olan değerleri içerir. git config komutunu --system seçeneğiyle kullanırsanız, araç bu dosyadan okuyup değişiklikleri bu dosyaya kaydedecektir.~/.gitconfigdosyası: Kullanıcıya özeldir. --global seçeneğiyle Git'in bu dosyadan okuyup değişiklikleri bu dosyaya kaydetmesini sağlayabilirsiniz.Kullanmakta olduğunuz yazılım havuzundaki git klasöründe bulunan config dosyası (yani .git/config): Söz konusu yazılım havuzuna özeldir. Her düzeydeki ayarlar kendisinden önce gelen düzeydeki ayarları gölgede bırakır (override), dolayısıyla .git/config'deki değerler /etc/gitconfig'deki değerlerden daha baskındır. Git'i kurduğunuzda yapmanız gereken ilk şey adınızı ve e-posta adresinizi ayarlamaktır. Bunun önemli olmasının nedeni her bir Git kaydının bu bilgiyi kullanıyor olması ve bu bilgilerin dolaşıma soktuğunuz kayıtlara değişmez biçimde işlenmesidir.$ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com--global seçeneğini kullandığınızda bunu bir kez yapmanız yeterli olacaktır, çünkü Git, o sistemde yapacağınız her işlem için bu bilgileri kullanacaktır. İsmi ya da e-posta adresini projeden projeye değiştirmek isterseniz, komutu değişiklik yapmak istediğiniz proje klasörünün içinde --global seçeneği olmadan çalıştırabilirsiniz. Bir Git Yazılım Havuzu Edinmek Var olan bir projenizi sürüm kontrolü altına almak istiyorsanız, projenin bulunduğu klasöre gidip aşağıdaki komutu çalıştırmanız gerekir:$ git initBu, gerekli yazılım havuzu dosyalarını —Git iskeletini— içeren .git adında bir klasör oluşturur. Bu noktada, projenizdeki hiçbir şey sürüm kontrolüne girmiş değildir. (Oluşturulan .git klasöründe tam olarak hangi dosyaların bulunduğu hakkında daha fazla bilgi edinmek için bkz. 9. Bölüm.) Var olan dosyalarınızı sürüm kontrolüne almak istiyorsanız, o dosyaları hazırlayıp kayıt etmelisiniz. Bunu, sürüm kontrolüne almak istediğiniz dosyaları belirleyip kayıt altına aldığınız birkaç git komutuyla gerçekleştirebilirsiniz:$ git add *.c $ git add README $ git commit -m 'projenin ilk hali'Var olan Bir Yazılım Havuzunu Klonlamak Var olan bir Git yazılım havuzunu klonlamak istiyorsanız —söz gelimi, katkıda bulunmak istediğiniz bir proje varsa- ihtiyacınız olan komut git clone. Bir yazılım havuzu git clone [url] komutuyla klonlanır. Örneğin, Grit adlı Ruby Git kütüphanesini klonlamak isterseniz, bunu şu şekilde yapabilirsiniz:$ git clone https://github.com/ahmetilgin/delta-learning-rule.gitBu komut delta-learning-rule adında bir klasör oluşturur, bu klasörün içinde bir .git alt dizini oluşturup ilklemesini yapar, söz konusu yazılım havuzunun bütün verisini indirir ve son sürümünün bir koyasını seçer (checkout). Bu yeni delta-learning-rule klasörüne gidecek olursanız, kullanılmaya ve üzerinde çalışılmaya hazır proje dosyalarını görürsünüz. Dosyaların Durumlarını Kontrol Etmek Hangi dosyanın hangi durumda olduğunu görmek için kullanılacak temel araç git status komutudur. Bu komutu bir klonlama işleminin hemen sonrasında çalıştıracak olursanız, şöyle bir şey görmelisiniz:$ git status # On branch master nothing to commit, working directory clean
Nginx,apache,Lighttpd Performans Kıyaslaması
Çalışma mantığı ve yaklaşım farkları :
Bir saniyede cevap verilen request sayısının grafiği
CSS dosyasına erişim (bootstrap.min.css)Nginx Ve Apache
Tek bir istek için karşılaşılan sonuç :
Toplu isteklerde
Salt PHP (“Merhaba Dünya”) Testi
Bu test ile en basit PHP kodunun çalıştırılıp istemciye ulaştırılmasında Apache ve Nginx’ in başarımlarının nasıl olduğunu öğreniyoruz. tek bir istek için :
Toplu istekler için sonuç:
Symfony 3.1 (“Merhaba {name}”) Testi
Bu test ile en basit Symfony kodunun çalıştırılıp client’a ulaştırılmasında Apache ve Nginx’ in başarımlarının nasıl olduğunu öğreniyoruz. Tek istek için
Toplu istekler için Apache2 ve Nginx’ten aldığımız requests/second değerleri:
Veritabanına 10 yeni kayıt gir
Doctrine ORM ile çok basit bir entity ’nin art arda oluşturulan 10 instance’ ının veritabanına kaydedilmesine ait kodun çalıştırılıp “işlem başarılı” mesajının istemciye ulaştırılmasında Apache ve Nginx’in başarımlarının nasıl olduğunu değerlendirdim. Bir tane istek için aşağıdaki karşılaştırmayı alıyoruz:
Toplu istekler için Apache2 ve Nginx’ten aldığımız requests/second değerleri:
Veritabanından 1000 kayıt oku ve görüntüle
Doctrine ORM ile çok basit bir entity’ye ait veritabanında 1000 kaydın sorgulanması, Object olarak hydrate edilmesi ve Basit bir twig döngüsü içinde kullanıcıya gösterilmesi Adımlarını içeren kodun çalıştırılıp istemciye ulaştırılmasında Apache ve Nginx’in başarımlarının nasıl olduğunu görüyoruz. Bir tane istek için aşağıdaki karşılaştırmayı alıyoruz:
Toplu istekler için Apache2 ve Nginx’ten aldığımız requests/second değerleri:
Apache Multithread çalışıyor. ( Her bir domain ve/veya projeniz için ayrı bir apache process’i yaratıldığını düşünün. )
Nginx Singlethread ve yanısıra Worker desteği ile çalışıyor. ( Her bir isteğin tek bir thread karşılandığını ancak duruma göre farklı bir Worker üzerine aktarıldığını düşünebilirsiniz. )
Lighttpd Singlethread çalışıyor. ( Tüm istekleri tek bir thread üzerinden alıp aynı thread ile işleyip yine geriye aynı yol üzerinden cevap veriyor. )
İhtiyaç duydukları donanım türüne göre performans sıralaması :
Ram Kullanımı : Lighttpd < Nginx < Apache
Burda en çok ram kullanımı apache de en az lighttpd
Cpu Kullanımı : Nginx < Lighttpd < Apache
En çok cpu yu apache kullanıyor yine en az cpu kullanan nginx.
Sunucuya göre;
Eğer sunucumda cpu ve ram problemim yoksa her an herşeye çözüm üretmem gerekecekse ve geniş destek içeriğine ihtiyacım varsa Apache.
Eğer sunucum bir VPS ise özellikle cpu kullanım oranı benim için problem olacaksa Nginx .
Eğer sunucum bir VPS ise özellikle ram kullanımı benim için sıkıntı oluyorsa Lighttpd.
tavsiye ediliyor.
Projemde çok fazla istek yapılmıyor ( çok fazla ziyaretçim yoksa, ajax, rpc gibi diğer isteklerin cevapları önemli miktarda değil ise ) ancak çok fazla yazılımsal iş yükü varsa Apache.
Projemde istek ve sayfa gösterim oranları çok yüksek yazılımsal iş yükü ağır ve projelerimde bol dinamik içerik varsa Nginx.
Projemde yazılımsal iş yükü fazla yoksa, dinamik içerikden ziyade statik içeriği aşırı yoğun ziyaretçi yüküne karşı hatasız sunmam gerekiyorsa Lighttpd.
tavsiye ediliyor.
Bir saniyede cevap verilen request sayısının grafiği
CSS dosyasına erişim (bootstrap.min.css)Nginx Ve Apache
Tek bir istek için karşılaşılan sonuç :
Toplu isteklerde
Bu test sonucunda, Nginx’in statik içerikleri sunma noktasında “toplu isteklerde” Apache2’ den en az 3 kat daha performanslı olduğu sonucuna ulaşıyoruz.
Salt PHP (“Merhaba Dünya”) Testi
Bu test ile en basit PHP kodunun çalıştırılıp istemciye ulaştırılmasında Apache ve Nginx’ in başarımlarının nasıl olduğunu öğreniyoruz. tek bir istek için :
Bu test ile; en basit PHP kodunun işletilmesi ve istemciye iletilmesinde, Nginx’in 1 request için %25 daha performanslı olduğunu; istek sayısı arttıkça bu farkın %100’e yaklaştığını gözlemliyoruz.
Symfony 3.1 (“Merhaba {name}”) Testi
Bu test ile en basit Symfony kodunun çalıştırılıp client’a ulaştırılmasında Apache ve Nginx’ in başarımlarının nasıl olduğunu öğreniyoruz. Tek istek için
Toplu istekler için Apache2 ve Nginx’ten aldığımız requests/second değerleri:
Önceki testin bulgusu olan, Nginx’in en basit PHP kodu işletimi ve istemciye iletimindeki %25’lik performans farkı; aynı işi Symfony3 ile yaptığımızda yaklaşık %30’luk bir performans farkına dönüşüyor ve fark daha da artıyor.
Veritabanına 10 yeni kayıt gir
Doctrine ORM ile çok basit bir entity ’nin art arda oluşturulan 10 instance’ ının veritabanına kaydedilmesine ait kodun çalıştırılıp “işlem başarılı” mesajının istemciye ulaştırılmasında Apache ve Nginx’in başarımlarının nasıl olduğunu değerlendirdim. Bir tane istek için aşağıdaki karşılaştırmayı alıyoruz:
Bir istek için Nginx, Apache2’den %100 daha performanslı olsa da, istek sayısı arttıkça aradaki farkın kapandığını görüyoruz. Ancak bu seviyede INSERT yaparken halâ Nginx kayda değer ölçüde daha performanslı.
Veritabanından 1000 kayıt oku ve görüntüle
Doctrine ORM ile çok basit bir entity’ye ait veritabanında 1000 kaydın sorgulanması, Object olarak hydrate edilmesi ve Basit bir twig döngüsü içinde kullanıcıya gösterilmesi Adımlarını içeren kodun çalıştırılıp istemciye ulaştırılmasında Apache ve Nginx’in başarımlarının nasıl olduğunu görüyoruz. Bir tane istek için aşağıdaki karşılaştırmayı alıyoruz:
Neredeyse bütün testler Nginx, Apache2’yi ezmiş olsa da; bu testin sonucu Apache2’nin tartışılmaz galibiyeti ile sonuçlandı. Bu durum dikkat çekici.Test Sonuçları — Toplu olarak
Django-Nginx-Postgresql Ubuntu Sunucusu Oluşturma
Django Virtualenv Pip Kurulum
Önce python3 ve pip3' ü kuruyoruz.
Postgresql kurulum ve ayarlar
Yeni Linux Kullanici Oluşturulması
Bu komutla linuxKullaniciAdi adında bir kullanici oluşturuyoruz.
Postgresql ile birlikte Yeni Uygulama Oluşturmak
Django projesi ve Gunicorn Ayarları proje klasörüne girip virtualenv'i aktifleştirelim.
Supervisor Kurulumu ve Ayarları
Supervisor linux ortamlarinda processleri kontrol altinda tutmaya yarayan yazilim. Surekli calismasini istediginiz bir yazilim varsa veya bunu bir sekilde yazilim crash ettiginde vb servis (bkz: service) gibi yeniden calistirma ozelligine sahiptir. supervisor kurulumu için
Nginx kurulumu ve Ayarları
Nginx kurulumu için
Önce python3 ve pip3' ü kuruyoruz.
sudo apt-get install python3-pip python3-devpip install django virtualenv gunicornPostgresql kurulum ve ayarlar
sudo apt-get install postgresql postgresql-contrib libpq-devpip install psycopg2
su - postgrespsqlCREATE USER userAdi WITH PASSWORD 'userSifresi';CREATE DATABASE veritabaniAdi OWNER userAdi;
Yeni Linux Kullanici Oluşturulması
Bu komutla linuxKullaniciAdi adında bir kullanici oluşturuyoruz.
sudo useradd -m -s /bin/bash linuxKullaniciAdisudo passwd linuxKullaniciAdisu - linuxKullaniciAdimkdir myprojectvirtualenv --python=python3 myproject/cd myproject/
source bin/activatepip install django gunicorn psycopg2Postgresql ile birlikte Yeni Uygulama Oluşturmak
django-admin startproject hello_django
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'veritabaniAdi',
'USER': 'userAdi',
'PASSWORD': 'userSifresi',
'HOST': 'localhost',
'PORT': '',
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')python manage.py migratepython manage.py createsuperuserpython manage.py collectstaticpython manage.py runserver
python manage.py runserver 0.0.0.0:8000
Django projesi ve Gunicorn Ayarları proje klasörüne girip virtualenv'i aktifleştirelim.
cd /myproject/source bin/activatenano bin/gunicorn_start
#!/bin/bash
# Project Name
NAME="hello_django"
# Django Project Directory
DJANGODIR=/home/linuxKullaniciAdi/myproject/hello_django
# Run gunicorn on the socket file
SOCKFILE=/home/linuxKullaniciAdi/myproject/hello_django/run/gunicorn.sock
# Gunicorn running as user and group
USER=linuxKullaniciAdi
GROUP=linuxKullaniciAdi
# Workers
NUM_WORKERS=3
#Module Setting
#replace hello_django with your project name
DJANGO_SETTINGS_MODULE=hello_django.settings
DJANGO_WSGI_MODULE=hello_django.wsgi
echo "Starting $NAME as `whoami`"
# Activate the virtual environment
cd $DJANGODIR
source ../bin/activate
export DJANGO_SETTINGS_MODULE=$DJANGO_SETTINGS_MODULE
export PYTHONPATH=$DJANGODIR:$PYTHONPATH
# Create the run directory if it doesn't exist
RUNDIR=$(dirname $SOCKFILE)
test -d $RUNDIR || mkdir -p $RUNDIR
# Start your Django Unicorn
# Programs meant to be run under supervisor should not daemonize themselves (do not use --daemon)
exec ../bin/gunicorn ${DJANGO_WSGI_MODULE}:application \
--name $NAME \
--workers $NUM_WORKERS \
--user=$USER --group=$GROUP \
--bind=unix:$SOCKFILE \
--log-level=debug \
--log-file=-
chmod u+x bin/gunicorn_startSupervisor Kurulumu ve Ayarları
Supervisor linux ortamlarinda processleri kontrol altinda tutmaya yarayan yazilim. Surekli calismasini istediginiz bir yazilim varsa veya bunu bir sekilde yazilim crash ettiginde vb servis (bkz: service) gibi yeniden calistirma ozelligine sahiptir. supervisor kurulumu için
sudo apt-get install supervisor/etc/supervisor, içinde bulunmakta.Bu klasöre gidelim ve yeni bir dosya oluşturalım.
cd /etc/supervisor/conf.d/
nano hello-django.conf
[program:hello_django]
command = sh /home/linuxKullaniciAdi/myproject/bin/gunicorn_start
user = linuxKullaniciAdi
stdout_logfile = /home/linuxKullaniciAdi/myproject/logs/gunicorn_supervisor.log
redirect_stderr = true
environment=LANG=en_US.UTF-8,LC_ALL=en_US.UTF-8
su - linuxKullaniciAdimkdir -p myproject/hello_django/run/
mkdir -p myproject/logs/
touch myproject/logs/gunicorn_supervisor.log
sudo systemctl start supervisor
sudo supervisorctl
tail -f hello_django
Nginx kurulumu ve Ayarları
Nginx kurulumu için
sudo apt-get install nginx/etc/nginx/sites-available/içinde bulunmakta klasör içine girelim ve nginx config dosyası oluşturalım.
cd /etc/nginx/sites-available/
nano hello_django
# Django running with Gunicorn Sock file
upstream hello_django_project {
server unix:/home/linuxKullaniciAdi/myproject/hello_django/run/gunicorn.sock fail_timeout=0;
}
server {
listen 80;
server_name yayinYapilacakOlanAdresinAdi.com;
client_max_body_size 4G;
access_log /home/linuxKullaniciAdi/myproject/logs/nginx-access.log;
error_log /home/linuxKullaniciAdi/myproject/logs/nginx-error.log;
location /static/ {
alias /home/linuxKullaniciAdi/myproject/hello_django/static/;
}
location /media/ {
alias /home/linuxKullaniciAdi/myproject/hello_django/media/;
}
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
# Try to serve static files from nginx, no point in making an
# *application* server like Unicorn/Rainbows! serve static files.
if (!-f $request_filename) {
proxy_pass http://hello_django_project;
break;
}
# Error pages
error_page 500 502 503 504 /500.html;
location = /500.html {
root /home/linuxKullaniciAdi/myproject/hello_django/static/;
}
}
}
sudo ln -s /etc/nginx/sites-available/hello_django /etc/nginx/sites-enabled/
sudo nginx -t
systemctl restart nginx
netstat -pl
