Jump to content
php.lv forumi
  • 0

Tavs Ajax ielādes ātrūms.


Wuu
 Share

Question

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.

Link to comment
Share on other sites

  • Answers 107
  • Created
  • Last Reply

Top Posters For This Question

Recommended Posts

  • 0

No kurienes tu to ātrumu mēri un kur atrodas saits? Vajadzētu mērīt no pavisam citas lokācijas, piemēram, serveris kaut kādā datu centrā vai ofisā, bet mēri tu no mājām vai kādas kafejnīcas WiFi.

Un tam, ka tu lieto "pusjēlu Windows mašīnu", requesta ātrumu nevajadzētu ietekmēt, tas var ietekmēt tikai datu apstrādi, saņemot response.

 

Bet nu jebkurā gadījumā šī pieprasījuma laiks ir pilnībā atkarīgs no a) interneta pieslēguma ātruma (kā jau briedis minēja), izņemot gadījumu, kad lapa atrodas intranetā, un b) no paša skripta izpildes laika hosta pusē. Pārsvarā pie lēniem pieprasījumiem vainojams B.

Edited by jurchiks
Link to comment
Share on other sites

  • 0

real escape string un prepare statement ir 2 dažādas lietas jau datubāzes līmenī un pie neatkārtotiem kverijiem pirmais ir ātrāks, jo notiek vienā solī, kamēr otrais notiek divos soļos - pa priekšu tiek sagatavots pieprasījums un tālāk tas tiek izpildīts izmantojot datus.

prepare statement mīnusi ir:

1)Kveriju kešs nestrādā vecākās mysql versijās , bet jaunākās strādā tikai pie noteiktiem nosacījumiem,

2)Papildus komunikācija ar db serveri, jo izpildās 2 soļos

3)Prepeared statment-u tāpat nevar izmantot visās vietās un nākas atgriezties pie pirmās metodes. Piemēram, LIMIT, IN, utt.

4)Defaultā grutāk debugojams, jo statement-i ir bez vērtībām.

 

plusi:

1)Ātrāks, ja jāizpilda viens un tas pats kverijs vairākas reizes, bet ar dažādiem datiem.

Link to comment
Share on other sites

  • 0

1) Tikai tāpēc, ka kveriju kešs kaut kādās situācijās nestrādā, nedrīkst pārslēgties uz hardkodētiem mysqli_real_escape_string(). +piekāst vecākas mysql versijas, time to move on.

2) Insignificant performance difference, ja vien vienā pieprasījumā neveic 1k+ pieprasījumus.

3) Kā tas jāsaprot - prepared statement nevar izmantot ... piemēram, LIMIT?

Kas tieši tev aizliedz izmantot prepared statement ar šādu kveriju:

"SELECT column FROM table WHERE time > :time ORDER BY column LIMIT 5"

?

4) Grūtāk debagojams, ja sūdīgi uzrakstīts kods, normālās aplikācijās exception izdod arī padotos parametrus.

 

Jebkurā gadījumā, uztraukties par performance atšķirībām starp hardkodētiem mysqli_real_escape_string() un normāliem kverijiem ar prepared statementiem ir stulbi, protams, līdz brīdim, kad tu sāc rakstīt kaut ko, kam viennozīmīgi nevajadzētu būt rakstītam PHP.

 

IMHO mysqli_real_escape_string() needs to die.

Link to comment
Share on other sites

  • 0

1) Tikai tāpēc, ka kveriju kešs kaut kādās situācijās nestrādā, nedrīkst pārslēgties uz hardkodētiem mysqli_real_escape_string(). +piekāst vecākas mysql versijas, time to move on.

Nevis kaut kādās nestrādā, bet strādā tikai specifiskās.

2) Insignificant performance difference, ja vien vienā pieprasījumā neveic 1k+ pieprasījumus.

Tā kā db bieži ir bootlenecks, tad var gadīties situācijas, ka nav tik nesvarīgi.

 

3) Kā tas jāsaprot - prepared statement nevar izmantot ... piemēram, LIMIT?

Kas tieši tev aizliedz izmantot prepared statement ar šādu kveriju:

"SELECT column FROM table WHERE time > :time ORDER BY column LIMIT 5"

?

Tu jau neizmanto prepared vērtību limit-ā

Pamēģini:

"SELECT column FROM table WHERE time > :time ORDER BY column LIMIT ?,?"

Nesanāks

 

4) Grūtāk debagojams, ja sūdīgi uzrakstīts kods, normālās aplikācijās exception izdod arī padotos parametrus.

Jebkurā gadījumā, uztraukties par performance atšķirībām starp hardkodētiem mysqli_real_escape_string() un normāliem kverijiem ar prepared statementiem ir stulbi, protams, līdz brīdim, kad tu sāc rakstīt kaut ko, kam viennozīmīgi nevajadzētu būt rakstītam PHP.

Ko nozīmē hārdkodēti? "...".mysqli_real_escape_string()."..."?

Priekš tam ir izdomātas funkcijas un klases, lai kodu abstrahētu un neatkārtotos. Par to šoreiz nav runa.

Runa ir par to, ka real_escape un prepared statmenti ir dažādas lietas un galvenā atšķirība nav pierakstā, jo mēs varam uzrakstīt abstrakciju, kā vienam tā otram, lai izskatās otrādi, bet gan veidā kā tiek izpildīti tālāk.

Piemēram, savulaik, pirms pats vēl aizrāvos ar savu FW rakstīšanu, man bija funkcija SQL("SELECT * FROM user WHERE name=? AND surname=?","john","doe"), kurā tika ņemti parametri un ar real_escape eskeipoti un salikti kverijā.

 

IMHO mysqli_real_escape_string() needs to die.

Uzraksti man ar prepared statement-u strādojušu kveriju, kuram url-ā padod lapaspuses numuru un tas atgriež no tās lapaspuses 10 ierakstus.

Un pēc tam uzraksti prepared statement-u kveriju, kurā ir tabula people un tiek padoti N vārdi un, lai ar WHERE name IN atgriež visus lietotājus, kuru vārdi sakrīt ar padotajiem vārdiem.

Link to comment
Share on other sites

  • 0

Uzraksti man ar prepared statement-u strādojušu kveriju, kuram url-ā padod lapaspuses numuru un tas atgriež no tās lapaspuses 10 ierakstus.

Tu taču negribi teikt, ka izmanto real_escape, lai eskeipotu skaitļus? if (!ctype_digit("{$_GET['page']}")) { echo 'invalid page parameter value, fuck you'; }

Mēs te nerunājam par cipara appendošanu pēc "LIMIT ", bet gan par manuālu jebkādu datu eskeipošanu.

Tas, ka tu nevari izmantot parametrus iekš LIMIT, nenozīmē, ka tev automātiski neder prepared statements, tas ir absurdi.

 

WHERE name IN

Es šo apeju citādāk -

$stmt->where('WHERE name IN (?)', array('abc', 'def')).

public function where($where, array $params = array())
{
    if (!empty($params))
    {
        $where = str_replace(
            '?',
            substr(str_repeat('?,', count($params)), 0, -1),
            $where
        );
        $this->params = array_merge($this->params, $params);
    }
    
    $this->wheres[] = $where;
}

$stmt->fetchAll();

public function fetchAll($some, $params)
{
    // not exact code, just an example
    $this->stmt->prepare($this->getQuery());
    $this->stmt->execute($this->params);
    return $this->stmt->fetchAll();
}
Kveriju es modificēju, bet es neko neeskeipoju manuāli, tas darbs ir jādara db.

 

 

In any case, izskatās, ka briest kārtējais holy war...

Edited by jurchiks
Link to comment
Share on other sites

  • 0

Mēs te nerunājam par cipara appendošanu pēc "LIMIT ", bet gan par manuālu jebkādu datu eskeipošanu.

Kāpēc lai kāds to darītu manuāli? Tas tiek iestrādāts db bibliotēkā un notiek automātiski.

Un ar ko atšķiras manuāla eskeipošana no manuālas datu bindošanas?

 

Tas, ka tu nevari izmantot parametrus iekš LIMIT, nenozīmē, ka tev automātiski neder prepared statements, tas ir absurdi.

Tas nav absurdi, tas ir viens no daudziem variantiem, kurā tev ar prepared statement-iem ir jādomā dažādas validācijas un apkārtceļi. Un tici man, jebkurš iesācējs ar šo (kverija parametru apendošanu) sastopoties ielaidīs SQL injekciju, tieši tāpat kā neizmantojot prepared statement-u.

 

Es šo apeju citādāk -

Nu malacis, ar realescape nekas nav jāapiet,

 

Kveriju es modificēju, bet es neko neeskeipoju manuāli, tas darbs ir jādara db.

Priekš kam jāmodificē kveriji, ja var nemodificēt? Tas ir absurdi.

 

In any case, izskatās, ka briest kārtējais holy war...

Holy ir tikai tiem, kuri domā, ka tas, ko viņi izmanto ir labāk un viss pārējais nekam neder.

Tāda subjektīva elitārisma sajūta. Bet episki ir tas, ka to dara PHP programmētājs, kamēr PHP ir pati apakša - zemākā kasta, un šeit par nekādu elitārismu pat nevar būt runa.

Link to comment
Share on other sites

  • 0

3)Prepeared statment-u tāpat nevar izmantot visās vietās un nākas atgriezties pie pirmās metodes. Piemēram, LIMIT, IN, utt.

 

LIMIT sadaļā tiešām nevar izmantot prepared statement, bet arī real escape tur arī nav jāizmanto - pietiek ar (int) vai intval().

IN sadaļā tiešām jāiet tas ceļš, kuru norādīja jurchiks, vienīgi varēja viņš to īsāk uzrakstīt, lai nebiedētu tautu ;)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share


×
×
  • Create New...