Jump to content
php.lv forumi

No0ne

Reģistrētie lietotāji
  • Posts

    148
  • Joined

  • Last visited

Everything posted by No0ne

  1. Liels paldies, codez un php newbie!
  2. Vai arī kādu sarežģītu piemēru uzrakstīsi, kas darbojas visos gadījumos, kas ir topika sākumā?
  3. Nepieciešams precīzs skaitlis, nevis noapaļots. Vai nākamreiz pirms sāc stāstīt par googli, vari iedot kādu strādājošu piemēru? number_format() un money_format() diezgan daudz visādas problēmas ir pieminētas, tāpēc gaidu no gudrākiem cilvēkiem info, kurš varētu būt labākais variants.
  4. Interesē, ar ko varētu panākt šādu konvertāciju: 1 => 0.01 10 => 0.10 100 => 1.00 1000 => 10.00 10000 => 100.00 Attiecīgi input - skaitlis, output ##.## ar 2 cipariem aiz punkta, attieciigi tie būs santīmi
  5. Starp citu, kopš last posta nevienu problēmu vairs neesmu manījis. Varbūt kādam noderēs, ja gadīsies līdzīga situācija :)
  6. Arī pēc PHP atjaunināšanas problēma saglabājas. Statiskais kontents joprojām ielādējas perfekti arī brīžos, kad lapas nevar atvērt. Izpētīju visu, tomēr neko interesantu neieraudzīju Tikko ieraudzīju arī 504 erroru, attiecīgi nginxā beidzot normāls skaidrojums: upstream timed out (110: Connection timed out) while reading response header from upstream Nezinu vai tas ir saistīts ar iepriekš minēto 404 erroru vai vienkārši trāpīju tādā brīdī, kad reizi gadā izmet šādu erroru, bet, lai risinātu palielināju php-fpm max childrenus. Rīt jāskatās vai nošaušu divus zaķus ar vienu šāvienu :) Vēl pie nakts atziņām gribas piebilst, ka diezgan loģiski, ka vaina ir kaut kur PHP, jo 404 errors nozīmē, ka failu nevar atrast, bet kur nginx ņem to failu? nginx tā vienkārši neparāda .php failu kā tas notiek ar html vai citiem statiskajiem. PHP to pieprasa no 'upstream' fast cgi interpretētāja (?), kas manā gadījumā ir php-fpm. Savukārt, ja PHP-fpm ir nokāries, tad attiecīgi izmet erroru, ka tāda faila nav vai, ka pārāk ilgi mēģina pieslēgties utt.
  7. Tagad pamanīju, ka uz statiskajiem failiem šādas problēmas nav. Statiskie faili tieši tāpat stāv uz SSD. Sāku domāt vai ar PHP nav kas noticies. Atjaunināju PHP versiju, skatīšos vai vēl parādīsies šī problēma, vai pazudīs.
  8. Kods ir veiksmīgi darbojies gadus 3, nekas nav rediģēts. Saproti, nevis pašu lapu lādē ilgi, bet tajā brīdī, kad notiek šī figņa, tad neko nelādē - ne elementus, ne ko un tad kad tā figņa beidzas viss uzreiz aiziet. Teiksim šobrīd ieejot lapā ~1sek un lapa ir ielādējusies. Ja tad, kad notiek figņa ieieitu lapā: 30sek firefox lādētu un pa to laiku būtu blank page, tad pēc ~30sek, kad figņa beigtos pa 1 sek ielādētu lapu. Ja figņa nebeigtos nginx izmestu 404 not found, jo nav varējis piekļūt failam for some reason. Pēc tam figņa beigtos un viss lādētos atkal ~1sek līdz nākamajai reizei, kad tā figņa parādīsies pēc dažām minūtēm. Esmu diezgan drošs, ka to error logā varēja redzēt un tur bija jāmet 502 vai 500-to erroru. 404 not found nozīmē, ka nav iespējams piekļūt failam vai, ka fails neeksistē. Fails eksistē un strādā lielāko laika daļu normāli, tāpēc lūdzu padomājiet kāpēc varētu nevarēt atsevišķos brīžos piekļūt failam, kamēr SSD nav noslogots.
  9. Nu tas, protams, nav ideāls scenārijs, bet atbilstošākais šai situācijai :) Varbūt kaut ko par tēmu vari pateikt, nevis tikai izteikt savas domas par to, ka SSD ir sūds un, ka serverim, kurš var pavilkt 10x lielāku slodzi kā tam šobrīd ir, ir stulbi litk darīt to, ko viņš dara?
  10. Cietie kādu gadu apmēram stāv, viss ir darbojies nevainojami līdz šim. Diski raksta datubāzē datus, domājams, ka relatīvi maz + vēl tiek izmantoti video failu lejupielādēi un apstrādei pirms tiek pārvietoti uz HDD. Izmantoju šādu SSD Intel 520 Series (80k random IOPS, ~550MB/s) blackhalt, es neesmu linux eksperts un diezgan maz sapratu no tā linka, ko devi, bet vai tā vispār optimizācija ir vajadzīga, ja cietajiem nav liels I/O (procentuāli)? Man šķiet, ka problēma slēpjas kur citur.
  11. Sveiki! Man pēdējās dienās parādijusies problēma ar serveri. Verot vaļā lapu tā 90% gadījumu atveras tieši kā paredzēts ātri un bez problēmām, bet ik pa brīdim rodas tāda problēma, ka lapu ver ļoti ilgi vaļā. Ne tieši atsevišķus elementus ilgi lādē, piemēram, bildes, bet vienkārši pieslēdzas pašai lapai ilgi. Tad attiecīgi pēc kādām 30sek vai nu lapa aiziet vai arī nginx izmet 404 not found. Problēma ir cietajā diskā, jo 404 not found parādās, ja nevar piekļūt failam slodzes dēļ. Tad nu tādos brīžos izdomāju ar iotop pavērot I/O, bet viss ir normā. Papildus tam tie ir SSD diski un I/O limitu sasniegt ir praktiski neiespējami pie pašreizējajiem apstākļiem. Skatījos arī visu pārējo - swap netiek izmantots, load nav liels. Kas varētu būt par problēmu kādēļ cietie šādi uzvedas?
  12. Tu. Tā arī neieraudzīju, ko tu esi veidojis tavā tekstā.
  13. Negribu izteikties par pašu lapu, bet mani interesē, ko visu zinošanis F3llony ir izveidojis, ka katrā topikā, kur es paskatos viņš gudri dirš, ka neviens neko nemāk un ka viņš visu zin labāk.
  14. http://php.lv/f/topic/21111-sist%C4%93manal%C4%ABti%C4%B7a-vakance/ visiem, kas piesakās iesaku izlasīt manu komentāru
  15. Starp citu, gribētu piebilst, ka šis Matīss Roberts Treinis ir kidala. Pirms vairākiem gadiem ieskaitīju viņam pirmo iemaksu par projektu, viņš kaut ko mēģināja taisīt, nezinu vai tāpēc, ka nesanāca vai kāpēc, bet neko neuztaisījis darbu pārtrauca, ignorēja un tā arī nekad nav atbildējis. Viņam par laimi viņš tad vēl dzīvoja Ogrē un nebija bijis tas gods satikt.
  16. Oi, tas baigi tizli sanāks, es drīzāk biju domājis, ka kāds caur teamviewer vai VNC caur manu datoru paskatīsies visu, kas tur nav kā vajag un tad pielabos. Es pat tā īsti nespēju "neparādot dzīvē" izstāstīt, kas tur neiet kā vajag.
  17. Ir +- gatavs skripts, kas +- dara to, ko vajag, bet čalis, kas taisīja ir nozudis, nepieciešams izlabot visādus sīkumus. Ātri, viegli caur skaipu var pietiekami ātri visu izrisināt, par palīdzību samaksāšu! No0ne-at-bmx-lv Teiksim, ja kādam šonat nenāks miegs, tad tas būs vienkārši perfekti. Pierakstīšu šeit, kad kāds mēģinās kaut ko darīt lietas labā, tā kā droši visi interesenti uz skaipu!
  18. Es zinu, kas tur ir, bet tas galīgi nedarbojas kā vajag. Star citu tas CURLOT_RANG ir tizlākais headeris ever, 3 lapaas meginaju, visas 3 ignoreja so jaukumu.
  19. Tātad interesē noteikt augšuplādes ātrumu konkrētajā brīdī serverim, uz kura glabājas faili. Nu, pieņemsim, pārbaudīt vai no servera fails nāk ar vismaz 100kb/s. Un lai nebūtu jāvelk visu lielo failu, gribētos nolimitēt curl uz 50mb, lai pēc tam pārtrauc lejuplādēt. Mēģināju šādi: $writefn = function($ch, $chunk) { static $data=''; static $limit = 500; //500 baiti $len = strlen($data) + strlen($chunk); if ($len >= $limit ) { $data .= substr($chunk, 0, $limit-strlen($data)); echo strlen($data) , ' ', $data; return -1; } $data .= $chunk; return strlen($chunk); }; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $curl_url); //faila url curl_setopt($ch, CURLOPT_RANGE, '0-500'); curl_setopt($ch, CURLOPT_BINARYTRANSFER, 1); curl_setopt($ch, CURLOPT_WRITEFUNCTION, $writefn); $result = curl_exec($ch); curl_close($ch); fwrite($fp, $data); fclose($fp); $bytes = 10253413 / 1048576; // 6576848=filesize || 1048576=how many bytes in a mb $time_end = microtime(true); $time = $time_end - $time_start; $mbps = $time / $bytes; echo 'MBps: '.$mbps; clearstatcache(); nu un pirmkārt jau tur kaut kāda mistika notiek ar baitiem. kad uzlieku 5 baitus, tad attēlo 1 ciparu, ok pieņemsim, ka tie 4 ir kaut kam domāti, kurus neparāda, ttas it kā mani neuztrauc, bet, starp 5-500 baitiem viss ir ok, bet, ja es teiksim uzliek 505 baitus, tad man vispār nekas nenotiek. Tā varētu būt servera vaina? Un, ja jā, tad kas pie tā vainīgs. Ja nē, tad gribētu dzirdēt kā šo realizēt! Tātad lejuplādējam failu, pārtraucam tā lejuplādēšanu pie 50mb un skatamies/rēķinam ar cik tas ir vilcies.
  20. DaGrevi, tu sāki cepties, kad paskaidroju tev, ka tas nav pareizi. Es tikai atbildēju uz to, ko tu teici. Es domāju tēmu var slēgt :)
  21. Neesmu. Pastāstīsi? Skatījos googlē, īsti nesapratu, ko tu tieši domāji.
  22. Man šķiet tev pašam skolā jāiet. Savulaik izveidojās diskusija ar forumcinemas par to, ka viņu tulks subtitros "jūs" pieklājibas formā, raksta ar mazo burtu. Biju vienkārši šokā, kad uzzināju, ka tas tomēr ir pareizi, jo Jūs lieto tikai vēstulēs un kaut kādos svarīgos dokumentos, bet nekad vienkāršā sarunā ar cilvēku. Kaut kur varētu sameklēt arī sīkāku skaidrojumu, bet pēc idejas, ja es tevi šobrīd gribētu uzrunāt pieklājības formā, pareizi skaitītos, ka es saku "jūs, daGrevis..." ar mazo burtu. Pārējiem vārdiem izmantot lielo sākumburtu ir vienkārši wtf. Varbūt gribi izcelties ar savām (ne)zināšanām, kā senāk DC++ hubu čatos daži rakstīja ar 50 atstarpēm no kreisās malas un boldā, kas to lai zin.. Bet kā jau teicu, negribēju uzbraukt, tikai pateicu, lai tu zinātu, manis pēc vari turpināt nepareizi rakstīt, ja tev tā labāk patīk. Un nejauc neuzmanības kļūdas ar kļūdām, kuras pieļauj speciāli. Ir starpība starp to, ka cilvēks ātrumā raksta un kaut ko piemirst, un starp to, ka cilvēks speciāli pacenšas kaut ko nepareizi izdarīt. Es jau vēlreiz saku, lai neuzskati to par uzbraucienu, bet vienkārši saproti, ka tas ir tāpat kā visu laiku rakstīt php mainīgos, kā arrayus ar vienu vērtību, domājot, ka tā ir pareizāk. <? $mainigais[]="hey hey"; echo $mainigais[0]; // un tas ir viss, kam tiek izmantots šis $mainigais ?> Btw, varbūt arī darbības vārdus Varētu Rakstīt ar lielo sākumburtu? Tā Teikt - kāpēc ne? :)
×
×
  • Create New...