k00sl
25.04.2010, 20:18:52
Witam,
Mam do Was pytanie, otóż czy dobrym rozwiązaniem w kwestii wydajności względem bazy danych mysql było by dodawanie zapytań sql do pliku txt (linia po lini) poprzez php, a później wykonywanie tych zadań poprzez odpalonego crona? Nie wiem jakiego typu rozwiązania stosuje się przy bardziej rozbudowanych projektach. Szukam dobrego sposobu na obniżenie ruchu między www a bazą danych, więc każda porada będzie dla mnie pożyteczna. Oczywiście o cachowaniu danych wyjściowych jak najbardziej wiem, ale interesuje mnie wprowadzanie nowych danych, bądź aktualizowanie ich. Proszę o jaką kolwiek odpowiedz w tym temacie

Pozdrawiam
tehaha
25.04.2010, 21:01:42
tak to dobry pomysł, ale dlaczego do pliku .txt? robisz sobie normalne skrypty aktualizujące w plikach.php i potem ustawiasz żeby cron je odpalał cyklicznie w godzinach nocnych w zależności od potrzeb.
tehaha nie kumam, chcesz zmniejszyć transfer między serwerem www a baza danych, zmuszając serwer www do dodatkowej pracy (zrzucania pytań sql do pliku) a potem i tak wykonywać te pytania, tylko że pomiędzy shellem a baza danych?
dodatkowo te plik do którego zrzucasz pytania musi być blokowany na czas zapisu, serwer www musi czekać na zwolnienie blokady.
zacznij od upewnienia sie ze nie masz pytań typu select * - wybieraj tylko te kolumny które ci są potrzebne.
używaj cachowania tam gdzie możesz (apc lub memcacha, w ostateczności pliki)
tehaha
25.04.2010, 21:46:24
ale nie chodzi o gromadzenie wszystkich zapytań do pliku i odpalaniu ich później, bo to by było pozbawione sensu, tylko przerzucaniu nie których operacji na godziny nocne po to aby zmniejszyć ilość zapytań do bazy w czasie rzeczywistym odwiedzania serwisu przez użytkowników.
Przykładowo miałem serwis gdzie były oceniane materiały, waga oceny była uzależniona powiedzmy od rangi użytkownika, od liczby odsłon i jeszcze tam paru czynników, jeżeli przy sortowaniu materiału względem tej oceny miałbym tych obliczeń dokonywać w czasie rzeczywistym to musiałbym wykonać kilka połączeń do bazy, zamiast tego użyłem crona który wyliczał to cyklicznie w nocy i wstawiał wyniki do tabeli. Moim zdaniem było to dobre rozwiązanie ponieważ zamiast wykonywać 3 dodatkowe połączenia przy segregacji materiału mogłem to zrobić zwykłym LEFT JOIN'em bez dodatkowych połączeń czyli de facto zmniejszyło to całkowitą ilość połączeń.
to co piszesz jest jak najbardziej poprawne.
jak dla mnie to k00sl pytał właśnie o takie gromadzenie pytań
Cytat
czy dobrym rozwiązaniem w kwestii wydajności względem bazy danych mysql było by dodawanie zapytań sql do pliku txt (linia po lini) poprzez php, a później wykonywanie tych zadań poprzez odpalonego crona?
k00sl
26.04.2010, 08:44:49
No fakt zrzucanie poleceń do pliku było by nie stosowne i znacznie spowolniło by stronę. Zgadzam się z Tobą tehaha, że tego typu dane (obliczanie statystyk etc.) można przetworzyć w godzinach nocnych sam tak robię. Chodziło mi, aby oto aby zamiast kilku tysięcy połączeń do bazy danych (duża ilość użytkowników klikająca przycisk np. "Zapisz") jakoś to uszeregować, aby nie były aż takie zabójcze.Wygląda na to , że raczej nie pozostaje nic innego jak zrobienie clustra w MySQL, no cóż dzięki za odezwanie się w tym temacie.
ile masz połączeń na sekundę ?
to może jakiś demon z otwartym stałym połączeniem do bazy nasłuchujący na jakimś porcie będący pośrednikiem miedzy baza a www.
tehaha
26.04.2010, 15:16:43
Cytat(k00sl @ 26.04.2010, 09:44:49 )

(duża ilość użytkowników klikająca przycisk np. "Zapisz")
to w takim razie można rozważyć jeszcze jedną sytuację, ile połączeń jest wykonywanych żeby wprowadzić te dane? bo gdybyś miał sytuację, że np. odebrane dane trzeba porozdzielać do wielu tabel i taka operacja dla jednego użytkownika wymaga wielu połączeń z bazą to mogło by się opłacać, żeby umieszczać te dane w tymczasowej tabeli, a potem w nocy to porozdzielać jak trzeba automatem, to zmniejszyło by obciążenie w godzinach szczytu, ale takie rozwiązanie jest sensowne tyko wtedy jeżeli zapis danych dla jednego użytkownika wymaga wielu połączeń z bazą
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę
kliknij tutaj.