Tavs Ajax ielādes ātrūms.

[Wuu]

Cik ir minimālais ielādēs laiks ko varētu sasniegt no brīža kad tiek nosūtīts JSON caur ajax un tiek saņemta atbilde. Vai 200ms ir ok? Gribētos ātrāk. Mēru ar Firebug. Ja tā vispār ir pareizais veids mērīt. Vienkārši tiek lietota pusjēla Windows mašīna (Nav mana izvēle). Kādā ir kolēģu pieredze šajā jautājumā?  Ja 200ms ir stipri par lēnu, varētu papēti šo jautājumu.

[daGrevis]

Hei, a PHP joprojām nav izauguši līdz ORM? :trollface:

[briedis]

Hei, a PHP joprojām nav izauguši līdz ORM? :trollface:

 

ORM ir pārāk liels overheads, tāpēc vislabāk ir "lipināt" kvērijus, nav nekāda overheada, pure raw power.

 

:trollface:

[daGrevis]

Overheads, jo jā-concat-o stringi.

[briedis]

Overheads, jo jā-concat-o stringi.

 

Parasti tiek lādētas liekas figņas atmiņā, daudz dažādas liekas procesēšanas, utt utt. Protams, ka ir overheads. Paskaties cik sver tās tavas orm bibliotēkas, cik daudz koda jāpilda!

:trollface:

[daGrevis]

Jā, tas bija joks. Nu tas ORM overhead ir smieklīgs, sorry.

[Wuu]

Esmu neizglītots, bet kods ar preperad statmentu ir graujošs. To pārbaužu kaudze fascinē pat mani. Cik saprotu, pat vienas pārbaudes pietrūkst :D Un vel beigās stmt jāaizver ne? 

						$result = mysqli_prepare($link, 'select * from '.$INFO['sql_tbl_prefix'].'excel_online;');
						if ($result != false) {
							$error = true;
							//$error = mysqli_stmt_bind_param($result, 's', $item['item_name']);
							if ($error != false) {
								$error = mysqli_stmt_execute($result);
								if ($error != false) {
									$result = mysqli_stmt_get_result($result); 
										while($r = mysqli_fetch_assoc($result)) {
											print_r($r);
										}
								} else {
									echo 'kļūda1';
								}
							} else {
									echo 'kļūda2';
							}
						} else {
							echo 'kļūda3';
						}	

Es pareizi sapratu?

 

Plus vel mīnus ar prastiem selectiem un limitiem? Pag, es paskatīšos kalendāra, jobcik 2014. gads... Priekš insert der, bet selecti gaužām līki izskatās.

Edited September 12, 2014 by Wuu

[briedis]

Jā, tas bija joks. Nu tas ORM overhead ir smieklīgs, sorry.

Paga, es vēl nebeidzu :D :D

[codez]

PHP ir ļoti labi ORM un viens no tiem saucās Doctrine. Man nav ne mazākās jausmas, kāpēc daudzi vēl iet ar kājām (PHP+figļimigļi plain kveriji), ja var braukt ar riteni (PHP + ORM). Protams, var arī izvēlēties sporta mašīnu (Scala + Play + Slick).

[jurchiks]

@Wuu - tavā kverijā nav neviena parametra, tur prepared statement gan nav jēgas izmantot.

Un vispār, tu tur ieslīgsti paranojā ar tām pārbaudēm.

Šim kodam vajadzētu mest exceptions pie jebkādām problēmām:

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); // kaut kur pie savienojuma izveidošanas

try
{
    $pstmt = mysqli_prepare($link, 'SELECT col1, col2 FROM excel_online');
    // $error = mysqli_stmt_bind_param($pstmt, 's', $item['item_name']);
    mysqli_stmt_execute($pstmt);
    mysqli_stmt_bind_result($pstmt, $col1, $col2);
    
    while (mysqli_stmt_fetch($pstmt))
    {
        echo "{$col1}, {$col2}\n";
    }
    
    mysqli_stmt_close($pstmt);
}
catch (mysqli_sql_exception $e)
{
    // log exception
}

Kā arī tava fobija no objektiem arī ir steidzami jāārstē. OOP kods izskatās labāk:

 

try
{
    $pstmt = mysqli_prepare($link, 'SELECT col1, col2 FROM excel_online');
    // $error = $pstmt->bind_param('s', $item['item_name']);
    $pstmt->execute();
    $pstmt->bind_result($col1, $col2);
    
    while ($pstmt->fetch())
    {
        echo "{$col1}, {$col2}\n";
    }
    
    $pstmt->close();
}
catch (mysqli_sql_exception $e)
{
    // log exception
}

Edited September 12, 2014 by jurchiks

[Kavacky]

TL;DR: codez >> jurchiks

[jurchiks]

@Kavacky - lies, all lies!

[Wuu]

Paldies jurchiks par izsmeļošu atbildi, (tur kodā, testam, izņēmu bindoto parametru) tomēr preperad statmenti ir laba ideja ar sliktu implementāciju. Par "Un vispār, tu tur ieslīgsti paranojā ar tām pārbaudēm." nepiekritīšu. Atkarīgs kam un kā tu vēlies veidot savu produktu.

[jurchiks]

Jā, ir tiem prepared statementiem ierobežojumi, bet tas vienalga ir labāk, nekā visos kverijos hardkodēt vērtības, tādiem kverijiem gandrīz nekad nav iespējams izmantot query cache, jo vērtības visu laiku mainās. Ja ir pieejama iespēja datubāzei pašai optimizēt kverijus, tad kāpēc gan to neizmantot? Pat ja tikai 25% kveriju izmantos kešu, tas vienalga ir daudz labāk nekā 0%.

 

Ja tu taisi kaut kādu kredītu sistēmu, tad varbūt ir vērts pārbaudīt visu un visur, bet, kā manā piemērā redzams, ir labāki risinājumi nekā katrā otrajā līnijā pārbaudīt iespējamās kļūdas, kuras 99.999% gadījumu nenotiks.

Edited September 13, 2014 by jurchiks

[hjkl]

PHP ir ļoti labi ORM un viens no tiem saucās Doctrine. Man nav ne mazākās jausmas, kāpēc daudzi vēl iet ar kājām (PHP+figļimigļi plain kveriji), ja var braukt ar riteni (PHP + ORM). Protams, var arī izvēlēties sporta mašīnu (Scala + Play + Slick).

 

Nevar iet ar kājām, ja vispirms nav iemācījies rāpot. Ar high speed sporta mašīnu, kas piebāzta ar dažādu automātiku, arī nav diezcik prātīgi braukt, ja pirms tam nav iemācījies kādu basic modeli ar manuālo ātrumkārbu izkustināt no vietas.

Edited September 13, 2014 by hjkl

[Wuu]

Atpakaļ pie tēmas:

 

Esmu atdūries pret gravitāciju, gaismas ātrumu un citām muļķībām (doh). Standarta pieprasījums (php 10ms + līdz klientam 30 ms) no Amsterdamas uz Latviju. Tomēr, lielāki JSON gabali (lielas tabulas) līdz pat 280ms. Vai ir iespēja JSON datus saspiest un samazināt to izmēru? Idejas?