Zmiana mechanizmu w Blocksearch.php na bardziej wydajny i prosty

[hakeryk2]

Witam,

 

Mam takie pytanie: ogólnie denerwuje mnie wbudowana funkcja wyszukiwania produktów w preście 1.6 - jest ociężała, wpływa na nią multum czynników, wyszukiwanie mocno obciąża bazę i ogólne regenerowane indeksu wyszukiwania jest upierdliwe. Ponadto strasznie źle radzi sobie z frazami pokroju k-1, km-2 itp 

 

Istnieje natomiast w zapleczu mechanizm wyszukiwania produktów powiązanych przy dodawaniu produktów który działa wręcz perfekcyjnie i szybko i czy da się go podpiąć by w taki sam sposób wyszukiwał moduł blocksearch.php?

 

 

[() Maciej ()]

Też się nad tym zastanawiam. Te same bolączki mi nie dają spokoju (tzn mam sporo kodów produktów o strukturze litera myślnik cyfra).

Ten mechanizm z tego co zdążyłem ogarnąć jest w plikach AdminSearchController.php oraz AdminSearchEnginesController.php ale jeszcze nie próbowałem ich przenosić :/ Brak czasu na wszystko ponad planowe niestety.

[hakeryk2]

Ogólnie jest tak, że ja już sobie nawet własne zapytanie mySql sformułowałem w jednym z modułów do wyszukiwania produktów w ajaxie i działa ono świetnie, ba nawet zrobiłem sobie opcję z kombinacjami itp bo akurat takiej potrzebowałem, ale po prostu pytam czy ktoś może już coś takiego zrobił. Jeśli nie, to się za to zabiorę i podrzucę efekt na czasie.

 

Gorszym problemem jest to, że Presta i tak w tle będzie np przy zapisywaniu produktu czy coś będzie odświeżać indeks wyszukiwania dla danego produktu, ale te override sobie podaruje.

[() Maciej ()]

Jakby co to piszę się na testy Mi ostatnio na wszystko brakuje czasu niestety. Podnoszenie wersji 2 sklepów jednocześnie, które są powiązane skryptami synchronizującymi sypie co chwilę błędami więc na najbliższy miesiąc mam co robić :/

[hakeryk2]

On 18.09.2017 at 0:14 PM, () Maciej () said:

Jakby co to piszę się na testy Mi ostatnio na wszystko brakuje czasu niestety. Podnoszenie wersji 2 sklepów jednocześnie, które są powiązane skryptami synchronizującymi sypie co chwilę błędami więc na najbliższy miesiąc mam co robić :/

Natknąłem się przy okazji na świetne rozwiązanie które mega przyśpiesza działanie wyszukiwarki poprzez zwykłe dodanie klucza indeksu w tabeli. Odpal PhpMyAdmin i w SQL wykonaj ten kod.

 

ALTER TABLE `ps_search_index` DROP KEY `id_product`;
ALTER TABLE `ps_search_index` ADD KEY `id_product` (`id_product`,`weight`);

Zobacz następnie jak wyszukiwarka zapitala

[() Maciej ()]

Nie wiem jak u Ciebie, ale ja w sklepie stawianym na 1.6.1.17 mam w tabeli ps_search_index 3 kolumny : id_product, id_word, weight.

Jak dobrze rozumuje skrypt usunie z tablicy "id_product" i wstawi "id_product" oraz "weight", więc w moim przypadku nastąpi duplikacja nazw kolumn.

 

Choć tu nie jestem do końca tego pewny, bo nie bardzo kojarzę składnie "DROP KEY".

[e_com]

@() Maciej () nic nie musisz robić, masz dobrze w tej najnowszej wersji. W jakichś staroć wersjach to brakuje tego klucza indeksu.

[() Maciej ()]

Tak właśnie myślałem Dzięki e_com za potwierdzenie moich przypuszczeń

Choć nie powiem jestem ciekaw, czy da się jakoś ulepszyć tą wyszukiwarkę presty. Dość wkurzające jest jej obecne działanie kiedy przy 20k produktów wpisuje pełny kod produktu, a wyszukiwarka zamiast dopasować kod w 1 kolejności wyrzuca ten produkt gdzieś pod koniec pierwszej strony. Tak jakby miała gdzieś priorytety ważności poszczególnych elementów składowych ustawionych w panelu.

Żeby nie było kod ma u mnie najwyższy priorytet i a reszta rozdzielone priorytety ważności z wykorzystaniem całego dostępnego zakresu.

[e_com]

Stopniowanie wag spróbuj zwiększyć. Np. dla indeksu daj 2x większą wagę.

Oczywiście po takich zmianach należy indeks wygenerować ponownie.

[hakeryk2]

Eh, czyli mój entuzjazm wynikał tylko i wyłącznie z tego, że miałem starszą wersję. Dobra. 

Mam natomiast kolejny "issue" który u mnie występował - nie wiem jak u was, ale jest to dosyć ciekawe. Otóż.

Mam około 8 000 produktów, ~23 000 kombinacji, w ustawieniach wyszukiwania mam wagi tylko dla nazwy (10), indeksu (4), producenta i tagów (2) i w tabeli ps_search_index miałem na świeżo po odbudowaniu całego indeksu ponad 500 000 rekordów. Wartość wydawała mi się nie co za dużo, więc chciałem zobaczyć co się dzieje w momencie gdy odbudowuje indeks na nowo, czy tabela czyści się cała czy może jednak nie. 

No i ogólnie wyszło na to, że tabela się nie czyści tylko zostaje na około 450 000 rekordów i ponownie indeksuje się jakieś 56 000 rekordów i tak za każdym razem, więc zaryzykowałem i wyczyściłem tabele ps_search_index oraz ps_search_word ręcznie i wygenerowałem na nowo cały indeks wyszukiwania i nieco przyśpieszyło teraz wyszukiwanie. Zalecam sprawdzenie czy u was też może taka sytuacja miała miejsce czy tylko w starszych wersjach.

Stare wpisy mogły po prostu zostać z początków gdy np krótki opis był brany pod uwagę.

Edited November 10, 2017 by hakeryk2 (see edit history)

[() Maciej ()]

ps_search_word zawiera słowa, które są wyszukiwane w wyszukiwarce i zostały odnalezione przy jakimś produkcie.

A więc jak tylko wygenerowałeś index na nowo i wyszukałeś jakąkolwiek frazę to ona się pojawi na liście jeśli nie występowała wcześniej.

Ma to niby na celu poprawienie wydajności samej wyszukiwarki, jak również trzymać statystyki słów wyszukiwanych.

[e_com]

Z Changloga ostatniej wersji 1.6.1.17:

- Core:
  - Improvement:
    - #8199: Speed up search queries

Opis jest enigmatyczny, ale to może być setki poprawek w kodzie.

[Piotr K.]

8 hours ago, () Maciej () said:

Jak dobrze rozumuje skrypt usunie z tablicy "id_product" i wstawi "id_product" oraz "weight", więc w moim przypadku nastąpi duplikacja nazw kolumn.

Źle rozumie, polecenia nie zmieniają zawartości tabel a tylko zmieniają indeks.
E-com ta poprawka to tylko zmiana klucza w bazie danych.