Puncte:0

Sortarea pe un câmp de dată personalizat este mai lentă decât sortarea după relevanță: există o soluție?

drapel pe

Folosesc API de căutare cu baza de date pe un site Drupal 9.3.3. Am indexat 26.000 de noduri de tip de conținut personalizat și acestea includ un câmp de dată personalizat: field_display_date

Indexul este configurat pentru a face html redat. Deoarece am nevoie ca utilizatorii să poată sorta pe field_display_date (descrescător), precum și pe relevanță, am expus două feluri: relevanță și dată (folosind acest câmp personalizat de dată) și am adăugat field_display_date la index în format „data”.

Scopul final este să puteți obține rezultate de căutare extrem de relevante, dar să le puteți sorta pentru a vedea cele mai recente rezultate extrem de relevante. Poate că există un mod complet diferit de a face asta.

Problemă: cu vizualizarea totul configurată, introduceți un termen de căutare și executați. Cu sortarea setată la „relevanța” implicită, returnările sunt destul de rapide. Dacă schimb sortarea la „data” (field_display_date: descendent) și trimit din nou, există un timp de așteptare foarte lung, adesea o expirare a gateway-ului.

Pe unul care nu a expirat, sql de vizualizare și redout de performanță a spus asta...

Interogare   
Index: principal2
Taste: „test”
Chei analizate: matrice (
    '#conjunction' => 'ȘI',
    0 => 'test',
  )
Câmpuri căutate: element_rendat, titlu
Sortare: field_display_date DESC
Opțiuni: matrice (
    'search_api_view' => 'obiect (Drupal\views\ViewExecutable)',
    'search_api_base_path' => 'search2',
  )
Căutare titlu2
Calea /căutare2
Timp de construire a interogării 1,43 ms
Timp de execuție a interogării 2,81 ms
Vizualizare timp de randare 43237,89 ms

De ce este timpul de randare atât de mare și există idei despre cum să corectați acest lucru? De asemenea, este probabil ca trecerea la apache solr să funcționeze mai bine sau să aibă același rezultat? (Deoarece configurarea solr pare destul de complicată și îmi va lua destul de mult timp, aș dori să știu dacă este probabil să merite făcută.)

În schimb, iată aceeași vizualizare și aceeași indexare și cuvânt cheie de căutare sortate după relevanță...

Interogare   
Index: principal2
Taste: „test”
Chei analizate: matrice (
    '#conjunction' => 'ȘI',
    0 => 'test',
  )
Câmpuri căutate: element_rendat, titlu
Sortare: search_api_relevance DESC
Opțiuni: matrice (
    'search_api_view' => 'obiect (Drupal\views\ViewExecutable)',
    'search_api_base_path' => 'search2',
  )
Căutare titlu2
Calea /căutare2
Timp de construire a interogării 1,23 ms
Timp de execuție a interogării 2,68 ms
Vizualizare timp de randare 2990,91 ms

Acest lucru pare să sugereze că căutarea în sine și obținerea rezultatului sunt ambele destul de rapide, dar din anumite motive încărcarea paginii este cu adevărat lentă?

Interesant, ocolirea completă a API-ului de căutare și doar plasarea câmpului corporal într-o vizualizare obișnuită și căutarea cuvântului cheie obține un rezultat mai rapid, ceea ce mă face să cred că fac ceva incorect la un nivel fundamental.

Filtru de vizualizări simple fără index, sortat după field_display_date descendent, căutând în câmpul de corp același cuvânt cheie...

Conținutul titlului
Calea /admin/content/node2
Timp de construire a interogării 3,23 ms
Timp de execuție a interogării 1,2 ms
Vizualizare timp de randare 6291,28 ms
sonfd avatar
drapel in
Data dvs. este sortată folosind datele din index? sau doar un câmp de dată obișnuit? Asigurați-vă că utilizați datele din câmpul de date indexate.
drapel pe
Este câmpul de dată indexat. Alte câteva detalii din analiză de până acum: timpul de randare este adesea mai rău dacă fac mai întâi căutarea cu sortare prin relevanță în filtrul expus, apoi îl schimb la data și aplic. Până acum, acel set de pași pare să fie mai rău decât a căuta mai întâi cu data în meniul derulant, dar sunt mai puțin sigur de asta. De asemenea: numărul total de accesări are un impact major. Mai mult = randare mai lungă. Vă poate ajuta să știți: vizualizarea nu include referințe la entitate la lucruri lente.
drapel pe
Un alt indiciu: dacă folosesc „html redat” în filtrul expus în loc de „căutare text integral”, rezultatele sortate după câmpul de dată personalizat (indexat) sunt mult mai rapide. Cu toate acestea, filtrul html redat nu oferă sortare prin relevanță. Poate că trebuie să utilizez implicit „sortare prin relevanță și text complet”, dar am un buton pentru a direcționa interogarea către „sortare dată și html redat”. Aș vrea să înțeleg de ce se întâmplă acest lucru.
drapel pe
S-ar putea să fie legat de această problemă: https://www.drupal.org/project/search_api/issues/3227268 O mare parte din discuția de acolo depășește nivelul meu actual de expertiză, așa că nu sunt sigur de relevanță.
Puncte:0
drapel pe

Aceasta este o soluție vagă, deoarece nu am putut determina de ce sortarea s-ar comporta în acest fel.

Pot raporta, totuși, că instalarea Solr și trecerea indexului la backend-ul Solr a dus la faptul că nu mai există nicio diferență vizibilă între un fel și celălalt.

Pentru a clarifica: aceleași vizualizări și câmpuri și aceeași configurație de index. (În API de căutare, puteți comuta backend-ul unui index, apoi puteți reindexa). Acest lucru a dus la sortări foarte rapide folosind aceleași pagini de vizualizare a rezultatelor căutării.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.