Automatický web benchmark

[stewe]

napisal som si vlastny url shortener a potrebujem zistit jeho "vykonnost". pouzivam connection pooling a neviem sa rozhodnut medzi dbcp a c3p0, preto chcem spravit nejaky "benchmark", ktore riesenie kolko spojeni zvladne a za aky cas.

tu aplikaciu pisem uplne od zakladu aj s vlastnym http serverom, pouzivam http://www.simpleframework.org/

Jednoduchy benchmark, kolko spojeni som schopny obsluzit za aky cas, som robil cez apache utilitu ab, napr. s

Kód: [Vybrat]

ab -n 10000 -c 3 http://localhost:8080
problem je ale v tom, ze tento "benchmark" netestuje nic. Samotna stranka je uplne primitivna a pozostava z jedneho input pola so submit tlacitkom do ktoreho dam url link a po jeho stlaceni sa cez POST metodu spracuje na strane servera, ulozi do db, zostavi sa skrateny link atd.

Neviem ale, ako zautomatizovat vkladanie tej neskratenej URL adresy do toho input pola. Lebo to vlastne robi uzivatel samotny a rucne. Ja to potrebujem simulovat. Napady?

[Reklama]

[stewe]

dalsia otazka suvisi s tym, ako vlastne tie url adresy ziskat. dajme tomu ze chcem ulozit 100 000 url adries a meriam cas za kolko sa to vsetko stihne. Odkial tie testovacie url ziskat? Mam si ich nejako nahodne nagenerovat? Nenapada vas nejaka jednoducha metoda ako ziskat random url adresy z netu dlhsie ako napr. 100 znakov?

v kocke mi kazde spojenie obsluzi jeden http kontajner, kazdy kontajner sa obsluhuje v samostatnom threade, cez java.util.concurrent.Executors.newFixedThreadPool; odkial pri spojeni vytiahnem z poolu nejaky kontajner ...

[Mirek Prýmek]

Neviem ale, ako zautomatizovat vkladanie tej neskratenej URL adresy do toho input pola. Lebo to vlastne robi uzivatel samotny a rucne. Ja to potrebujem simulovat. Napady?

man ab - parametr -p

Odkial tie testovacie url ziskat? Mam si ich nejako nahodne nagenerovat?

Proč ne - nezáleží přece na tom, o tam bude.

[stewe]

cez ten -p prepinac to ide pekne, ale on vzdy zoberie len jeden riadok a tym konci

ked ten obsah suboru vyzera ako

Kód: [Vybrat]

url_input=url1&submit=short
url_input=url2&submit=short

takto spracuje len ten prvy link ... multiple data

[Mirek Prýmek]

No je to pitomý, že post data neumí vzít ze stdin. Lepší asi teda bude http://linux.die.net/man/1/siege - viz sekci "Url format".

[Reklama]

[DK]

kdyz pouzivas vlastni url shortener a chces zjistit vykonnost poolu, proc tam nevytvorit treba pole plne dat a neberes to z toho? (pak akorat zavolas tisikrat treba tu url, ktera to hned zpracuje)

[stewe]

spravil som to cez tu siege utilitu a toto su vysledky, does it sound legit?
V subore links.txt je 5000 linkov, vyzeraju nejako takto:

Kód: [Vybrat]

http://localhost:8080/ POST url_input=http://www.example.com/images/pic4501.jpg&submit=short


Kód: [Vybrat]

$ siege -f links.txt -c 4 --reps=once
** SIEGE 2.70
** Preparing 4 concurrent users for battle.
The server is now under siege..      done.
Transactions:        20000 hits
Availability:       100.00 %
Elapsed time:        48.77 secs
Data transferred:         8.77 MB
Response time:         0.01 secs
Transaction rate:       410.09 trans/sec
Throughput:         0.18 MB/sec
Concurrency:         3.97
Successful transactions:       20000
Failed transactions:            0
Longest transaction:         0.04
Shortest transaction:         0.00

410 trans/sec je pri prazdnej DB kedy sa to kazdy link musi ulozit. ked to spustim hned znova, cize tie linky uz tam vsetky su, takze sa nic neuklada, dostanem sa asi na 715/s a ked sa dotazujem na 5000 linkov (napr. takto http://localhost:8080/goto/3ed5d4 ) tak som s concurrency = 1 na 850/s ...

su tie cisla radovo uplne mimo ci je to normalne?

[stewe]

predchadzajuci benchmark bol s dbcp, vyskusal som aj to c3p0 a je to asi o patinu rychlejsie. Do cistej DB zapisuje asi 590 transakcii/s a pri citani je to dokonca cez 1000 ...

kazdopadne tam je milion parametrov s ktorymi sa to da optimalizovat ale na hrube rozhodnutie kam sa vybrat to hadam staci. c3p0 je ze vraj viac vhodne vo viac vlaknovom prostredi co sa mi asi dost hodi ...