Obsługa tego parametru pochłania dość dużo mocy. Aktualnie rozbiłem cały proces na dwa zapytania tak, aby nie przeciążyć za bardzo pięciu LEFT JOINÓW :), jednak testy wydajnościowe na zwielokrotnionej bazie wpisów Dzienników Zyxowych pokazały, że nadal powstaje problem, bo tak czy siak te 1000 ID jest ładowanych do skryptu i dopiero tam eliminowanych. Nie udało się napisać zapytania SQL, które wyeliminowałoby je już na poziomie bazy danych - zmodyfikowana metoda preorder używana do przechodzenia drzewa musi mieć trochę wsparcia ze strony jakiegoś języka programowania, aby zadanie to było wykonalne.
Po paru przemyśleniach otrzymałem dwa rozwiązania tego problemu:
- Napisanie specjalnego, wysokopoziomowego menedżera cache, który aktywowałby się, gdyby otrzymana w zapytaniu ilość rekordów przekroczyła setkę. Pozwoliłby on wtedy PHP na uszczuplenie zbioru o rekordy, których nie będziemy wyświetlać, a następnie scache'owałby wynik, co przy kolejnych wejściach zmniejszyłoby obciążenie i wyeliminowało jedno zapytanie. Wymaga to jednak wprowadzenia paru dodatkowych poprawek do DAO, które czyściłyby jeszcze jeden cache w przypadku modyfikacji danych.
- Takie przerobienie skryptu, aby w wypadku rozpoczęcia renderingu od obiektu z flagą "Wyświetlanie użytkownika", automatycznie olać wszystkie następne rekordy dzięki klauzuli LIMIT.
Optymalizacja nigdy nie powinna być lekceważonym etapem, szczególnie gdy korzystamy z niestandardowych struktur danych oraz kilkunastolinijkowych zapytań. Wtedy każda, nawet najmniejsza idea, decyduje o być albo nie być projektu na większym obciążeniu.
Napisał serafin w poniedziałek, 31 lipca 2006 o 16:05
Mnie natomiast na uczelni uczono ze zeby optymalizowac trzeba miec finalny pod wzgledem funkcjonalnosci program. Dobrze napisane API pozwala na zastapienie zlych rozwiazan nowymi bez dodatkowego grzebania w kodzie :)