JSF gerçekten yüksek performanslı web uygulamaları sunmaya hazır mı? [kapalı]


16

JSF hakkında çok iyi duydum ama bildiğim kadarıyla insanların geçmişte bu teknoloji ile ilgili çok ciddi şikayetleri vardı, durumun ne kadar iyileştiğinin farkında değillerdi. JSF'yi bir sosyal ağ projesi için olası bir teknoloji olarak görüyoruz. Ancak JSF'nin performans puanlarının farkında değiliz, ne de JSF kullanan mevcut herhangi bir yüksek performanslı web sitesine gerçekten rastlayamadık. İnsanlar performans ölçeklenebilirliği sorunlarından şikayetçidir.

Jsf'yi seçerek doğru şeyi yapıp yapmadığımızdan hala emin değiliz ve bu nedenle sizden tüm bunları duymak ve girdilerinizi dikkate almak istiyoruz.

JSF'yi sosyal ağ hizmetinin yüksek performans ihtiyaçlarını karşılayacak şekilde yapılandırmak mümkün müdür? Ayrıca JSF'deki mevcut problemlerle ne ölçüde hayatta kalmak mümkündür. Sorunları tam olarak nedir?


Ben am değil benim kişisel deneyim göre ben hepsi doğru değil inanması nedeniyle diğerleri genellikle şikayet neyi JSF ile geliştirme karmaşık endişe, ama ben daha fazla ne performans ve ölçeklenebilirlik sorunları hakkında endişe duyuyorum. Ve lütfen sadece önceki sürümlerle bağlantılı eski sorunlarda kötüye kullanmayın. Geçmişi ne olursa olsun şimdiki durumu umursuyorum.


7
ptrthomas.wordpress.com/2009/05/15/jsf-sucks JSF baş mimarı tarafından her kararı haklı çıkaran bir yanıt olduğunu biliyorum, ama bana göre, bazı web teknolojilerini bilen ve acı çeken biri, JSF ile bile 2.0, Facelets ve SEAM, bu alaycı. James Gosling bile: "JSF'yi bir tutkuyla nefret ediyorum." Wicket veya Goblen kullanırım ve JSF ve problemlerinden tamamen kaçınırdım.
Falcon

12
@ ThorbjørnRavnAndersen Nazikçe sana katılmıyorum. Ben sadece "JSF nefret ediyorum" demekten daha fazla açıklama yapmak daha iyi olduğunu düşünüyorum
Chiron

6
@ ThorbjørnRavnAndersen Ne demek istediğini anlıyorum ama insanları daha fazla bilgi sağlamaya gerçekten teşvik ediyorum. Örneğin, yorumu olmayan bir aşağı oy her zaman beni rahatsız eder.
Chiron

3
@Chiron, soru JSF'nin kullanılabilir olup olmadığı değil, JSF'nin gerçekleştirilip gerçekleştirilemeyeceğidir. Çerçeveyi indirerek başlayan insanlar büyük olasılıkla asıl soruya cevap veremezler. Bir JSF uygulamasını kendim sürdürdüğümde, ben de bilmek istiyorum.

3
> James Gosling bile: "JSF'yi bir tutkuyla nefret ediyorum." - JSP demek istediği için bunun bir hata olduğu iyi biliniyor. Söz konusu parçayı dikkatle dinleyin. Klasik ASP'ye yanıt olarak oluşturulan şeyle ilgilidir ve bu JSF değil, JSP idi.
Arjan Tijms

Yanıtlar:


24

JSF kesinlikle yüksek performanslı web uygulamaları sunabilmektedir. Şu anda üzerinde çalıştığım uygulama tamamen JSF ve günlük istatistiklerinden DB olmayan yoğun sayfaların minimum yürütme süreleri 0 ms ve ortalama süreleri 10 ms'den az olduğunu görebilirsiniz.

Wicket'lerden bazıları JSF'nin performansı hakkında bir şeyler söylüyorlar, ancak bu ayrıntılı karşılaştırmaya göre JSF aslında Wicket'ten daha iyi performans gösteriyor: http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx-edition/

Sunucu doygun olmadığı sürece JSF'nin GWT'den daha iyi performans gösterdiğine dikkat edin. GWT / JSF kıyaslama karşılaştırması zordur, çünkü GWT sunucusunun ayrıca JSF'nin yaptığı postback'teki verilerin dönüşümünü ve doğrulamasını yapması gerçekten önemlidir. Bu pratikte dışarıda bırakamayacağınız bir şeydir (asla müşteriye güvenmeyin). Ayrıca, GWT ve JSF / Wicket grafikleri için, tarayıcının oluşturma adımının JSF / Wicket için önemsiz olduğu dikkate alınmalıdır (çoğunlukla render için hazır HTML sundukları için), ancak GWT istemcisinin hala bazı çalışmaları vardır. sunucu yanıtı aldıktan sonra yapın.

Eski JSF sürümlerinin (2.0 öncesi) sahip olduğu önemli performans / ölçeklenebilirlik sorunlarından biri, içine çok fazla veri koyarak devlet tasarrufunu kötüye kullanmaktı. Kesinlikle orada bulunmaması gereken şeyler (içinde olduğu gibi 'foo' gibi sabitler gibi <my:tag attribute="foo"/>).

JSF 2.0 partial state saving, yalnızca delta durumunun kaydedildiği anlamına gelen mekanizmayı tanıttı . Pratikte bu çok az olabilir ve JSF 1.x ile karşılaştırıldığında iki büyüklükte küçülme nadir değildir.

JSF yıllarca kullandıktan sonra, JSF 1.x'te çok fazla durum kaydetmek dışında, JSF ile ilişkilendirebileceğim hiçbir performans sorunuyla karşılaşmadım diyebilirim. Şimdiye kadar karşılaştığımız performans sorunları her zaman DB'ye ve / veya arka uç hizmetlerini nasıl kurduğumuz, sorgularımızı yazdığımız vb.


1
0 ms ... Bence ölçüm araçlarına bakmak gerekiyor.
gbjbaanb

2
@gbjbaanb Sanmıyorum, bunlar oldukça profesyonelce hazırlanmış istatistiklerden geldi. Minimum zaman ve DB olmayan sayfalar hakkında konuştuğumu unutmayın . Böyle bir zamanda yürütülen sayfalar, 100'ün üzerine yayılmış 1000 bileşen içermiyordu. Burada nispeten basit sayfalardan bahsediyoruz, belki 10 bileşen, 1 ana şablon, belki 1 içerir, bir süredir çalışan bir sunucuda her şey sıcak ve bellektir. Ortalama süre daha yüksek (bahsettiğim gibi 10 ms) ve% 90 daha yüksek. Max her şey olabilir.
Arjan Tijms

Durum şu ki, bu dünya sadece tüm problemleri çözebilecek şeyleri eleştiriyor. Ancak tüm problemleri çözmenin her zaman bir bedeli vardır ve büyük bir gayret ve coşku gerektirir. Takımlarda gördüğüm şey, yaşam döngüsünü bile anlamadan gelişmeye başlamasıdır. Dik bir öğrenme eğrisi içerir, ancak hem güzel hem de dikkat çekici.
Shirgill Farhan

Darboğaz, veritabanından / IO ve bant genişliğinde (mobil ...) sunucunun kendisinden daha olasıdır. Java, iyi kullanıldığında gerçekten hızlıdır.
Christophe Roussy

8

Dünyadaki tüm teorik JSF'nin harika olduğunu söyleyebilir, ancak sayfalarınızın nasıl göründüğüne bir göz atın. JQuery veya temiz CSS kullanımı gibi modüllere ekleme yeteneğinizi ciddi şekilde engelleyen dev javascript yığınları ve diğer saçmalıklar üretir. Bunun yapılamayacağını söylememek, ama ne pahasına olursa olsun.

Nispeten küçük bir proje ve orta karmaşıklıkla kişisel deneyim. Bir felaket. Tüm geri aramalarla uğraşan bir karmaşa vardı ve diğer teknolojilere kolayca karışamazsınız. JSF ile karışık JSTL kullanırken ortaya çıkan büyük bir hata vardı. HER bağlantının javascript geri çağrısı olması nedeniyle tüm jQuery öğelerini asla kullanamadık.

Kaç ve hızlı kaç.

Ayrıca ölçek derken, ne tür bir ölçek hakkında konuşuyorsunuz. Sayfa sayısı, kullanıcı sayısı, saniye başına istek sayısı, özellik sayısı. Bunların cevapları size yardımcı olabilir. Ayrıca birisi size bunu ölçeklendirmesi gerektiğini söylediğinde, onlara ne derece ve ne kadar hızlı olduğunu sorun. Cevap size çok yardımcı olacaktır. Bir hafta içinde google ölçeği veya bir yılda günde yaklaşık 1000 kullanıcı ve 10000 sayfa görüntüleme hakkında konuşuyorsanız.

Hemen hemen arka planda gerçek zamanlı yanıtlar yazdığınız herhangi bir çerçeve, kullanım durumlarının% 99,999'unu karşılayacak şekilde ölçeklendirilecektir.


3
Herhangi bir çerçeve ölçeği için -1. Bu, "performansı önemsemeyin" demek gibidir.
Raynos

3
Kendi başlarına tek başına yayınlanan JSF de dahil olmak üzere web çerçevesi ölçeklendirilecektir. Hepsi yaptıklarını söylüyorlar, olmasaydı oldukça berbat bir çerçeve olurdu. Bununla birlikte, birçok insan onunla aptalca şeyler yapar ve genellikle ölçekleme sorunlarının ortaya çıktığı yerdir.
Bill Leeper

1
doğru, ancak bazı çerçeveler, ya çerçeve teşvik ettiği ya da topluluk bunu teşvik ettiği için engelleme ile bir şeyler yapmanızı teşvik eder. Bu çerçevelerin ölçeklenmediğini iddia ediyorum.
Raynos

"Ölçeklendirmeyi nasıl ölçersiniz" biti belki de soruya bir yorum olmalıdır?

4

Feragatname: JSF'yi seviyorum. Her neyse, en son RI (Mojarra 2.2.x) veya MyFaces ile bile, uzun zamandır beklenen vatansız uygulama performansı ile bile çok düşük. Bunun nedeni JSF yaşam döngüsü ve her Görünümün (isteğe bağlı olarak) her istek için oluşturulmuş olmasıdır.

Bir ipucu elde etmek için, bu düz bir java sunucu uygulamasına karşı JSF sayfasına karşı basit bir ölçüttür, her ikisi de sadece "merhaba dünya"

Servlet

glassfish-3.1.2.2$ ab -n 10000 -c 100 http://localhost:8080/mavenproject-web/NewServlet

Server Software:        GlassFish
Server Hostname:        localhost
Server Port:            8080

Document Path:          /mavenproject-web/NewServlet
Document Length:        128 bytes

Concurrency Level:      100
Time taken for tests:   0.970 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      4300000 bytes
HTML transferred:       1280000 bytes
Requests per second:    10307.02 [#/sec] (mean)
Time per request:       9.702 [ms] (mean)
Time per request:       0.097 [ms] (mean, across all concurrent requests)
Transfer rate:          4328.14 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.0      1       5
Processing:     1    9   4.6      8      51
Waiting:        1    8   4.4      7      40
Total:          4   10   4.1      8      51

Percentage of the requests served within a certain time (ms)
  50%      8
  66%     10
  75%     11
  80%     11
  90%     12
  95%     14
  98%     29
  99%     33
 100%     51 (longest request)

MTU

glassfish-3.1.2.2$ ab -n 10000 -c 100 http://localhost:8080/mavenproject-web/xhtml/test/jsf.xhtml

Server Software:        GlassFish
Server Hostname:        localhost
Server Port:            8080

Document Path:          /mavenproject-web/xhtml/test/jsfxhtml
Document Length:        100 bytes

Concurrency Level:      100
Time taken for tests:   4.676 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      4250000 bytes
HTML transferred:       1000000 bytes
Requests per second:    2138.60 [#/sec] (mean)
Time per request:       46.759 [ms] (mean)
Time per request:       0.468 [ms] (mean, across all concurrent requests)
Transfer rate:          887.60 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       6
Processing:     5   46   6.0     46      73
Waiting:        2   45   5.5     45      72
Total:          8   47   5.8     46      73

Percentage of the requests served within a certain time (ms)
  50%     46
  66%     48
  75%     50
  80%     51
  90%     54
  95%     56
  98%     60
  99%     62
 100%     73 (longest request)

1
Basit bir dünya sayfasının temsili veya anlamlı olabileceğini düşünmüyorum. Ciddi bir karşılaştırma, sürüm numaraları, kullanılan yapılandırma ve benzeri gibi gerekli bilgileri sağlamalıdır. Lütfen önceki bir cevapta JSF ve Wicket arasındaki karşılaştırmayı okuyun.
lu4242

Kabul etmeme izin ver. En basit durumsuz bağlamda jsf'nin jsp'den 5 kat daha yavaş olduğu gerçekten anlamlı buluyorum. Daha karmaşık senaryolarda jsf performansının kötüleştiğini doğrulamak önemsizdir. Veya en tembel :-) için daha fazla kriter sağlayabilir :-) jsf uygulama yukarıda belirtildiği gibi mojarra 2.2, glassfish 3 ile
gpilotino

"... jsf jsp 5 kat daha yavaş ..." Bence burada hata verimi ve jsp vs jsf altında yatan davranış dikkate almaz olduğunu düşünüyorum. Açıklamak çok karmaşık, ancak bu durumda, yanıt süresi açıkça daha yavaştır, çünkü jsf, jsp'nin sahip olmadığı bir eşzamanlılık etkisine sahiptir. Ancak sonunda saniyedeki döngüleri karşılaştırmak daha doğru olur. Ayrıca, Mojarra MyFaces ile aynı değildir, bu nedenle her iki uygulamanın performans açısından farklı sayıları vardır. Bu durumda eşzamanlılık efektinin abartılı olduğuna dikkat edin.
lu4242

Aslında, düz bir sunucu uygulamasını JSF ile karşılaştırmak tamamen saçmadır. Mantıklı olan tek karşılaştırma JSP / servlets ve JSF kullanarak tamamen aynı olan başka bir "uygulama" kullanılarak yapılan bir "uygulama" dır. Neden? çünkü JSF, işleme / ajax / navigasyon / doğrulama için yerleşik çözümler sağlar, sıfırdan veya JSP'de elle yapılması gereken şeyler. Karşılaştırma performans açısından ilginç olsa bile (hiçbir çerçeve servlet / jsp'den daha hızlı olmayacaktır), JSP JSF ile eşleşmez, çünkü JSF'nin sizin için yaptığı küçük bir parça bile yapmaz.
lu4242

"Sade bir sunucu uygulamasını JSF ile karşılaştırmak tamamen saçma". hayır değil. her iki teknolojinin de içerik sunması gerekiyor. Bu nedenle, validasyon ve diğer şeylerin sayılmadığı durumsuz durumları hesaba katıyorum. "Yanıt süresi açıkça daha yavaş çünkü jsf jsp sahip olmadığı bir eşzamanlılık etkisi vardır" bu bir ölçeklenebilirlik sorunu kendisi değil mi? MyFaces hakkında, afaik Mojarra etrafında en hızlı uygulama var: (i araştırılacak)
gpilotino

3

JSF'nin nasıl performans gösterdiğini daha iyi anlamak istiyorsanız (hem Mojarra 2.1.7 hem de MyFaces 2.1.7) ve bunu Apache Wicket (1.4.20 ve 1.5.5) gibi benzer bir çerçeveyle karşılaştırmak istiyorsanız, buna bakın. derin karşılaştırma (MAYIS 2012):

JSF 2 ve Wicket'i Anlamak: Performans Karşılaştırması

İyi olan her şey mevcut (kod, deneysel veriler, testin nasıl yeniden üretileceğine dair talimatlar, ayrıntılı bir rapor). JSF performansı hakkındaki tüm sorularınızı çözecek ve Apache MyFaces'in neler yapabileceğini göreceksiniz.


3

Biraz yardımcı olabilecek bir makale (gerçekten kesin olmasa da) Sunucu Merkezli Java Çerçeveleri: DZone Javalobby'de Performans Karşılaştırması :

... Bu makalede, SPI Java web çerçevelerinin çoğunun sunucu tarafından sağlanan kısmi değişikliklerde ne kadar etkili olduğu gözden geçirilmektedir. Sunucu iletişimi olmayan olaylarla, yani (olası) sunucu kontrolü olmayan olaylarla ilgilenmiyoruz.

Nasıl ölçülecekler

Müşteriye yapılan görsel değişiklikle ilgili olarak müşteriye gönderilen kod miktarını ölçeceğiz .

Örneğin, bir bileşendeki küçük bir görsel değişiklik (bazı yeni veriler) için sunucudan çok fazla kod beklemiyoruz, yani düz HTML olarak gerekli olan veya JavaScript'e gömülü yeni biçimlendirme veya yeni verileri içeren bazı üst düzey talimatlar bekliyoruz. canlandırdım. Aksi takdirde, bir şey yanlış görünüyor, örneğin tüm bileşen veya sayfa bölgesi yeniden oluşturuluyor, bant genişliği ve istemci gücü (ve belki de sunucu gücü) harcanıyor.

Halka açık demoları kullanacağımız için, kesin ve ince bir tahıl ölçütü elde etmeyeceğiz . Ancak çerçeveler arasında çok güçlü farklılıklar göreceksiniz.

Test tekniği çok kolaydır ve herkes bunu özel bir altyapı olmadan yapabilir, sadece FireFox ve FireBug'a ihtiyacımız var. Bu testte FireFox 3.6.8 ve FireBug 1.5.4 kullanılır.

"XMLHttpRequests Göster" etkinleştirildiğinde FireBug Konsolu, sunucu yanıtını gösteren herhangi bir AJAX isteğini günlüğe kaydeder ...

Test edilen çerçeveler

RichFaces , IceFaces , MyFaces / Trinidad , OpenFaces , PrimeFaces , Vaadin , ZK , ItsNat

... görünüşe göre ciddi performans cezaları olmayan tek JSF uygulaması PrimeFaces ...

(Performans için) uygun bir karşılaştırma bulamadım, eğer biri bulursa onu görmek isterim!


2

Genel olarak IMHO'nun kullanımı oldukça rahatsız edici olan Facelets ile ilgili bir sorun var. Gerçekten gerekli olandan dört kat daha garip ve ilkel bir şeyden bir adım attıktan sonra çok fazla manuel çalışmaya ihtiyacınız var. HybridJava , JSF içinde sunum motoru olarak Facelets için iyi bir yedek olacaktır - aynı işi (ve daha da fazlası, özellikle de tüm "bağlamaları" ve kimlikleri sizin için) çok daha az tuş vuruşuyla yapar.


1

Bu yüzden benzer bir ölçüt atmak istedim. Bir twitter bootstrap örnek sayfası aldım ve xhtml katıya dönüştürdüm. Bundan sonra, Hello, World'ü döndüren tam bir ApplicationScoped CDI fasulyesi kurdum. EL ifadesini sayfaya koydum. JSF sürümü için JSF kaynak işleyicisini kullandım, JSPX sürümü için HTML tarzı css kullandım ve js içerir.

Ana sayfa yükleme süresini test etmek için apache bench'i kullandım. Test, optimize edilmemiş bir TomEE + v1.5.2 sunucusunda gerçekleştirildi. Her bir ölçütü 5x çalıştırdım, sonra bir ölçüm yapmadan önce tam bir GC çalıştırdım. Bov testleri, JVM yeniden başlatılmadan aynı JVM örneğinde yapıldı. Libath üzerinde APR mevcut, ancak bunun bu testi etkilediğinden emin değilim.

Çok küçük miktarlarla uğraştığımız için JSF daha yavaş, ama çok değil. Ne değil sayfaları daha karmaşık olsun gösterdi olduğunu doğrusal veya katlanarak MTU / JSPX ölçeği yapar.

Fark ettiğim bir şey, JSPX'in JSF'ye kıyasla çok az çöp üretmesidir. Karşılaştırmayı JSPX sayfasında çalıştırmak, kullanılan yığının 184mb'den 237mb'ye atlamasına neden oldu. Karşılaştırmayı JSF sayfasında aynı JVM'de çalıştırmak, kullanılan yığının 108mb'den en az 404mb'ye atlamasına neden olur , ancak bu noktada otomatik bir çöp toplama başladı. Çöp toplayıcınızı JSF için ayarlamak kesinlikle bir zorunluluktur .

MTU

jonfisher@peanut:~$ /usr/local/bin/ab -n 10000 -c 100 http://localhost:8080/cdi-jsp/index.jsf
This is ApacheBench, Version 2.3 <$Revision: 1373084 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost
Server Port:            8080

Document Path:          /cdi-jsp/index.jsf
Document Length:        2904 bytes

Concurrency Level:      100
Time taken for tests:   2.138 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      32160000 bytes
HTML transferred:       29040000 bytes
Requests per second:    4677.27 [#/sec] (mean)
Time per request:       21.380 [ms] (mean)
Time per request:       0.214 [ms] (mean, across all concurrent requests)
Transfer rate:          14689.55 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.3      1      21
Processing:     1   20   9.0     18      63
Waiting:        1   19   8.8     17      62
Total:          2   21   8.8     20      64

Percentage of the requests served within a certain time (ms)
  50%     20
  66%     23
  75%     25
  80%     27
  90%     32
  95%     39
  98%     46
  99%     50
 100%     64 (longest request)

JSPX

jonfisher@peanut:~$ /usr/local/bin/ab -n 10000 -c 100 http://localhost:8080/cdi-jsp/page2.jspx
This is ApacheBench, Version 2.3 <$Revision: 1373084 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost
Server Port:            8080

Document Path:          /cdi-jsp/page2.jspx
Document Length:        2440 bytes

Concurrency Level:      100
Time taken for tests:   1.273 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      26290000 bytes
HTML transferred:       24400000 bytes
Requests per second:    7856.63 [#/sec] (mean)
Time per request:       12.728 [ms] (mean)
Time per request:       0.127 [ms] (mean, across all concurrent requests)
Transfer rate:          20170.98 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    5   2.3      6      20
Processing:     1    8   4.6      6      40
Waiting:        1    8   4.3      6      40
Total:          2   13   3.8     12      41

Percentage of the requests served within a certain time (ms)
  50%     12
  66%     12
  75%     13
  80%     13
  90%     17
  95%     20
  98%     24
  99%     28
 100%     41 (longest request)

-3

GWT, java kodunuzu java betiğine dönüştürür. böylece istemci tarafında bir java komut dosyası olarak çalışır. Ayrıca, css'yi gwt uygulamalarınıza entegre edebilirsiniz. Genel olarak, gwt hafiftir ve tüm tarayıcılarda sorunsuz çalışabilir. JSF hakkında fazla bir şey bilmiyorum. Ama bence dt, JSF GWT gibi esnek değil.


1
Çerçeve önerisi değil, JSF performansı ile ilgili soruya cevap vermez. Her neyse, GWT genellikle JavaScript bilmeyen insanlar tarafından beğeniliyor ^^
Danubian Sailor
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.