hvala za mnenja, dokler od ponudnika ne dobir konktretnih podatkih je pe uranjeno razmiljati o zamenjavi, po zadnjem obvestilu so opomin dali na osnovi:

meritve top apache procesov in uporabo CPU

po zadnjih meritvah porabe časa(dodano na vsako podstran) je potrebno za nalaganje - sprocesiranje potreben čas od 0,02 sek do 2 sek(to se meni zdi normalen čas) - odvisno od funkcije, ki so izvedene - pretežno zapisovanje z mySQL. Ob tem ni jasno koliko je še aktivnih drugih procesov ob istem času.

Vprašanj je več: koliko to vpliva na stabilnost serverja, vpliv na odzivnost in procesiranje drugih procesov - "uporabnikov" - upočasnjenost itd.

Ker še niso poslali obljubljenega skana top procesov še bom malo počakal z odločitvijo - kaj sedaj???

sem dodal merjenje časa ter odklopil nekaj "nepotrebnih" klicev v mySQL, sedaj so časi kar užitni od 0.02 do 0.2 sek za nalaganje podstrani, v šahu pa še je vedno čas kar visok - pri zapisu potez do 2.5 sek nalaganje pa okoli 0.2 sek - vem pa da je danes nedelja. Bolj realni podatki bodo jasni v ponedeljek ali torek ko bo verjetno večji promet na strežniku.

Malo sem gledal po spletu na tematiko CPU limit - omejevanje porabe CPU strežnika - pa kaj jasnega ne najdem - ima kdo podobne izskušnje???

Sedaj se je odprlo ono pravo - merilo za porabo CPU in limit te porabe - ni nikjer definiran. Ponudnik lahko ob vsakem času reče preveč CPU mi trošiš ne da bi navedel parametre limitov. Čas merjenja nalaganja je z unixtimestamp - tick. Procedura se nalaga z avtomatskim refrešom (interval 10 do 30 sek) ali pa po potrebi z ročnim osveževanjem - vmes se nič ne dogaja - je pač PHP klasika, če bi bil Ajax bi sigurno manj trošil, query zahtevkov je okoli 7 - samo eden ima loop ostali gledajo npr ime nicka ali čas porabe za potezo(eno polje). Čas nalaganja je bil merjen na domačem serverju MS IIS. Kakšna optimizacija se bi že našla je pa vprašanje, če bo to sploh kaj vplivalo, res pa je da skripta zelo kompleksna.

Naj bolj zanimivo je dejstvo, da ta zadeva deluje več kot leto in pol na istem serverju pa do sedaj niso imeli pripomb - na serverju pa ni nekih resnih spletnih(vizitke tam do 15 podstrani - obisk pa minimalen) strani razen njihove.

MySQL: sem pregledal možnost loopa pa ga ni, pa tudi vsi ostalo zahtevki so kratki za eno polje po indexu...vse je klasičen PHP z submit metodo z enkratnim izvajanjem procedur - ni Ajax platforma - dostop do procedure je možen samo prijavljenim uporabnikom preko čekiranja sessiona, je nekaj nizov - arrays do 64 členov ostalo so v glavnem procedure, ki se izvajajo po potrebi, skripta(sešteto cca 400kb)...

Bandwidth = vse kar server downloada na uporabniško stran - vidno Awstat

CPU - poraba = trenutna poraba v MB - ali obstaja možnost testiranja??? koliko jo nek skript rabi. da se izvede....

čas izvajanja od 1 do 5 sec pri nalaganju pri uporabniku - zelo počasno....

obstaja možnost, da kdo pozabi zapreti šah vendar je delovanje v prazno omejeno z session čekom in ga preusmeri ven iz šaha...

Torej omeji težavo na določeno skripto, ki ti požere največ CPU-ja.

samo nimam dostopa do teh podatkov samo do statistike npr Awastat...., avtorskih sprememb pa ni bilo vsaj 6 mesecev...

po ugotovitvi ponudnika gostovanja je skript:

chess.php

ki je namenjen za igranje šaha - teško bi bil mallware, ker je skript čista nekompilirana PHP koda preizskušena na domačem serverju....

Od ponudnika spletnega gostovanje sem prejel mail naslednje vsebine:

ugotovili smo da vaša skripta chess.php na podomeni sah.phpzofa.net ponepotrebnem bremeni naš strežnik.

Ugotovili smo , da je skripta večkrat zagnana ( tudi do 10x ) in včasih dalj kot 2 ure.

Ob tem vsak proces porabi neverjetno veliko CPU-ja.

Smatrajte to sporočilo kot prvi opomin kršenja splošnih pravil poslovanja.

Poraba mojih resursov:

bandwidth: 4250.82 / 30.000 MB ali 15%

zaseden prostor: 67.19 / 500 MB ali 13.9%

za prvih 15 dni januarja. Do sedaj ni bilo nobenih problemov. Portal je namenjen igranju online šaha deluje na platformi PHP (osveževanje stanja na šahovnici s submit metodo) in baza mySQL, največji promet okoli 20 ure. Vprašanje je ali bi lahko bila krivda v skriptu ali nastavitvah serverja - skript ni bil bistveno spremenjen več kot 6 mesecev pa tudi ni bilo posegov v administratorske nastavitve, prenos grafike - figur je minimalen. Za mnenja se v naprej zahvaljujem!

hvala za komentar, trio88.si ima dizajn(prenos) po dogovoru z proizvajalcem varčnih sijalk kot jo imajo oni z razliko, da je v slovenskem jeziku... sami smo ugotovili, da je postavitev za kupca prekomplicirana... je bolj referenca za veletrgovce...

akcija je test ali ena taka "navadna" spletna stran "vžge" in daje potrebne informacije za eventuelni nakup sijalk, ideja je padla na osnovi komentarjev ali lahko enostavna stran bolje trži kot "super" dizajnirana stran....

balonar:

prodaja se vrši na osnovi osebnega kontaktna - telefon ali po mailu, pogoji so navedeni v spletni prodaji, je pa za razmislit če bi stran "akcija" dopolnili s temi podatki...

osnovna stran www.trio88.si je za nekatere bila prekomplicirana pri podajanju informacije o ponudbi ekološke razsvetljave pa sem naredil eno "simpel" akcijsko tran - vse v eni - ogled je možen:

http://www.akcija.trio88.si/

vse kritike in ideje bodo dobrošle...

malo sem pogledal po netu pa je kar nekaj luštnih rešitev

http://www.studiotomas.si/

http://www.copek.si/studio.htm

http://www.salon-barbi.si/

http://www.salonrenata-sp.si/

barvni koncept je daleč od sivo-belega, pa nekaj fotografij frizur

je dodano, je pa res vse so bolj kot vizitke ampak zanimive...