Czy powinienem przejmować się wydajnością przy połączeniach z wieloma bazami danych?

Question

Mam aplikację PHP działającą na serwerze Apache z bazami danych MySQL. Na podstawie poddomeny, do której uzyskują dostęp użytkownicy, łączę je z bazą danych (sub1.domain.com łączy się z bazą danych database_sub1 i sub2.domain.com łączy się z database_sub2). Obecnie istnieje 10 kombinacji baz danych subdomeny, ale ta liczba może potencjalnie wzrosnąć do ponad 100.

Czy to źle?

Biorąc pod uwagę moją sytuację, czy mysql_pconnect jest drogą do zrobienia?

Dzięki, i proszę dać mi znać, jeśli więcej informacji byłoby pomocne.

Josh

Answer 1

To zależy częściowo od reszty konfiguracji, ale tak długo, jak każda transakcja obejmuje tylko jedno połączenie, a następnie kod klienta bazy danych należy wykonać jak można się spodziewać - w przybliżeniu taka sama jak z jednej bazy danych, ale z większymi możliwościami poprawy wydajności serwerów baz danych, aż do ograniczenia przepustowości sieci.

Jeśli w transakcji uczestniczy więcej niż jedno połączenie, prawdopodobnie potrzebny jest menedżer transakcji zgodny z XA, który zazwyczaj wiąże się ze znacznym narzutem wydajności.

Answer 2

Nie, to nie jest złe.

To raczej pytanie o liczbę równoległych połączeń w sumie. Można to zdefiniować za pomocą "max_connections" w ustawieniach mysql (domyślnie jest to 151 od MySQL 5.1.15) i jest ograniczone możliwościami twojej platformy (np. 2048 < w systemie Windows, więcej w systemie Linux), sprzętem (RAM) i ustawieniami systemu (głównie przez limit otwartych plików). Może to być wąskie gardło, jeśli masz wielu równoległych użytkowników, liczba baz danych nie jest ważna.

Zrobiłem skrypt, który łączy 400 + baz danych w jednym wykonaniu (jeden po drugim, nie równolegle) i znalazłem mysql + php, który radził sobie z nim bardzo dobrze (brak znaczących wycieków pamięci, brak dużego obciążenia). Zakładam więc, że nie będzie problemu z twoją konfiguracją.

I, finnaly - mysql_pconnect generalnie nie jest dobry, jeśli chodzi o tworzenie stron internetowych, jeśli nie ma znaczących kosztów związanych z łączeniem bazy danych per se. Musisz to zarządzać bardzo ostrożnie, aby uniknąć problemów z połączeniami max_connections, blokadami, skryptami oczekującymi itd. Myślę, że pconnect ma ograniczone zastosowanie (np. Zadanie cron uruchamiane co sekundę lub coś podobnego)

Answer 3

Czy to aplikacja, którą napisałeś? ?

Jeśli tak, z punktu widzenia konserwacji może to stać się koszmarem.

Co dzieje się po zmianie programu i konieczności zmiany bazy danych?

Jeśli nie masz słodkiego narzędzia do migracji, które pomoże Ci wprowadzić zmiany we wszystkich bazach danych do nowego schematu, możesz znaleźć się w świecie cierpienia.

Zdaję sobie sprawę, że możesz być teraz za daleko w tym projekcie, ale jeśli do schematu dodana została niewielka dodatkowa relacja w celu rozróżnienia domen (firm/użytkowników), możesz uruchomić je wszystkie z jednej bazy danych z niewielkim dodatkowym obciążeniem .

Jeśli wydajność naprawdę staje się problemem (Read this), możesz wdrożyć klastrowanie lub inne eleganckie rozwiązanie, ale przynajmniej nie będziesz mieć więcej niż 100 baz danych do utrzymania.