Live Site Üzerinde Trafik Stress Testi

[bingildak]

geçtiğimiz yıllarda celebrity tiplerle proje yaptığımızda sitenin aynı anda gelen 150-200 kullanıcı yüzünden göçtüğü örnekler yaşadık. şimdi önünmüzdeki hafta benzeri bir proje var, yüksek hacimde anlık trafik bekliniyor. ben hem yazılım tarafıyla hem de hosting tarafıyla bunun ön çalışmasını yaptım fakat iki tarafa da güvenemiyorum - birbiriyle geçinemeyen huysuz çocuklar gibiler. biri diğerine bok atıyor sürekli olarak. ikisinin argümanları da boş. bana güven vermiyorlar.

bu sebepten dolayı projeye start vermeden önce live site üzerinde trafik için stress test yapmak istiyorum, böyle bir tool var mı kullanabileceğimiz?

loadimpact.com denedim, 99 UV - 5 dk istediğim sonucu vermedi. benim istediğim reel kullanıcı gibi bir anda 150 bağlantıyı yaratıp aynı anda requestlerin çağrılmasını sağlamak.

geçen projelerde CPU şişip ISS patlamıştı, aynısı olacak mı ön bir çalışma yapmak istiyorum.

mümkünse yüzlerce dolar harcamadan.

[ViForVictory]

Oldu canım.

[µh]

buraya koy linki hayrına browserdan makroya bırakalım

[bingildak]

senkron edemeyiz 150-200 kişiyi

loadimpact.com'daki olayı tam anlamadım. trial hesap üzerinde 99 UV diyor. aktif olarak başlatıyorum testi, realtime bakıyorum analytics'ten US'den gelmesi gerekiyor trafik fakat gelmiyor. aktif kullanıcı sayısında bir artış oluyor ama çok düşük rakamlarda. bir bağlantıyı kapatıp diğerini mi açıyor acab?

[-Bonesoul-]

siege veya slam isine yaramaz mı?

https://www.npmjs.com/package/slam
https://www.joedog.org/siege-home/

saglam bir baglantı uzerınden calıstırırsan (ucuz yollu bir vps olabilir bu), bir fikir edinmeni saglar.

hatta su siege npm paketiyle yaratılacak trafigi kontrol bile edebilirsin once sunu yap, sonra suraya git vs. gibi.

https://www.npmjs.com/package/siege

[di]

ViForVictory said:

Oldu canım.

Madem ise yarar bisey demicen, bari hic konusma mudur ya. Baydin cidden.

[ViForVictory]

Sen de biraz beni baydın ya. Forumun yarısından fazlası 'boş' konuşuyor, benim yazdıklarım batıyor.

[bingildak]

halletik beyler, sağolun

[di]

Bak hala...

@bingildak kac kurus tuttu tum test onu da diyeydin.

[bingildak]

tespit mükemmel bir şekilde ücretsiz oldu (tu)

ama çözüm maliyetli olacak.

heads will roll :X

[-Bonesoul-]

ne kullandın, belki birilerinin isine yarar.

[di]

Onu da ben vereyim.

https://httpd.apache.org/docs/2.4/programs/ab.html

Cok detayli cikti gerekmiyosa gayet guzel is goruyo.

[-Bonesoul-]

ha ok ab. oda is gorur tabi.

[sardalya]

It's about caching.

Celebrity dediginin sitesi statik olur genelde, 3 dk'da cloudflare aktive edilir milyonlarca hite rahatlikla cevap verilir.

Gerci Microsoft server'la .NET'te falan yaziyorsaniz coksun daha iyi

[Lancelion]

shots, fired.

faydali degil ama tarzi sevdim +rep

[Laorx]

su ise yarayabilir

https://github.com/newsapps/beeswithmachineguns

said:

Bees with machines guns is a fabric script that I put together to aggressively load-test our sites. It provides methods to spin up an army of EC2 instances (the bees), assault a target server with a configurable amount of traffic, and then spin those instances back down.

Here is an example of what a Bees session might look like:

$ fab -f bees.py up:2
Connecting to the hive.
Attempting to call up 2 bees.
Waiting for bees to load their machine guns...
.
.
.
.
Bee i-df450ab4 is ready for the attack.
.
Bee i-dd450ab6 is ready for the attack.
The swarm has assembled 2 bees.
Done.

$ fab -f bees.py attack:http://YOUR-DOMAIN.com/,1000,100
Read 2 bees from the roster.
Connecting to the hive.
Assembling bees.
Each of 2 bees will fire 500 rounds, 50 at a time.
Stinging URL so it will be cached for the attack.
[localhost] run: curl http://YOUR-DOMAIN.com/ >> /dev/null
Organizing the swarm.
Bee 0 is joining the swarm.
Bee 1 is joining the swarm.
Bee 0 is firing his machine gun. Bang bang!
Bee 1 is firing his machine gun. Bang bang!
Bee 0 is out of ammo.
Bee 1 lost sight of the target (connection timed out).
Offensive complete.
Target failed to fully respond to 1 bees.
Complete requests: 500
Requests per second: 81.670000 [#/sec] (mean)
Time per request: 612.188000 [ms] (mean)
50% response time: 358.000000 [ms] (mean)
90% response time: 1541.000000 [ms] (mean)
Mission Assessment: Target successfully fended off the swarm.
The swarm is awaiting new orders.
Done.

$ fab -f bees.py down
Read 2 bees from the roster.
Connecting to the hive.
Calling off the swarm.
Stood down 2 bees.
Done.
(Note: Bees assumes you have AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY set as environment variables–just as you would if you were using the Amazon command line tools.)

Using the Bees I was able to verify that our new load-balanced and Varnished servers could handle a sustained load significantly beyond our requirements. Obviously this testing strategy doesn’t attempt to address all scenarios and it should be used in conjunction with traditional testing tools such as jmeter. That being said, it also provides a pretty interesting example of using EC2 to solve problems that can really only be properly addressed with distributed computing. This particular example is very well-suited to validating caching and scaling strategies.

[bingildak]

hallettik arkadaşlar bu konuyu, sorunu tespit ettik - çözdük - tekrar test ettik güzel sonuçlar aldık :)-D