Developers often ask me the same question: "My API is slow. Where do I start?" The reflex is usually to upgrade the serv

Watengenezaji mara nyingi huuliza swali lile lile: "API yangu ni nzito. Naanzaje?" Mbinu ya haraka mara nyingi ni kuongeza uwezo wa seva au maraisha RAM. Hiyo inagharimu pesa na mara nyingi haitatua chanzo cha tatizo. Katika programu nyingi za Laravel, kikwazo (bottleneck) kipo kwenye tabaka la kanzidata (database layer). Muundo mzuri wa framework hii unafanya iwe rahisi kusahau kwamba kila wito wa Eloquent hatimaye unakuwa SQL, na SQL ndipo mara nyingi matatizo huanzia.

Kabla ya kugusa mipangilio ya seva, pitia hoja zako (queries) kwa utaratibu.

Anza na Utambuzi Sahihi

Usifanye uboreshaji (optimization) gizani. Kuandika upya queries bila mpangilio ni kukisia, na kukisia kunapoteza saa nyingi.

Unahitaji kupata kauli (statements) zinazotumia muda mwingi zaidi. Angalia programu yako chini ya mzigo halisi (real load). Laravel Telescope inakupa mwonekano safi wa kila query inayotekelezwa wakati wa ombi (request), ikiwa na muda wake. Laravel Debugbar inazionyesha kwenye kivinjari chako wakati wa maendeleo ya ndani (local development) ili uweze kubaini hitilafu mara moja. Unapohitaji kukamata matatizo kwenye uzalishaji (production), washa MySQL Slow Query Log. Inarekodi kauli zinazozidi kiwango (threshold) unachoweka, jambo ambalo inafanya iwe bora kwa kupata mambo yasiyotarajiwa ambayo hayaonekani kwenye seti ndogo za data. Ikiwa unaendesha kitu kikubwa zaidi, zana ya Application Performance Monitoring inaweza kuunganisha HTTP endpoints nzito na wito mahususi wa kanzidata.

Unapopitia data, angalia mambo mawili: muda kamili wa utekelezaji na masafa ya wito (call frequency). Query inayochukua milisekunde arobaini inaonekana haina madhara mpaka utakapogundua inafanya kazi mara elfu mbili kwa dakika. Ripoti ya sekunde tatu inayofanya kazi mara moja kwa saa inaweza kuwa na umuhimu mdogo kuliko utafutaji wa nusu sekunde unaofanya kazi kwenye kila ukurasa. Rekebisha matatizo yenye athari kubwa kwanza.

Acha Kuomba Kila Kitu

SELECT * ni rahisi. Lakini pia ni gharama kubwa. Unapoandika Model::all() au unapata seti ya matokeo bila kutaja safu (columns), MySQL inavuta kila uwanja (field) kwa kila mstari unaolingana. Hiyo inajumuisha uwanja mkubwa wa maandishi, JSON blobs, na kitu kingine chochote kilichopo kwenye jedwali. Seti ya matokeo inakuwa kubwa, matumizi ya kumbukumbu (memory) yanaongezeka, na muda unaotumika kubadilisha jibu (serializing the response) huongezeka.

Kuwa wazi. Ikiwa kiongozi wako (controller) unahitaji tu uwanja wa id, name, na email, omba hizo hasa:

User::select('id', 'name', 'email')->get();

Katika query builder, kanuni hiyo hiyo inatumika. Data ndogo (smaller payloads) husafiri haraka zaidi kwenye mtandao na hutumia RAM kidogo kwenye seva ya programu yako. Hii ni moja ya ushindi rahisi zaidi unaopatikana, lakini ni rahisi kuipuuza kwa sababu Laravel inafanya SELECT * kuwa tabia ya kawaida.

Acha EXPLAIN Iongoze Mabadiliko Yako

Usifanye marekebisho (refactor) ya query nzito bila kuendesha EXPLAIN kwanza. Katika MySQL, neno EXPLAIN linaonyesha mpango wa utekelezaji wa query. Linaonyesha jinsi optimizer inavyokusudia kupata data yako.

Zingatia safu ya type. Ukiona ALL, MySQL inafanya ukaguzi kamili wa jedwali (full table scan). Hiyo inamaanisha inasoma kila mstari ili kutimiza sharti lako la WHERE. Angalia safu ya key ili kuona kama optimizer inatumia index kabisa. Kisha kagua safu ya Extra. Ukiona Using temporary au Using filesort, MySQL inajenga majedwali ya muda au inafanya mpangilio (sorting) kwenye kumbukumbu kwa sababu muundo wako wa sasa hauwezi kutimiza query hiyo kwa urahisi.

Endesha EXPLAIN kwenye mteja wako wa MySQL, au tumia zana inayopanga matokeo (output) kwa ajili yako. Ukishauona mpango huo, utajua ikiwa tatizo ni kukosekana kwa index, join mbaya, au sharti (predicate) ambalo injini haiwezi kuiboresha. Kukisia hakutahitajika tena.

Weka Index kwa Kusudi

Index ni zana yenye nguvu zaidi kwa ajili ya kuharakisha utafutaji, lakini zinafanya kazi tu wakati zinaendana na jinsi unavyouliza query. Bila index sahihi, MySQL inascan mstari kwa mstari. Hiyo inaweza kuonekana sawa wakati wa maendeleo kwenye jedwali lenye mistari elfu moja, na kisha kusambaratika wakati wa uzalishaji kwenye jedwali lenye milioni kumi.

Anza na index za safu moja kwa uwanja unaotokea mara kwa mara katika kauli za WHERE. Ikiwa unachuja mara kwa mara kwa status, ongeza index kwenye status.

Wakati query inachuja kwenye safu nyingi kwa pamoja, hamia kwenye composite indexes. Mpangilio wa safu ndani ya index ni muhimu kwa sababu MySQL inasoma composite indexes kuanzia kushoto kwenda kulia. Hii inaitwa sheria ya "leftmost prefix". Ikiwa query yako inatafuta kwa user_id na kisha inapanga kwa created_at, composite index kwenye (user_id, created_at) inasaidia sana. Ukibadilisha mpangilio, optimizer inaweza isitumie index hiyo kwa ajili ya chujio kabisa.

Usiweke index kwenye kila safu. Kila index inaongeza mzigo (overhead) kwenye uwekaji (inserts), uhuishaji (updates), na ufutaji (deletes) kwa sababu MySQL lazima idumishe muundo huo. Ziweke kwa makusudi kulingana na mifumo uliyopata wakati wa upimaji.

Weka Kazi (Functions) Mbali na Safu

Kosa hili huondoa uwezo wa indexes kimyakimya. Unapoweka safu (column) ndani ya function ndani ya kipengele cha WHERE, MySQL haiwezi