[kpihus]

Oleks tarvis veebiserveri PHP osa koormus testida. Sestap on vaja üht lihtsat, aga koormavat PHP skripti.
Oskate ehk mõne hea näite tuua ?

[Mnator]

Modifitseeri siin postis pakutu enda tarbeks https://foorum.hinnavaatlus.ee/viewtopic.php?p=7312497#7312497

[LKits]

Javascript on kliendpoolne.
Aga jah - tee mõni koormav käsk ja viska loop-i - usun, et siis jookseb nii mõnigi server kokku. Ära ainult üle pinguta ja ära unusta logida, sest muidu ei tea, miks kokku jooksis.
Ei ole küll lähemalt tutvunud, aga üks koormavaid võib olla mingist failist andmete lugemine muutujasse.

[Mnator]

Nojah, oleneb kus kohast ja mil moel ta koormata tahab...

[Ho Ho]

[LKits]

Arvan, et ta tahab CPU-d koormata.
Leia mingi räige valem, mis nõuab räigelt arvutusvõimsust ja viska loop-i.

[Ho Ho]

[Redikate]

max_cpu.sh

[Ho Ho]

Kas mitte too skript ei jää pigem IO taha ootama ning ehkki proset näidatakse 100% peal siis reaalselt ta lihtsalt ootab?

[Redikate]

[troglodyte]

Ka output on IO

Prose jõuab seda counterit suurendada kiiremini kui see output sinuni jõuab üle võrgu või terminal seda kuvada suudab või faili suunates ketastele jõuaks kirjutada.

[Redikate]

[LKits]

Miks mitte lihtsalt "$x=rand()" vms sinna loopi sisse visata? Või mingi "$x=sqrt(rand(2,999999),1 / rand(1,999999))" - see peaks juba midagi koormama.

[Ho Ho]

Skriptikeele puhul on üsna suva mida sa sinna "koormuseks" sisse kirjutad, lõviosa ajast läheb ikka stringide parsimisele ning prose ei saa normaalse kasutusega kaugeltki võrreldavat koormust.

OP'd veelkord lugedes tekkis mõte, et ehk on tal miski custom kompileeritud PHP seal servus jooksmas ning soovib teada kui hästi too suudab asju jooksutada. Igal juhul on selgeks saanud, et hetkeseisuga pole kaugeltki piisavas koguses infot vajaduste kohta millegi mõistliku soovitamiseks.

[Kymps]

Kas Pi arvutamine ei sobiks?

[LKits]

Suvalisest arvust suvalise juure võtmine peaks vist rohkem ressurssi raiskama.

[Ho Ho]

Jeebus küll. Juure arvutamine on vähegi kaasaegsemale arvutile mõnikümmend prosetakti. Tolle käskluse lahti intepreteerimine kümneid tuhandeid. Tulge maa peale tagasi ning testige asju mis ka midagi reaalset näitavad. Hetkeseisuga soovitate veebiservu jõudlust superpi'ga mõõta

[kpihus]

Tõsi ta on, infot oli pisut vähe. Kuna Apache tuunimisega olen vist enam vähem lõpule jõudnud on järg fcgid käes. Idee oli nimelt tekitada skript mis prosele pisut koormust tekitab (aga samas päris kooma ei tõmba) siis Jmeter selga lasta, ning fcgid parameetreid tuunida ja jälgida, kuidas kõige parema CPU koormuse ja requestide vahekorra saaks. St PHP poole pealt peaks olema üks ja sama skript, mis ei sõltu välistest teguritest (ketas ja mysql). Ise mõtlesin, et ehk arvutaks rekursiooniga fibonacci jada (mingit mõistliku pikkust).
Lisaks võiks muidugi katsetada ka mõnd PHP Cache vahendit.

[Ho Ho]

Endiselt on liiga vähe infot. Vaja on teada mis on suurem eesmärk miks seda tuunimist teed. Ühe kaupa mõttetute skriptidega üksikuid komponente koormates ei jõua kusagile kuna nood mõttetud skriptid ei koorma tarkvara komponente kaugeltki sarnaselt kui reaalsed rakendused. Samuti jääb täielikult vaatlusest välja märksa olulisemad asjad a'la php-sql'i vaheline suhtlus ning selle efektiivsus.

[kpihus]

[Ho Ho]

Sõltub mida ja kuidas salvestad. Kui lihtsalt ilma igasugu kontrollita raw datat kettale kirjutad on see igal juhul kiirem andmebaasist. Muidugi hilisem andmete lugemine-otsimine-töötlemine on suure tõenäosusega aeglasem andmebaasist.

[kpihus]

[Fukiku]

Minu talupojaloogika ütleks, et kallim on siiski baasi kirjutamine, sest lisaks andmetele kirjutatakse terve hunnik metaandmeid ju ka juurde sinna, et see asi odavalt ja kiiresti hiljem leitav oleks. Lisaks veel kogu maagia mida kulisside taga tehakse, et andmete korrektsust kontrollida ja tagada äkiliste äparduste ootuses.

[napoleon]

Selge see, et otse kettale või failisüsteemi kirjutamine on kiirem. Küsimus on vaid selles, et kirjutamisel pole mõtet kui keegi neid andmeid hiljem kätte saada ei taha ja baasist kättesaamine on tunduvalt "odavam". See on ka põhjus, miks rakenduse andmeid enamasti baasis hoitakse, aga logifailid(mida loetakse tunduvalt harvemini ja enamasti pole oluline, kas töötlemine 1, 10 või 100 sekundit võtab) kirjutatakse enamasti faili.

[kpihus]