Hızlı WordPress sitesi için En iyi server yapılandırması

Bunun asla tek bir cevabı olamaz. Ama kendi sisteminizi tanıyorsanız muhtemelen kısa sürede kendiniz için iyi bir reçete çıkartabilirsiniz. Ben sadece Apache’den NGINX servera geçerek sayfa yüklemelerinde 6 saniye daha performanslı bir sonuç elde ettim. (6 saniyede açılan web sitesini ben yapmamıştım.)

• Bu değişikliği yapmam gerektiğini 11 günde farkettim.
• NGINX kurduktan sonra nasıl çalıştırabileceğimi öğrenmek 5 saatimi aldı.
• Yapılandırmak mı.. (bknz: https://tr.wikipedia.org/wiki/Sisifos)

Peki bu kadar basit mi?
Asla değil.

Öncelikle başlangıç yazısı olan: WordPress ile Yüksek Performans ve SEO odaklı Web Sitesi Geliştirme Notlarım da ikinci yazıda bahsedeceğim başlıkları listelemiştim. Burada tekrar hatırlayalım;

• Web sunucusu insandır, kod insanoğlu.
• NGINX mi evet conf.d yi kurcaladım.
• Apache WebSocket yazınca benim makalem çıkıyor.

Öncelikle basit localhost clientları kurup üstüne hello world yazarak yazılım öğrenmeye başladıysanız uzun yıllar basit hostingler üzerinde çalışmalar yapıyorsunuz. Panel arayüzlerindeki ayarlar da, limitleri belli paylaşımlı bir hosting üzerinde işinizi çözüyor.

Sonra yıllar geçiyor, geliştirdiğiniz sistemleri bazen aynı anda binlerce kişinin kullanabilmesi, bu sistemlerin saldırılardan korunması, tüm istekleri karşılayabilmesi vs. gerekiyor.

O zaman hemen HR departmanına bir ilan çıkmasını söyleyip ekibe bu işleri yapacak birisini almasını söylüyorsunuz ve o gelene kadar yıllık izne çıkıyorsunuz.

Genellikle böyle olmuyor.

Bir kişinin ortalama bir web sitesi ziyaretinde hangi anlarda ne kadar cpu tükettiğini bilmeniz gerekiyor. Yazdığımız kodun çalışması yetmiyor, performanslı çalışması gerekiyor. 15 MB’lık görselleri önce servera yükleyip gece 2 de tüm görselleri sıkıştıran bir zamanlanmış görev çalıştırmayı akıl ettiğimde kendimi artık usta zannetmeye başlamıştım. Ne kadar yanılmışım.

Sohbet ederken biraz da teknik örnekler verelim.

WordPress için Web sunucusu oluştururken kullanılan en popüler sistemler Apache ve NGINX’tir.

Bunların detaylı anlatımlarını yapmama gerek olduğunu düşünmüyorum, sonuçta bir eğitim içeriği oluşturmuyoruz. Ama akla gelen ilk soruyu Gemini’a sorarak başlayalım. (Yanıtları, soruların üstüne tıklayıp görüntüleyebilirsiniz.)

Bu yanıtlar su götürmez, WordPress bir site kuracaksak NGINX web sunucusu üzerinde çalıştırmak performans için pozitif etki yaratacak.

Geliştirme yaparken de geliştirme ortamlarımızı buna göre düzenleyebilirsiniz.

Web sunucusu insandır, kod insanoğlu.

Hazır kod bloklarını kullanarak ekrana bir şeyler yazdırdığım ilk günlerden, detaylı CRUD işlemleri yaptığım büyük sistemlere kadar hep gözden kaçırdığım bir şey vardı, o da bu işin mühendisliği.

Tasarlamak, mimarisini oluşturmak bir yere kadar kolaydı. Çünkü yaygın bir iş için diğer insanlar ne yaparsa ben de aynısını yapıyordum. cPanel’li olacak hosting diyordum soranlara(!).

Fakat tasarlamak ve mimari kurmak için yaygın bilgilerin yetmediği bir noktaya geldi konu. Tam bu noktada mecburen bu kod’un arkasında ne var, nerede işini görüyor, çalışıyor, oralarda neler yapabiliriz diye düşünmeye başlıyoruz.

En başta içi boş bir server kiralayıp her şeyini manuel kurmak ve entegre etmek imkansız gibi geliyordu ama ben bu aşamayı Amazon Web Services kullanarak çok daha rahat atlattım. Çalıştığım proje ölçeklenebilir bir altyapı mimarisi kurmuştu ve bu mimariyi kuran arkadaşlarla bolca sohbet etme fırsatım oldu. Bir şeylerin ne için var olduğunu öğrenmek çok önemli, çünkü o noktadan sonra hareket alanımızı anlamış oluyoruz.

Birden çok web server yoğunluğa göre açılıyor, gelen ziyaretçiler de bu web serverler üzerine dağıtılıyor, siteye kaç kişi girerse girsin site ayakta kalıyor. En ilkel ölçekleme yöntemi budur AWS’de. Yoğunluğa göre otomatik açılan makine kullanımı başına faturalandırılırsınız. Bir yerden başlamak da önemli, o sebeple bunu kullanıyorduk.

Fakat zaman içerisinde AWS modüllerini gördükçe çok daha karlı yöntemler geldi aklıma. Fakat bunun için AWS’ye tamamen bağımlı olmayı kabul etmiş oluyorsunuz. Veya bu modülleri kendi içinizde kuracak takıma sahip olmalısınız. Ki bu pek çok şirket için bile pek mümkün değil.

Ben bir AWS uzmanı değilim o sebeple ölçeklenebilir de yapsanız, single şekilde VDS’e de kursanız bir WordPress sitesi geliştirirken nasıl bir genel server konfigurasyon uygulamalıyız bunu anlatabilirim. Yeterli mi? Pek çok kişi için yeterli olacaktır.

NGINX mi evet conf.d yi kurcaladım.

Ben tek tek kurulum yönergesi yazmayacağım. Ama şu soruların Google Gemini cevaplarına bakmakta fayda var.

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload1

Şimdi sıra bir NGINX conf. dosyasında neler yazıyorum onları tek tek incelemekte. Bu konfigurasyon dosyasını /etc/nginx/sites-enabled/ icerisinde example.com.conf adı ile oluşturacağız. example kısmını kendinize göre özelleştirebilirsiniz.

server {
    listen 80; # HTTP (80) portunu dinle
    listen [::]:80; # IPv6 üzerinden HTTP (80) portunu dinle

    server_name example.com www.example.com;  # Sunucunun bu alan adlarına yanıt vereceğini belirt (hem example.com hem de www.example.com)

    if ($host = 'example.com') { # Eğer gelen istek 'example.com' alan adından geliyorsa
        return 301 https://www.example.com$request_uri; # 301 (kalıcı) yönlendirme ile HTTPS'e yönlendir ve www alt alan adını ekle (istek URL'sini koru)
    }

    if ($host = 'www.example.com') { # Eğer gelen istek 'www.example.com' alan adından geliyorsa
        return 301 https://www.example.com$request_uri; # 301 (kalıcı) yönlendirme ile HTTPS'e yönlendir ve www alt alan adını ekle (istek URL'sini koru)
    }
}

server { # HTTPS sunucu bloğu

        listen [::]:443 ssl http2; # IPv6 üzerinden HTTPS (443) portunu dinle, SSL ve HTTP/2 etkin
        listen 443 ssl http2; # HTTPS (443) portunu dinle, SSL ve HTTP/2 etkin
        server_name example.com www.example.com; # Sunucunun bu alan adlarına yanıt vereceğini belirt (hem example.com hem de www.example.com)

        ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # SSL sertifika dosyasının yolunu belirt
        ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # SSL özel anahtar dosyasının yolunu belirt
        ssl_session_cache shared:le_nginx_SSL:10m; # SSL oturum önbelleğini 10MB boyutunda paylaşılan bir alanda sakla
        ssl_session_timeout 1440m; # SSL oturum zaman aşımını 1440 dakika (1 gün) olarak ayarla
        ssl_session_tickets off; # SSL oturum biletlerini devre dışı bırak
        ssl_protocols TLSv1.2 TLSv1.3; # Kullanılacak SSL/TLS protokollerini belirt (TLS 1.2 ve 1.3)
        ssl_prefer_server_ciphers off; # Sunucu şifrelerini tercih etme
        ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA"; # Kullanılacak şifreleme algoritmalarını belirt
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # Diffie-Hellman parametreleri dosyasının yolunu belirt (Certbot tarafından yönetilir)

location ~* \.(jpg|jpeg|png|gif|ico|webp|ttf|woff|woff2)$ { # Bu dosya uzantılarına sahip statik dosyalar için
    expires 30d; # Tarayıcı önbelleğini 30 gün olarak ayarla
    add_header Cache-Control "public, max-age=2592000, immutable"; # Tarayıcı önbellekleme kontrol başlığını ayarla (30 gün, değiştirilemez)
}

location ~* \.(css|js)$ { # Bu dosya uzantılarına sahip statik dosyalar için
    expires 30d; # Tarayıcı önbelleğini 30 gün olarak ayarla
    add_header Cache-Control "public, max-age=2592000"; # Tarayıcı önbellekleme kontrol başlığını ayarla (30 gün)
}

        root /var/www/examplecom; # Web sitesinin kök dizinini belirt
        index index.php index.html index.htm; # Dizin indeks dosyalarını belirt (öncelik sırasına göre)
        client_max_body_size 200M; # İstemci tarafından gönderilen maksimum istek boyutunu 200MB olarak ayarla

        location / { # Tüm istekler için (kök dizin)
                index index.php; # index.php dosyasını indeks dosyası olarak kullan
                try_files $uri $uri/ /index.php$is_args$args; # Dosya veya dizin yoksa, index.php dosyasını çalıştır ve sorgu parametrelerini ekle
        }

       location ~ \.php$ { # PHP dosyaları için
                include snippets/fastcgi-php.conf; # FastCGI yapılandırma dosyalarını dahil et
                fastcgi_pass unix:/run/php/php8.1-fpm.sock; # PHP-FPM soket dosyasının yolunu belirt
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; # PHP betik dosyasının yolunu FastCGI'ye ilet
        }
}

Bu örnek PHP 8.1 kullandığım bir projenin nginx konfigurasyonlarını gösteriyor. Basit bir şekilde 80 ve 443 portlarını dinliyor, 443 portu için SSL ayarlarını içeriyor. 80 portuna gelen ziyaretçileri 443 portuna yönlendiriyor. Çeşitli cache ayarlarını, dosya dizin şartlarını ve dizindeki PHP kodunu çalıştırmak için fastcgi ayarlarını içeriyor.

Bunlar bilenin unuttuğu, bilmeyenin de öğrenmeye bir türlü heveslenemediği bilgiler aslında. Unutmayalım konumuz WordPress ile Yüksek Performanslı Site Yayayınlamak. NGINX yüzlerce farklı kombinasyonda özelleştirilebilir ayara sahiptir. Bu konu kendı içinde bir yazı dizisi oluşturabilir. Bu sebeple ben ortalama bir projede kullandığım NGINX konfigürasyon dosyasını paylaştım ve satırlara detaylarını ekledim.

Apache dış kapının dış mandalı mı? Apache’nin hiç mi olur yanı yok diye soranlar varsa: ‘Yazılım geliştirme reçeteleri önceden öğrenilen enstrümanlarla değil, karşınıza olur olmadık anlarda çıkan ihtiyaçlarla belirlenir.’ demek isterim.

Google’a ‘Apache WebSocket’ yazınca benim makalem çıkıyor 🙂

Bu tip durumlarda yanlış bir şey mi yapıyorum acaba diye düşünmeden edemiyorum. Mevcut kaynakları tarayıp yapmaya çalıştığım websocket kurulumu maalesef tutarlı çalışmamıştı, ben de sağlıklı çalışan kurulumu makaleye dönüştürdüm. Bahsi geçen websocket’i kurduğum bu projeyi neden Apache’den NGINX’e taşımadığımı da başka bir yazı da anlatacağım.

Sonuçta bazı konular dikeyinde çalıştıkça bu enstrümanların kullanım alanlarının farklı ve fazla olduğunu görebilirsiniz. Apache de NGINX de yeri ve zamanı gelince kullanılır. Lakin hızlı WordPress NGINX ister, SEO’cunuz htaccess (apache içindir) düzenlemek isterse bana kızmayın. NGINX’de nasıl yapacağınızı öğrenin. Yapay zeka, örnek htaccess kodunuzu NGINX için convert etmenize yardımcı olacaktır.