Czy serwer MySQL rozwiąże potrzeby serwisu z ruchem 2-5k /dzień ?

[Piter77]

Witam wszystkich maniaków PHP i MySQL!

Kilka lat temu zrobiłem coś, czego nie spodziewałem się, że osiągnie dobrą oglądalność ale nie o tym chcę napisać.

Mam serwis dla ciężarnych, cały silnik stworzyłem w PHP bo nie wyrabiał już w Joomli przy średnim ruchu 1k - wtedy wziąłem sprawy w swoje ręce i postawiłem wszystko na własnym silniku - bez żadnych frameworków.

Obecnie ruch jak w temacie - 2-5k / dzień. Wszystko musi leżeć na dedyku bo np. Home nie pozwala na takie operacje jak kilkudziesięciominutowe działanie crona, który generuje mapę stron dla Google itp. historie, mimo konta Business Server PRO. Mam to więc na dedyku w niemczech i płacę ok. 300 zł / mc.

Zauważyłem, że moim głównym problemem jest nie hosting, lecz sama BAZA DANYCH MySQL, więc pomyślałem, że może zapytam fachowców - czy znacie coś takiego jak hosting na najwyższym poziomie lecz przeznaczony wyłącznie pod bazy danych ?

Po co mam płacić 300 zeta / m-c tylko za to, że serwer nie wyrabia przez bazę ?

Proszę o pomoc.

Piotrek

[Cosmoweb]

Ja nie znam, ale może pomyśl o jakiejś optymalizacji bazy danych.

[Marek607]

Masz może jakieś wyniki/analizy jakie zapytania obciazają baze danych i w jakim stopniu?

5k uuu/dzień to nie jest tak dużo i dedyk powinien spokojnie to obslużyć - zapewne wina leży albo w samym skrypcie , czyli nieoptymalne zapytania/brak indeksów itp i to zajeżdża mysql-a, albo źle zoptymalizowany serwer.

Żaden hosting współdzielony nie pozwoli ci na wykonywanie zadania cron przez kilkadziesiąt minut

[Piter77]

Domyślam się, że problem leży głównie w dwóch tabelach forum.

Całe forum ma około 1,3 mln wpisów napisanych przez ok.14k userów, więc tablica z nagłówkami wątków ma prawie 1,3 mln rekordów (10 pól). Do tego muszę połączyć ją z tablicą userów, która ma 53 pola.

Problem może leżeć właśnie w tym miejscu. Poza tym mam serwer w hetznerze, gdzie w ciągu 6 miesięcy już dwa razy dali mi uwalony hdd - raz wymieniali, obecnie nie działa nawet raid0 i kazali zrobić kopię na własną rękę bo po wymianie będzie czysty. Ręce opadają...

Dlatego chciałem przenieść samą bazę na inny serwer, a serwis postawić na współdzielonym serwerze np. w Home bo już mam dość hetznera. Obawiam się tylko jak to będzie chodziło, gdy baza będzie w innej lokalizacji, niż strona.

[Piter77]

Masz może jakieś wyniki/analizy jakie zapytania obciazają baze danych i w jakim stopniu?

5k uuu/dzień to nie jest tak dużo i dedyk powinien spokojnie to obslużyć - zapewne wina leży albo w samym skrypcie , czyli nieoptymalne zapytania/brak indeksów itp i to zajeżdża mysql-a, albo źle zoptymalizowany serwer.

Żaden hosting współdzielony nie pozwoli ci na wykonywanie zadania cron przez kilkadziesiąt minut

chyba coś pokręciłem, chodzi o kilkuminutowe działanie - 5-10 minut.

Z tabeli 1,3 mln rekordów buduję google sitemap z linkami.

[Mion]

Dlatego chciałem przenieść samą bazę na inny serwer, a serwis postawić na współdzielonym serwerze np. w Home

Niczym kombinacje konia pod górkę !

Obecnie ruch jak w temacie - 2-5k / dzień.

Taki ruch to w zasadzie zastój jak na serwer dedykowany.

chodzi o kilkuminutowe działanie - 5-10 minut.

Jak masz serwer dedykowany to wielominutowe działania można wykonywać w trybie CLI PHP o ile PHP ma odpowiednie ustawienia czasów wykonywania operacji.

Tak, czy inaczej masz kiepskie oprogramowanie z błędami w jego logice, bo ruch o jakim piszesz to żaden ruch.

Zainteresuj się:

- memcache;

- optymalizacją ustawień MySQL i optymalizacją zapytań https://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html | https://dev.mysql.com/doc/refman/5.0/en/explain.html

- zmianą logiki dla operacji crona np ich rozbicie na mniejsze - krótsze operacje lub trybem PHP CLI;

- składowaniem mapy serwisu w plikach;

- itd...

[VMline]

SSD/MariaDB (mysql), varnish, nginx, php-fpm Polecam najlepiej wszystkie opcje.

[Piter77]

Dzięki za wszystkie celne uwagi

[Leszczu]

Kiedyś, o ile dobrze pamiętam, były problemy z forami typu phpBB ponieważ w jednej z tabel bazy danych forum zbierało zapytania wpisane w szukajkę i ta tabela potrafiła rosnąć baaaardzo duża. Wręcz nieproporcjonalna do wielkości pozostałej części bazy.

[Piter77]

Kiedyś, o ile dobrze pamiętam, były problemy z forami typu phpBB ponieważ w jednej z tabel bazy danych forum zbierało zapytania wpisane w szukajkę i ta tabela potrafiła rosnąć baaaardzo duża. Wręcz nieproporcjonalna do wielkości pozostałej części bazy.

no i właśnie z tego powodu napisałem skrypt własnego forum.

Problem, że to moje też, choć trochę lepiej zrobione (wyniki nie są wypluwane do tablic) to nie jest do końca idealne lub po prostu jest zbyt dużo danych w jednej tabeli (1,3 mln + 14k z drugiej)

[Mion]

1,3 mln + 14k z drugiej

To nie są aż tak duże tabele by stanowiły znaczący problem. Ewidentnie jest błędnie = nieoptymalnie to wszystko napisane. Jeśli tabela ma prawidłowe indeksy, a serwer odpowiednio dużo RAM całe indeksy tabeli powinny mieścić się w RAM, więc wybieranie rekordów powinno być szybkie. Wolniej będzie działać aktualizacja w takiej tabeli, bo indeks musi się przebudować.

Zależy też jakie to są tabele i jaka wersja MySQL.

Poza tym nic konkretnego nie piszesz o problemie, więc nawet nie wiadomo co tak naprawdę go powoduje.

Wykonywałeś chociaż analizę wolnych zapytań slow query oraz wyniki EXPLAIN , sprawdzałeś co stanowi wąskie gardło

[INOMan]

Pewnie brak odpowiednich indeksów na tabelach, nieodpowiednio skonfigurowany serwer mysql...

Co do memcached to polecam zamiast tego APC. Memcached przy dużym obciążeniu ujawnia swoje bugi.

APC ładnie pracuje bez problemów nawet w duzym stresie i można go użyć nie tylko do akceleracji skryptów ale także jako mechanizm keszujący zamiast memcached.

[Piter77]

indeksy są i zakładałem je dla pól, po których filtruję i porządkuję dane. Może problem w tym, że przez to, ze jest indeks, założenie nowego rekordu na dużej tablicy trwa dłużej.

Serwer mysql również optymalizowałem, dałem dużo pamięci na cache oraz na indeksy.

Macie racje, muszę najpierw wszystko pomierzyć - ile wykonuje się najdłuższe zapytanie itd. Problem większy w tym, że czasem strona wyświetla się błyskawicznie, a czasem muszę czekać nawet do 10 sekund na reakcję serwera - z tym szlag mnie trafia.

[INOMan]

indeksy są i zakładałem je dla pól, po których filtruję i porządkuję dane. Może problem w tym, że przez to, ze jest indeks, założenie nowego rekordu na dużej tablicy trwa dłużej.[...]

Tak. bo mysql z technicznego punkty widzenia to nie za dobra baza, nawet dość kiepska w porównaniu z innymi, ale za to, niestety, popularna. To zresztą nie zależy tylko od indeksów tylko danych w ogóle, czym więcej danych tym dłużej trwają niektóre metaoperacje na tabeli w mysqlu.

Np. w darmowym postgresqlu możesz mieć tabele nawet z 5GB danych i miliardami rekordów a mimo to np. dodanie nowej kolumny do tabeli trwa krótko.

[monterek]

SSD/MariaDB (mysql), varnish, nginx, php-fpm Polecam najlepiej wszystkie opcje.

Tez polecam takie połączenie, ale wystarczy zamina na ssd +varnish bo memcache jest wolny w porównaniu do varnisha