Daňového přiznání od účetní pouze teď od 490-Kč
Zobrazují se odpovědi 1 až 12 z 12

Rychlost stranek v nette

  1. Zdravím,

    programuji si novou aplikaci a řeším problém v rychlosti. Nevím či na to jdu správně, jelikož mi to načítá vždy strašně dlouho. Je to kvůli dotazům do DB a největší dotaz je tento:

    Mám hlavní kategorii v ní podkategorie a v ní další podkategorie. V každé kategorii mám nějaké produkty. Po kliknutí na kategorii, mi to musí vypsat produkty a funguje to tímto stylem:

    "zjištění všech podkategorií zobrazené kategorie (opět to samé pro všechny podkategorie), potom vybrání všech produktů z těchto kategorií (+ podmínka jestli je produkt aktivní nebo neaktivní)."

    tento dotaz mi trvá strašně dlouho, nevím jestli na něho jdu špatně a nebo se to dá řešit jinak?

    jde mi o logiku.

    děkuji za případné tipy

  2. Co se právě děje na Webtrhu?
  3. Kategorie se urcite prilis casto nemeni -> muzes v nette pouzit cache

  4. Citace Původně odeslal josef.jebavy Zobrazit příspěvek
    Kategorie se urcite prilis casto nemeni -> muzes v nette pouzit cache
    kategorii se cachuji na memecache (disk), takze i kdyz se cachuji tak to trva, kdybych to necachoval tak jsem asi na 5-6s. Nyni jsem na 2-3s.

    resim zde vice kategorii podkategorii (tisice) - produkty -(deseti tisice)

  5. A zkoušel jsi optimalizovat select, tabulky ve kterých to máš uložený (indexy) apod.?

  6. Ono jde o to, jak jsou dotazy napsany. Pises treba: "vybrání všech produktů z těchto kategorií"

    Jdes na to treba pomoci IN (), nebo je tam fakt nejaky sileny pocet jednotlivych dotazu, aby ti vybral produkty z ketegorie ID = X a to delas pro kazdou kategorii? https://www.w3schools.com/sql/sql_in.asp

  7. Tohle je moc obecný dotaz, když nikdo pořád neví, jaké dotazy to pokládá. Buďto jich to pokládá hodně, nebo jsou extrémně náročné a nebo kombinace obojího :-). To chce vědět.

    V první řadě si zkontroluj, jestli jsou dobře indexy v tabulkách.

  8. čo ti hlási debugbar, koľko máš dotazov na DB?

  9. Tipuju ze mas strom kategorii v tabulce typu - id, name, parent_id, coz je pro takove mnozstvi polozek strasne drahy na vykon a rozhodne se to nedoporucuje. Ma to smysl u nejakejch roli v ACL, kde toho tolik neni.

    Ty potrebujes closure table - nejaky cesky navod zde http://blog.voracek.net/databaze/clo...-trochu-jinak/ nebo pogoogli najdes toho dost.

    Pak to mas jeden rychlej dotaz na vsechny podkategorie, podle kterych si dotahas produkty. takze celkem 2 dotazy.

  10. ten dotaz vypada takto
    PHP kód:
    SELECT sloupce
    FROM product_variant p0_
          LEFT JOIN product p1_ ON p0_
    .product_id p1_.id
          LEFT JOIN product_label p4_ ON p1_
    .id p4_.product_id
          LEFT JOIN product_translation p2_ ON p1_
    .id p2_.product_id
          LEFT JOIN product_variant_translation p3_ ON p0_
    .id p3_.product_variant_id
          LEFT JOIN category c5_ ON p1_
    .default_category_id c5_.id
          LEFT JOIN product_category p6_ ON p1_
    .id p6_.product_id
          LEFT JOIN product_language p8_ ON p1_
    .id p8_.product_id
    WHERE p0_
    .is_product AND (c5_.status OR p1_.default_category_id IS NULL) AND
         ((
    p1_.import_checked AND p1_.import_id IS NOT NULL) OR p1_.import_id IS NULL) AND
         
    p6_.category_id IN ('13''14''15''16''17''18''19''21''285') AND
         
    p1_.product_variant_id IS NULL AND p0_.status AND (p1_.in_sale OR (p1_.in_sale AND
                                                                                    
    p0_.stock >= 1)) AND (p8_.status OR p8_.status IS NULL)
    GROUP BY p1_.id DESC
    LIMIT 21 
    Ty joiny jsou tamkvůli kombinací počtu dotazů pro každý produkt/množství joinů.

    Pro každý produkt se navíc tahají štítky + překlad, je to rychlejší než to tahat najednou.


    ---
    sentosa
    to je zajímavé, to neznám - používá se to více nebo je to ojedinělé? Jeste dodam, ze to bezi na doctrine - cili nevim jak si to s tim poradi.

    ---------- Příspěvek doplněn 11.10.2018 v 09:11 ----------

    [/COLOR]
    Citace Původně odeslal Gabonator Zobrazit příspěvek
    čo ti hlási debugbar, koľko máš dotazov na DB?
    celkovy pocet dotazu je kolem 200, ale vsechny jsou celkem zanedbatelne i kdyz se sectou. Nejvetsi problem je vyber polozek / produktu,

  11. Zkuste si před ten dotaz hodit "explain" aspoň trochu vám to poradí (jestli to jede vůbec přes indexy, jestli tam neni prace na disku atd)

  12. Citace Původně odeslal JiriJiri Zobrazit příspěvek
    sentosa
    to je zajímavé, to neznám - používá se to více nebo je to ojedinělé? Jeste dodam, ze to bezi na doctrine - cili nevim jak si to s tim poradi.
    Jestli je to ojedinele, tak jenom proto, ze to lidi neznaj. Na doctrine to preci nebezi, ta ti to obsluhuje. A urcite to zvladne.
    Jeste koukam, ze tam mas group by. Je to kvuli duplicitam? Skus misto group by pouzit select distinct, je to mnohem levnejsi.

    Indexy problem nebudou, ale llidi stejne myslej klice a na ty se taky mrkni. Skoro to vypada ze p6_.category_id IN ('13', '14', '15', '16', '17', '18', '19', '21', '285') jsou stringy

  13. Citace Původně odeslal sentosa
    Ty potrebujes closure table - nejaky cesky navod zde http://blog.voracek.net/databaze/clo...-trochu-jinak/ nebo pogoogli najdes toho dost.
    Citace Původně odeslal JiriJiri
    to je zajímavé, to neznám - používá se to více nebo je to ojedinělé? Jeste dodam, ze to bezi na doctrine - cili nevim jak si to s tim poradi.
    DoctrineExtensions/tree.md at master · Atlantic18/DoctrineExtensions · GitHub

Hostujeme u Server powered by TELE3