Browserless İncelemesi: Kota ile Kullanabileceğiniz Chrome Hizmeti

Browserless, self-host ettiğiniz bir servis olarak paketlenmiş headless Chrome’dur. Docker konteyneri sürekli çalışır, işleri HTTP ya da WebSocket üzerinden kabul eder ve her çağıranın içine gömülmek yerine paylaşılan kabul limitlerini uygular. Bu REST testlerinde servis boştayken sıfır Chrome süreci ile çalıştı, istek aktifken Chrome süreçleri oluşturdu ve iş bitince tekrar sıfıra döndü. Burada havuzlanan şey önceden ısıtılmış tarayıcı süreçleri değil, servis kapasitesi ve kuyruklama mantığıdır.

v2.55.0 sürümünü kontrollü bir yerel fixture üzerinde test ettim — başlangıcı aşamalara böldüm, üç farklı yapılandırmada kabul kontrolünü ölçtüm, bilinen doğruluk değerleriyle uç nokta sadakatini doğruladım, 30 oturumluk bir soak testi yaptım ve zaman aşımı sınırını yokladım. İşe yarayan taraf hız artışından çok operasyonel davranış oldu: kabul limitleri, istemci tarafında görülen yanıtlarla eşleşti; sorun çıkaran noktalar ise büyük ölçüde dağıtım biçiminden kaynaklanıyordu.

En faydalı sonuç bir gecikme sayısı değildi. Browserless, Chrome’u daha hızlı başlatmıyor — Chrome’un kapısına bir giriş politikası koyuyor: içeride sabit sayıda oturum, onların arkasında bir kuyruk ve diğer herkes için HTTP 429. Bu üst sınır, iki environment değişkenini değiştirdiğimde 4’ten 8’e, sonra 10’a çıktı ve konteynerin kendi muhasebesi, her bir istekte istemcimin durum kodlarıyla birebir uyum sağladı.

Browserless aslında nedir?

İnsanların en sık takıldığı nokta kategori tarafı. Browserless içe aktarıp çağırdığınız bir kütüphane değildir. O, uzun ömürlü bir servis olarak çalıştırdığınız bir Docker imajıdır — ghcr.io/browserless/chromium. Tarayıcı işlerini aracı olarak yönetir ve bunu iki yoldan sunar: REST uç noktaları (/content, /scrape, /screenshot, /pdf, ayrıca /function ve /unblock) ve Puppeteer ile Playwright’ın connect() olabileceği bir CDP/WebSocket yüzeyi.

Ben REST yüzeyini test ettim. WebSocket yolu gerçek ve yaygın olarak kullanılıyor, ancak onu ölçmedim.

Test edilen sürüm v2.55.0 idi ve 27 Temmuz 2026 tarihinde doğrulandı.

Yıldız sayıları değişir; bunu yalnızca o anlık bir okuma olarak düşünün.

Lisans kapısı: SSPL-1.0 ya da ticari lisans

Depo, Browserless’i SSPL-1.0 veya Browserless ticari lisansı altında sunuyor. Bir yol seçmeden önce mevcut depo LICENSE dosyasını ve Browserless’in resmî açık kaynak dağıtım rehberini aynen okuyun. Bu yazı; ticari ürünler, kapalı kaynak uygulamalar, CI sistemleri, barındırılan servisler veya kurum içi kurulumlar için hukuki analiz yapmadı; dolayısıyla bu senaryoları herhangi bir lisansa atamıyor. Dağıtım ve yaygınlaştırma modelinizi, bir avukatın veya yazılım lisanslamasından sorumlu kişinin değerlendirmesi gerekir.

Browserless ayrıca barındırılan planlar da satıyor. Fiyatlandırma ve kullanım birimi tanımları sık değişebilir; bu self-hosted testin parçası değildi, bu yüzden burada gördüğünüz eski bir tabloyu satın alma kanıtı gibi değil, resmî siteden doğrulanması gereken bir referans olarak kabul edin.

Oturum modeli kaputun altında nasıl çalışıyor?

Ölçülen REST yolu, istek başına tarayıcı işi gibi davrandı; ancak bu test düzeneği Browserless’in iç işleyişini yeterince derin izlemediği için, yeni bir tarayıcı süreci ile her türlü context yeniden kullanımı stratejisini birbirinden ayıramaz. Yine de netleştirilen şey daha basit: boşta sıfır Chrome süreci, aktif bir istek sırasında 11 chrome-family süreci ve ardışık çalıştırma sonrasında tekrar sıfır. Bu yapılandırmada önceden ısıtılmış bir tarayıcı havuzuna dair kanıt yoktu.

Uzun ömürlü Node servisi, sınırlı sayıda tarayıcı işini kabul eder, başka bir sınırlı seti sıraya alır ve geri kalanları reddeder. Aşağıda ölçülen mimari sözleşme olarak bunu kabul edin. “Pool” kelimesinden süreç veya context yeniden kullanımını çıkarmayın; zamanlama düzeneği bunu kanıtlayamaz.

Kabul kontrolü iki ayardan oluşur:

• CONCURRENT — aynı anda kaç oturum çalışabilir.
• QUEUED — slot açılmasını bekleyebilecek ek istek sayısı.

Konteynerin /config uç noktası varsayılan olarak CONCURRENT=10, QUEUED=10, TIMEOUT=30000 değerlerini bildirdi. CONCURRENT + QUEUED toplamının ötesindeki her şey hemen reddedilir.

Kimlik doğrulama isteğe bağlı değildir. Browserless v2 her zaman bir token gerektirir — TOKEN ayarlamazsanız, başlangıçta rastgele bir token üretir ve stdout’a yazdırır. Her REST çağrısı ?token= parametresi taşır.

Gözlemlenebilirlik için /pressure (çalışan, kuyrukta bekleyen, CPU, bellek, son reddedilenler), /sessions ve /config vardır. Ayrıca /metrics JSON çıktısı da bulunur, ancak bunun için METRICS_JSON_PATH ayarlanmalıdır; ben kullanmadım. İmaj ayrıca PID 1 olarak dumb-init ile çalışır; bu da konteynerleştirilmiş Chrome’un yıllardır peşinden gelen zombie-process şikâyetlerine karşı belgelenmiş çözümdür.

Kurulum gerçeği: tek komut ve o tek komutta kimsenin söylemediği dört şey

Herkesin aktardığı kurulum satırı gerçekten tek bir docker run komutu. Fakat onun etrafındaki ayrıntılar için ayrıca plan yapmanız gerekir.

İmaj 4.34 GB. Beklentini şekillendirmesi gereken sayı bu; başlangıç gecikmesi değil. Manifest hem linux/arm64 hem de linux/amd64 içeriyor; benim arm64 host’umda Docker yerel arm64 varyantını çekti. (Konteyner içindeki Chrome user-agent hâlâ X11; Linux x86_64 yazar — bu Linux’ta Chrome’un kozmetik UA bilgisidir, emülasyon değil. uname -m ise aarch64 der. İnsanlar bunun için hata kaydı açıyor.)

Tüm ölçümlerde --shm-size=2g kullandım. Test düzeni Docker’ın varsayılan /dev/shm ayarında bir kontrol koşusu içermiyordu; bu yüzden bu yazı, 2 GiB’nin evrensel olarak zorunlu olduğunu söyleyemez ya da başarısızlık noktasını nicemleyemez. Bunu tarayıcı sayınıza ve iş yükünüze göre ayarlayın.

Token, formalite değil dağıtım konusudur. Token olmadan, 3000 portuna ulaşabilen herkes ağınızda bir tarayıcıyı kontrol edebilir.

Konteyner ağ geçidi sizin sorununuzdur. Benim fixture host üzerinde çalışıyordu; bu yüzden konteyner ona host.docker.internal üzerinden ulaştı (colima bunu --add-host host.docker.internal:host-gateway ile eşler). Ölçüme güvenmeden önce konteynerin fixture’a gerçekten erişebildiğini ham bir curl ile doğruladım.

Benim ortamım: macOS 26.5.2 arm64 üzerinde Docker 29.2.1 ile colima 0.10.3 (6 CPU / 11.6 GiB). Test düzeneği yalnızca Python 3 standart kütüphanesini kullandı. PNG ve PDF için çözümlenmiş içerik doğruluğunu, boyutları, sayfa sayısını, bütünlüğü veya görsel sadakati değil, dosya imzalarını kontrol etti.

Aşağıdaki minimal eşdeğer başlatma, sabitlenmiş imajı, açık bir token’ı ve burada kullanılan paylaşımlı bellek tahsisini kullanır:

docker run --rm -p 3000:3000 --shm-size=2g \
  -e TOKEN=replace-with-a-secret \
  ghcr.io/browserless/chromium:v2.55.0

/pressure?token=... yanıt verdikten sonra, hedef URL’yi içeren JSON gövdeli kimlik doğrulanmış bir POST /content?token=..., REST yolunu çalıştırır. Üretim tarafındaki çağıranlar için, 429 yanıtlarına karşı jitter’lı sınırlı yeniden deneme gerekir; hemen tekrar denemek yalnızca aynı dolu kuyruğa yeniden yarış açar.

Başlangıç maliyeti, parçalanmış halde

Üç yeni docker run başlatması, medyan ve min–maks değerleriyle:

Ortadaki satırı yanlış okumak kolay. Bu satır, tarayıcı başlatmayı tek başına ölçmez ve Browserless’in Chrome’u process-içi bir kütüphaneden daha hızlı başlattığını göstermez. Bu, konteyner içine bir HTTP gidiş-dönüşü, ardından tarayıcı işi, gezinme ve yanıt aktarımıdır. Yaklaşık 0.17 saniyelik ilk ve sonraki istek farkı; dosya sistemi, işletim sistemi, Chrome, Node veya konteyner önbelleği etkilerini içerebilir. Chrome süreçleri boşta sıfır olduğu ve bu çağrılar için test düzeneği herhangi bir CDP izi ya da süreç zaman çizelgesi yakalamadığı için, bu farkı tarayıcı yeniden kullanımına ya da “amortize edilmiş” başlatma maliyetine bağlayamaz.

Bir de şunu unutmayın: bunlar macOS üzerinde colima VM sayıları. Yerel donanım Linux’ta farklı olur. 0.78 s değerini SRE ekibinize sanki her ortamda geçerliymiş gibi sunmayın.

Uygulamalı test: tavanı iki taraftan bulmak

CONCURRENT + QUEUED → 429 sözleşmesi her yerde tekrar edilir ama nadiren doğrudan gösterilir.

Kurulum şu: sunucu tarafında 5 saniye uyuyan bir fixture rotası, böylece her istek belirli bir süre boyunca güvenilir biçimde bir oturumu meşgul eder. Ardından CONCURRENT + QUEUED + 4 isteği aynı anda gönderin ve ne döndüğüne bakın — aynı anda ayrı bir örnekleyici thread de konteynerin kendi muhasebesini okumak için /pressure değerini yoklar.

Buradan üç sonuç çıktı.

Tavan her seferinde tam olarak CONCURRENT + QUEUED. Başarılı yanıtlar 4, 8 ve 10 oldu — her durumda yapılandırılan toplam kadar. Reddedilenler ise aşım miktarına eşitti; bu üç koşunun hepsinde 4’tü.

Tavan değişir. Bu, imaja gömülü sabit bir değer değil; ne yapılandırırsanız odur. Ortam değişkenleriyle 4 → 8 → 10’a çıkması, bunu önemsiz bir ayrıntı olmaktan çıkarıp kullanışlı hale getiren kısımdır.

Ve iki sinyal birbirinden bağımsızdır. İstemcimdeki durum kodları gerçek HTTP yanıtlarından geldi; /pressure ise farklı bir thread tarafından yoklanan, konteynerin kendi iç muhasebesinden. Bu üç kısa koşuda birbirleriyle uyum sağladılar. Bu da /pressure’ı üretimde kullanılabilecek bir sinyal adayı yapar; ancak tek başına eksiksiz bir otomatik ölçekleme sözleşmesi değildir: örnekleme sıklığı, sıfırlanma semantiği, çoklu replica toplaması ve daha uzun karışık iş yükleri altındaki davranışın ayrıca doğrulanması gerekir.

Geçti/kaldı sayılarının gizlediği bir nüans var. Kuyruğa alınan bir istek başarısız olmaz — bekler ve bir süre bekleyebilir. (2, 2) ayarında ve 5 saniyelik iş yüküyle, başarılı yanıtlar 5.7 s ile 11.0 s arasında geldi; medyan 8.3 s idi. Yani uçtan uca gecikme yaklaşık iki oturum süresine kadar çıktı. Test düzeneği ayrı kabul ve yürütme zaman damgalarını yakalamadığı için, bu gecikmenin tamamını kuyruk beklemeye atfedemez.

Bu, gerçek bir işte nasıl görünür?

Diyelim ki her gece 4.000 ürün sayfasını PDF’e dönüştürüyorsunuz ve her sayfa yaklaşık 5 saniye sürüyor. CONCURRENT=5, QUEUED=5 ayarlıyorsunuz. Geçiş kapasiteniz 5 saniyede 5 sayfa — yani saniyede 1 sayfa — olur; hattı tam dolu tutarsanız iş yaklaşık 67 dakika sürer. Bu bir benchmark değil, ölçülen davranış üzerine yapılmış aritmetik; ama dağıtımdan önce yapmanız gereken hesap tam olarak budur.

Çalışan ve kuyruktaki tüm slotlar doluyken gelen her istek anında 429 alabilir; aynı anda gönderim, hangi ordinal isteğin yarışı kaybedeceğini garanti etmez. Bir iş çalıştırıcı, bu yanıtı backpressure olarak görmeli ve sınırlı jitter’lı yeniden deneme kullanmalıdır. Aksi halde üst seviye iş muhasebesi devam ederken sayfalar düşebilir — bu, bu test düzeneğinin gösterdiği bir hata değil, operasyonel riskidir.

Uygulamalı test: uç noktaların gerçekten gördükleri

Render sadakatini dürüstçe test etmek için, fixture sayfası işaret metnini gerçek bir tarayıcı çalıştırmayan herkesten saklar. Görünen Runtime Injected Marker 88 dizesi yükleme sırasında JavaScript parçalarından oluşturulur; yani sunucunun gönderdiği hiçbir baytta onun için bitişik bir literal yoktur. O sayfanın düz bir statik fetch’i, içinde ne bu işareti ne de diğerini barındıran 702 bayt döndürür.

/content’in 811 bayt ve eklenen işareti döndürmesi, gerçek bir Chromium’un HTML geri dönmeden önce sayfayı render ettiğini gösterir. /scrape, JavaScript çalışana kadar var olmayan bir düğümden değer çekti. İkisi de istemci tarafında sıfır otomasyon kodu ile çalıştı — tek bir kimlik doğrulanmış POST yeterliydi.

Asıl vaat budur. Aynı test turunda, statik bir crawler bu içerik sınıfını tamamen kaçırdı; process içi tarayıcı kütüphaneleri (chromedp, rod, Selenium) ise ancak açık bir bekleme ekledikten sonra yakalayabildi. Browserless bunu curl benzeri bir istekle yakaladı. Burada otomasyon kodunu, dağıtım ağırlığıyla takas ediyorsunuz.

Bu iddia için iki sınır var. Kanıtlar modern web’in genel bir taramasını değil, benim fixture’ımdaki içerik sınıflarını kapsıyor. Ayrıca anti-detection uç noktası olan /unblock bilerek hiç kurcalanmadı — bu sonuçların hiçbiri anti-bot kabiliyeti iddiası olarak okunmamalı. /function, /download ve /performance de test edilmedi.

Uygulamalı test: kısa bir kalıntı kontrolü

Konteynerleştirilmiş Chrome’un geride ceset bırakmasıyla ilgili bir ünü vardır; bu yüzden CONCURRENT=3 ile 30 ardışık oturum çalıştırıp konteyner içindeki süreçleri saydım.

Bunların hiçbirine güvenmeden önce dedektörü kalibre ettim. Bir oturum sürerken /proc sayacı 11 chrome-family süreci okudu (browser, zygote, GPU, renderer’lar, utility’ler). Bu önemli: araç Chrome’u görebiliyor demektir; dolayısıyla koşu sonundaki sıfır, körlük değil ölçümdür. Sayabildiğini kanıtlamadan “0 süreç” raporlayan bir leak testi işe yaramaz.

30 oturumdan sonra: 0 chrome süreci, 0 zombie. Geriye kalanlar yalnızca dumb-init, node, Xvfb, start.sh ve sh idi. /sessions boşta 0 gösterdi.

Konteyner belleği, docker stats verisine göre (tek bir süreç RSS’i değil, operatörün görebildiği sayı):

30 oturum boyunca net büyüme yaklaşık 9.5 MB oldu ve örneklenen eğri 10. oturumdan sonra plato yaptı. Bu, bu kısa pencerede basit doğrusal bir oturum başına sızıntıyla uyumlu değil. Node warmup olası bir açıklama; ancak bu süreç sayımı ve bellek serisi onu kanıtlayamaz.

Kapsam: 30 ardışık oturum küçük bir soak testtir; dayanıklılık ya da eşzamanlılık testi değildir. Issue tracker’daki uzun süredir görülen EventEmitter listener uyarıları, saatler ve binlerce oturum sonunda ortaya çıkabilecek türden şeylerdir; ben bunu çalıştırmadım. Desteklenen sonuç yalnızca, bu pencere içinde v2.55.0 üzerinde biriken Chrome süreçleri veya zombie’ler gözlenmediğidir.

Zaman aşımı sınırı

TIMEOUT, belgelenmiş bir ayardır. Ben de tetiklenmesini görmek istedim.

TIMEOUT=5000 ile, sayfayı 15 saniye tutmaya çalışan bir oturum askıda kalmak yerine 5.007 s’de HTTP 408 döndürdü. Bu tek gözlem, yapılandırılmış sınır civarında bir uygulamayı doğrular. Timer’ın nasıl uygulandığını göstermez ya da slot temizliğini kanıtlamaz; daha güçlü bir test, denemeyi tekrarlar, /sessions ve /pressure’ın tekrar boşa döndüğünü gözlemler ve ardından gelen bir isteğin boşalan slotu aldığını doğrular.

Geçiş tuzağı: PREBOOT etkisizdir ve bunu size söylemez

Ölçtüğüm her şey arasında, yükseltmeden önce bana en çok verilmesini isteyeceğim sonuç bu.

Browserless 2.0.0, PREBOOT ve KEEP_ALIVE’ı kaldırdı — değişiklik günlüğü, bunların kafa karıştırıcı olduğu, pek bir şey yapmadığı ve hata çıkardığı için kaldırıldığını söylüyor. Mantıklı bir karar. Sorun, bir v1 yapılandırmasının kopyala-yapıştır ile v2’ye taşınması halinde ortaya çıkıyor; insanlar yükseltmeyi en sık böyle yapıyor.

Konteyneri -e PREBOOT=true ile çalıştırdım ve varsayılanla karşılaştırdım:

Her zamanlama, varsayılan kolun kendi min–maks bandının içinde; bu bir etki değil, gürültü. Ayrıca hiçbir şey önceden ısıtılmadı: PREBOOT=true konteyneri boşta hiçbir tarayıcı tutmuyor; bayrak olmayan sürümle aynı. İki ek sinyal, ikisi de sayı değil:

• /config, hiçbir preboot anahtarı sunmuyor. Anahtarlar concurrent, queued, timeout, token, maxCPU, maxMemory, retries ve benzerleri.
• Hata yok. Uyarı yok. Konteyner loglarında hiçbir şey yok.

Yani v1’den gelen bir PREBOOT yapılandırması, v2’de olağan başlangıç ve log kontrollerinde sessiz bir no-op’tur. Eksik /config anahtarı ile değişmeyen davranış birlikte tespit edilebilir sinyaldir; Browserless açık bir reddetme ya da uyarı üretmez. Geçiş kontrolünün, tüm environment değişkenlerinin etkili olduğunu yeşil başlangıca bakarak varsaymak yerine uygulanan yapılandırmayı incelemesi gerekir.

KEEP_ALIVE bunun tersidir ve ikisi aynı kefeye konmamalıdır. Aynı sürümde kaldırıldı, ama sessiz değildir — konteyneri kısa bir probe ile yokladığınızda stdout’ta tam orada Environment variable of "KEEP_ALIVE" is deprecated and ignored. yazar. Bu düzgün bir operatör uyarısıdır. KEEP_ALIVE için, PREBOOT’a uyguladığım ölçüm düzeninin aynısını kullanmadım; bu yüzden bunu bir ölçüm değil, bir kontrol olarak raporluyorum. Ama yönü yeterince nettir: sessiz tuzak yalnızca PREBOOT’tur. Browserless, KEEP_ALIVE konusunda, “v2 v1 bayraklarınızı görmezden gelir” gibi kaba bir özetten daha dürüst davranıyor.

Artılar ve eksiler

Artılar

• Belgede anlatıldığı gibi çalışan ve yapılandırmayla birlikte hareket eden kabul kontrolü — üç farklı tavanda, hem istemci durum kodlarında hem de sunucunun kendi muhasebesinde doğrulandı.
• /pressure, üç kısa koşuda istemcinin gördüğü çalışan, kuyruktaki ve reddedilen sayılarla eşleşti; bunu otomatik ölçeklendirme ve alarm için aday bir girdi olarak değerlendirin.
• İstemci tarafında otomasyon kodu olmadan gerçek Chromium render’ı: tek bir kimlik doğrulanmış POST, statik fetch’in göremeyeceği JS-eklenmiş DOM’u görünür kıldı.
• 30 oturumluk ardışık çalışmada biriken Chrome süreci gözlenmedi; koşu sonunda 0 Chrome süreci ve 0 zombie vardı.
• Bir TIMEOUT denemesi, 5.000 s bütçeye karşılık 5.007 s’de 408 döndürdü; temizleme ve slot bırakma ayrıca doğrulanmadı.
• Kimlik doğrulama varsayılan olarak açık: dört REST uç noktasının hepsi token olmadan 401 döndürüyor.
• Hazır servise yaklaşık 0.78 s’de ulaşan tek bir docker run ve ardından 0.32 s’de ilk render.

Eksiler

• 4.34 GB imaj. Bu dürüst başlık maliyetidir; registry’nizde, CI önbelleğinizde ve soğuk dağıtım sürenizde görünür.
• SSPL-1.0 veya Browserless ticari lisansı. Mevcut şartları dağıtım ve yaygınlaştırma modelinize göre değerlendirin.
• v1’den gelen PREBOOT, v2’de sessizce kabul edilip yok sayılır — hata yok, uyarı yok, /config anahtarı yok.
• Bir bağımlılık eklemiyorsunuz, bir servis işletiyorsunuz: konteyner, token, ağ yolu, kabul sınırı ve yükseltme sorumluluğu.
• Kuyruğa alınan istekler, (2, 2) koşusunda uçtan uca gecikmeyi yaklaşık iki oturum süresine çıkardı; ayrı kuyruk bekleme süresi ölçülmedi.
• Ölçülen REST zamanlaması bir HTTP adımı içeriyor ve tarayıcı başlatma maliyetini izole etmiyor ya da tarayıcı yeniden kullanımını kanıtlamıyor.

Kimler kullanmalı, kimler kullanmamalı?

Browserless, birden fazla şeyin tarayıcıya ihtiyacı olduğunda gerçek değerini gösterir. Birkaç uygulamanın ortak kullandığı bir render servisi, her servisin içine Chrome bağımlılığı koymak yerine HTTP uç noktası arkasında screenshot ve PDF isteyen bir ekip, kapasite sınırı ve ölçülebilir backpressure gerektiren bir iş hattı — bu ürün tam da bu şekle uyar. Zaten Docker çalıştırıyorsanız ve dağıtımı birisi sahipleniyorsa, operasyon hikâyesi nettir: öngörülebilir kabul, gözlemlenebilir backpressure ve 30 oturumluk ardışık kontrolde biriken Chrome süreci ya da zombie gözlenmemesi.

Ayrıca yığınınızdaki her servisin kendi Chromium’unu kurması alternatifi varsa da doğru seçimdir. Bunu tek bir konteynere, bir token’a ve bir tavana toplamak gerçekten iyi bir mimari takastır.

Tek bir script yazıyorsanız geçin. Bir Python dosyasının render edilmiş bir sayfayı alabilmesi için 4.3 GB çekip konteyner çalıştırmak, küçük bir iş için fazla törendir — process içi bir tarayıcı kütüphanesi bunu ayrı bir servis dağıtımı olmadan yapar. Ticari ürününüz için SSPL şartları uygun değilse ve çözemiyorsanız geçin. Gerçekte istediğiniz şey önceden ısıtılmış, soğuk maliyeti olmayan bir tarayıcıysa yine geçin; çünkü v2’de PREBOOT size bunu vermez. Asıl probleminiz anti-bot işlemleri ise, bunu bilerek test etmediğim ve kefil olamayacağım bir uç noktada arıyorsunuz demektir.

Alternatifler ve Thunderbit’in konumu

Karşılaştırılması gereken şey Browserless’i başka bir konteynere karşı koymak değil. Tarayıcının nerede yaşadığı ve onu canlı tutmaktan kimin sorumlu olduğu.

İlgili inceleme: Browsertrix Crawler incelemesi.

İlgili inceleme: chromedp incelemesi.

Kendi process’inizin içinde bir tarayıcı istiyor ve beklemeleri yazmaya aldırmıyorsanız, bir kütüphane daha hafiftir ve ayrıca bir dağıtım gerekmez. Bu tarafı Playwright ile Puppeteer karşılaştırması ve daha geniş açık kaynak scraping proje özeti içinde anlattım.

Hiç tarayıcı işletmek istemiyorsanız, bizim Thunderbit çözümümüz yönetilen bir alternatiftir. Browserless, render edilmiş materyali döndürür ve bunu kodunuz yorumlar; Thunderbit ise rendering altyapısının sorumluluğu sağlayıcıda kalırken Markdown veya şema eşleşmeli veri döndürebilir. Bu yazı Thunderbit’in gecikmesini, kapasitesini, hata davranışını, çıkarım kalitesini veya maliyetini benchmark etmedi; bu yüzden tablo performans karşılaştırmasından çok sorumluluk sınırlarını anlatır.

Aynı test turundan ilgili okuma: Crawl4AI incelemesi sizin çalıştırdığınız tarayıcı destekli bir Markdown hattını ele alır; web scraping tools genel bakışı ise daha geniş kategori haritasını verir.

Web Veri Çıkarımı için Thunderbit’i Deneyin

Sonuç

Browserless çalıştırmalı mısınız? Evet — eğer birden fazla çağıran tarayıcı işine ihtiyaç duyuyorsa, konteyneri işletebilecek biri varsa ve lisans incelemeniz dağıtım modelini onaylıyorsa. Üç sentetik kabul koşusunda, kabul edilen sayı CONCURRENT + QUEUED ile eşleşti, aşım 429 aldı ve /pressure istemcinin gördüğü sayılarla uyumluydu. Ayrı bir 30 oturumluk ardışık kontrolde, biriken Chrome süreci veya zombie gözlenmedi. Bir zaman aşımı denemesi, yapılandırılmış sınıra yakın bir anda 408 döndürdü. Bunlar faydalı, sınırları belirli gözlemler; evrensel garantiler değil.

Yine de taahhüdü dürüstçe boyutlandırın. Bu, 4.34 GB’lık bir imaj ve sizin işlettiğiniz bir servistir; eklediğiniz sıradan bir bağımlılık değildir. Bu test, process içi bir tarayıcı kütüphanesiyle hız kıyası yapmadı. Size kazandırdığı şey, rasyonlayabileceğiniz bir tarayıcıdır: bilinen bir tavan ve ölçülebilir backpressure. 30 oturumluk ardışık kontrolde biriken Chrome süreci veya zombie gözlenmedi. Maliyetler dağıtım ağırlığı ve okumanız gereken lisanstır. Tek bir script’ten birkaç sayfa render ediyorsanız bu takas karşılık bulmaz. Birden fazla servisin bağlı olduğu bir render katmanı işletiyorsanız bulur — yalnız v1 environment değişkenlerinizi içeri alırken bir kez daha kontrol edin, çünkü PREBOOT içeride çalışıyor gibi görünürken aslında hiçbir şey yapmayacaktır.

Web Veri Çıkarımı için Thunderbit’i Deneyin Get Started Free

SSS

Browserless headless Chrome’u hızlandırır mı? Bu test bunu yanıtlayamaz. HTTP uç noktası docker run’dan 0.78 s sonra yanıt verir hale geldi; ilk /content çağrısı 0.32 s sürdü ve aynı konteynerde sonraki çağrılar yaklaşık 0.15 s oldu. Bu rakamlar bir HTTP gidiş-dönüşü, tarayıcı işi, gezinme ve yanıt aktarımını birlikte içerir. Test düzeneği başlatma süresini ayırmadı, süreç yeniden kullanımını izlemedi ve benzer bir process içi benchmark yayımlamadı. Browserless’i paylaşılan servis sınırı ve kabul kontrolü için kullanın; sonra kendi gecikme yolunuzu benchmark edin.

Browserless’in eşzamanlılık sınırını aşarsanız ne olur? Anında HTTP 429 alırsınız. Tavan tam olarak CONCURRENT + QUEUED’dir ve bunu üç yapılandırmada doğruladım: (2,2) 4 kabul etti ve 4 reddetti, (3,5) 8 kabul etti ve 4 reddetti, (5,5) 10 kabul etti ve 4 reddetti. Sunucunun /pressure uç noktası her seferinde eşleşen running, queued ve recentlyRejected sayılarını verdi. Bilmekte fayda var: kuyruktaki istekler başarısız olmaz, bekler — (2,2) ve 5 saniyelik iş yükünde başarılı yanıtlar 5.7 s ile 11.0 s arasında geldi. İstemcinizi 429’u backpressure olarak görüp retry ve backoff uygulayacak şekilde kurun.

PREBOOT Browserless v2’de hâlâ çalışıyor mu? Hayır. PREBOOT, 2.0.0 sürümünde kaldırıldı ve v2, -e PREBOOT=true değerini hiçbir hata ya da uyarı vermeden kabul edip onunla hiçbir şey yapmıyor. Bu etkisizliği üç yoldan doğruladım: gecikme varsayılandan ayırt edilemiyordu, boşta çalışan PREBOOT=true konteynerinde bekleyen 0 chrome süreci vardı ve /config içinde hiç preboot anahtarı görünmüyordu. Eğer bir v1 yapılandırmasını taşıdıysanız, örnekleriniz önceden ısıtılmış değildir. Aynı sürümde kaldırılan KEEP_ALIVE ise bir “deprecated and ignored” uyarısı kaydediyor — yani sessiz başarısızlık problemi özellikle PREBOOT’a özgü.

Browserless ticari kullanım için ücretsiz mi? Depo, SSPL-1.0 veya Browserless ticari lisansı sunuyor; ancak bu yazı belirli ticari veya kapalı kaynak senaryoları bu seçeneklerden birine eşleştirmiyor. Mevcut LICENSE ve resmî dağıtım rehberini inceleyin, ardından yazılım lisanslamasından sorumlu kişinin dağıtım ve yaygınlaştırma modelinizi değerlendirmesini sağlayın.

Browserless geride zombie Chrome süreçleri bırakır mı? Test edilen kısa pencerede birikmediler. 30 ardışık oturumdan sonra konteynerde 0 Chrome süreci ve 0 zombie vardı; yalnızca dumb-init, node, Xvfb, start.sh ve sh kalmıştı. Dedektör, bir oturum canlıyken 11 chrome-family süreci sayabildi; yani kör değildi. Konteyner belleği 294 MiB’den 303 MiB’ye çıktı ve ardından örneklerde plato yaptı. Bu, çok saatlik, eşzamanlı veya binlerce oturumluk bir dayanıklılık sonucu değildir.