BoraN7 Tarayıcıdan gelen istek domainin işaret ettiği IP adresine geldiğinde, bu istek internet portunu (80/443) dinleyen web sunucusu tarafından socket aracılığıyla işlem yöneticisine (FPM) iletilir. FPM de gelen isteği bir PHP işçisine (worker) atar. Bu worker gelen isteği işlem koduna (opcode) derler, belleğe alır, Zend moturu tarafından bu direktifler çalıştırılır. (Opcache aktif ise bu belleğe alınan direktifler önbellekte tutulup ihtiyaç halinde derleme gerçekleşmeden tekrar Zend tarafından çalıştırılarak performans artışı sağlanır, Opcache bu işe yarıyor.) Çıkan işlem sonucu da istemciye geri gönderilir ve işlem sonlandırılır. Bu her istekte tekrar başlayan bir döngüdür, yani PHP'nin çalışma şeklidir. Laravel olarak düşündüğümüzde ise Opcache tarafından önbelleklenen kısımlar haricinde her istekte Laravel'in baştan yüklenmesinden bahsediyoruz. Bu da yavaş yanıt süreleri demektir: Toplam Yanıt Süresi = Laravel vs her şeyin yüklenme süresi + İsteğin işlenme ve cevap süresi. (Bu işlemi, Vue ile yazılan bir uygulamada her linke tıklanmasında sadece ilgili alanların değişmesi yerine komple tarayıcının yenilenmesi olarak düşünebilirsiniz.) Bir PHP worker tek seferde bir iş yapar, bir isteği yönetebilir. O yüzden birden fazla isteğin eş zamanlı işlenebilmesi için birden fazla worker çalışır (FPM bunları yöneten yöneticidir.). Bu yaşam döngüsünü hızlandırmak için yapılan şeylerden ilki (uygulama tarafında bir sorun olmadığını varsayarsak) bu worker sayısını arttırmaktır, böylece aynı anda çok daha fazla istek işlenebilir ama bu da kaynak tüketimi demektir. Belli bir noktaya kadar donanımı arttırarak, para harcayarak bu kaynağa ulaşılabilir ama elbette çözüm bu olmamalı, az kaynakla çok iş yapmak olmalıdır. O yüzden çözüm Laravel'in her seferinde yüklenmesine engel olmaktır. Bildiğiniz gibi örneğin AppServiceProvider::boot() içerisine yazdığımız bir sorgu her seferinde aynı sonucu verse de her istekte tekrar çalışır. Bunun önüne geçmek için biz cache vs kullanırız. İşte bunun yerine bu işlemlerin bir kere belleğe alındıktan sonra bir daha yenilenmediğini düşünün. FPM bunu yapamaz ama alternatifi var: Swoole. Swoole buna olanak sağlayan bir işlem yöneticisidir fakat burada bir sorun var. Klasik FPM ile her istekte her şey baştan yüklendiği için hiçbir şey birbirine karışmaz, her istek kendine özeldir, her kullanıcı kendi isteğini atar, her biri kendine özgü işlem yapar, veri kullanır vs... ama Swoole kullandığınızda bu her zaman mümkün olmayabilir. Şöyle düşünebilirsiniz: random değere sahip bir session değişkeni oluşturduğunuzda değişken adı aynı olsa bile değer her kullanıcı için farklıdır çünkü oturum her kullanıcı için ayrı bir dosyada/yerde tutulur fakat aynı isimde sunucuda bir cache tuttuğunuzda herkes için aynı değeri tutar. Bunu engellemek için ne yapıyorduk? Mesela Cache::put("key_{$user->id}", 'value')
yaparak önbelleği kullanıcıya özel hale getiriyorduk. Peki bunu bir Request için nasıl yapabiliriz? İşte Laravel Octane Swoole ile çalışırken bu işi bizim için yapacak, hem işlemlerin paralel yapılmasını hem de birbirine karışmadan işlenmesini sağlayacak. Diğer paketlerde vs yapılan değişikliklerin sebebi bu uyum sağlama süreci. Biz de büyük ihtimalle neyin her istekte baştan yüklenmesi gerektiğini neyin yüklenmemesi gerektiğini belirleyebileceğiz, deferred provider oluşturabildiğimiz gibi.
İşte Octane, Laravel'in Swoole ya da RoadRunner ortamında çalışmasına olanak tanıyacak olan paket, umarım anlatabilmişimdir. Paket daha çıkmadığı için ben anladığımı anlattım, çıkınca tekrar değerlendiririz.
Swoole ve RoadRunner ile Node.js gibi ortamlarda ya da Go, Erlang, C#, Java... gibi dillerde karşımıza çıkan async programlama, coroutines, concurrency/multi-tasking, load balancing... gibi özellikleri PHP'de kullanabiliyoruz (çünkü workerları kontrol edebiliyoruz). Laravel Octane ise bunları, içlerinde kaybolmadan deneyimlememizi, kullanmamızı sağlayacak (Mesela broadcasting özelliğini kullanırken message broker, publisher, subscriber... gibi konularda takılmayıp direkt kullanmamıza olanak sağladığı gibi) ve aynı zamanda dolaylı ve direkt yollardan performans artışı sağlanmış olacak. O yüzden Laravel Octane'den ziyade üstteki kavramları öğrenmeniz daha önemli çünkü benim anladığım kadarıyla Octane bizim için arka planda çalışıp (artisan queue:work gibi) bizim yerimize karmaşayı halledecek. Bunun için:
https://www.swoole.co.uk/
https://roadrunner.dev/
Ben de paketi merak ediyorum, daha önce Swoole ya da RoadRunner kullanmadım ama PHP ile yazılım geliştirmede bakış açımızın Node.js'in Javascript'i değiştirdiği gibi değiştirebileceğini düşünüyorum. Laravel tarafında ise, özellikle ilgimi çekmesini sağlayan bunun 3. parti değil de direkt birinci elden, resmi olarak desteklenmesi.