Mendelezaji wa Magento alibadilisha miito 300 tofauti ya ProductRepositoryInterface::getById() na dodoso moja la mkusanyiko (collection query). Miguso ya hifadhidata (database hits) ilipungua kutoka 300 hadi 1, na ukurasa wa kategoria ulipakia kwa kasi zaidi. Je, gharama yake ilikuwa nini? Baadhi ya bidhaa zilipotea kwenye duka la mtandaoni, jambo lililowachanganya wateja na wamiliki.
Tatizo la N+1 kwenye ukurasa wa kategoria wa Magento
Ukurasa huo uliorodhesha bidhaa 300. Kwa kila bidhaa, kodi ilichukua sifa mbili maalum (custom attributes) kupitia njia ya getById() ya repository, ikitengeneza dodoso moja kwa kila bidhaa—muundo wa kawaida wa N+1. Kubadilisha upakiaji huo wa kila bidhaa kwa kutumia mkusanyiko (collection) unaovuta mistari yote inayohitajika katika dodoso moja kulipunguza idadi ya dodoso kwa kiasi kikubwa. Ucheleweshaji wa upande wa mbele (front-end latency) uliongezeka, lakini orodha ya bidhaa sasa ilikosa bidhaa ambazo zilikuwa zimeonekana hapo awali.
Kwa nini mkusanyiko huficha bidhaa ambazo hazipo stoo
Moduli ya CatalogInventory ya Magento huongeza chujio la "in-stock" kiotomatiki kwenye mkusanyiko wowote wa bidhaa ulioundwa kwa ajili ya upande wa mbele. Chujio hilo hufanya kazi wakati mpangilio wa duka wa Display Out of Stock Products unapozimwa, chaguo la kawaida kwa wafanyabiashia ambao hawataki kuonyesha bidhaa ambazo hazipatikani.
Kinyume chake, repository haitumii chujio la stoo kamwe. Inahakiki tu kwamba bidhaa ipo na kuirudisha, bila kujali kiwango cha bidhaa iliyobaki. Wakati kodi ilipohamia kutoka kwenye miito ya repository kwenda kwenye mkusanyiko, chujio la stoo liliondoa kimya kimya kila bidhaa ambayo idadi yake ilikuwa sifuri. Hakuna hitilafu iliyorekodiwa; mkusanyiko ulirudisha mistari michache kuliko vile mendelezaji alivyotarajia.
Hii inamaanisha nini kwa wafanyabiashia
Duka la mtandaoni linalofuta SKU ambazo hazipo stoo kimya kimya huleta matatizo kadhaa:
- Vipengele vya upande wa mbele (front-end components) vinapokea data inayokosekana, na kusababisha lebo tupu au bei zisizo sahihi.
- Utatuzi wa hitilafu (debugging) unakuwa mgumu kwa sababu dalili—bidhaa kukosekana—haizalishi onyo lolote.
Kwa sababu majaribio mengi ya kiotomatiki hutumia data za majaribio (fixtures) za bidhaa zilizopo stoo, hitilafu hii mara nyingi hubaki imejificha hadi tovuti inapofanya kazi na bidhaa halisi.
Jinsi ya kudumisha kasi bila kuficha bidhaa zilizopo stoo
- Ruka chujio la stoo la kawaida – Ondoa chujio hilo waziwazi kutoka kwenye mkusanyiko ikiwa unahitaji kila bidhaa bila kujali upatikanaji wake. Magento inatoa njia za kuzima au kubadilisha plugin ya stoo kwa kila dodoso.
- Tumia repository wakati usahihi unapohitajika – Repository inahakikisha kuwa kila ID ya bidhaa iliyoomba inarudishwa, hata kama haipo stoo. Hifadhi matokeo (cache) au pakia ID tu unazohitaji ili kudhibiti dodoso za ziada.
- Tumia resource model au SQL ghafi – Uliza jedwali la bidhaa moja kwa moja kwa ajili ya sifa zinazohitajika. Hii inapita plugin zote za mkusanyiko na kukupa udhibiti kamili juu ya mistari inayojumuishwa.
Kasi dhidi ya usahihi
Kubadilisha mzunguko wa N+1 wenye kelele kwa dodoso moja la mkusanyiko huonekana kuwa ni jambo la kawaida; upungufu wa ucheleweshaji unahisiwa wazi. Hata hivyo, dodoso ya haraka inayorudisha seti isiyo sahihi ya bidhaa ni hitilafu, si uboreshaji. Mendelezaji lazima apime kasi halisi dhidi ya hatari ya kuonyesha katalog isiyo kamili.
Vitu vya kuzingatia baadaye
- Mabadiliko ya mipangilio (Configuration drift) – Hakikisha kuwa alama ya Display Out of Stock Products inalingana na tabia inayokusudiwa ya kodi yoyote ya mkusanyiko maalum.
- Athari za plugin – Moduli nyingine zinaweza kuongeza vichujio vyao kwenye mikusanyiko. Pitia mfululizo wa plugin kila unapobadilisha mbinu za dodoso.
Somo ni wazi: kutatua tatizo la N+1 kwa kutumia mkusanyiko kunaleta faida tu ikiwa pia utakagua vichujio vya kawaida vya mkusanyiko huo. Kupuuza chujio la stoo lililojengwa ndani ya Magento kunaweza kukata katalog yako kimya kimya, na kugeuza ongezeko la utendaji kuwa upotevu wa mapato.