Optymalizacja zapisywania danych do bazy danych przez AJAX, Odpisze ktoś mądry? Opcje

[rugby]

Tworzę aplikację RIA, która działa w przeglądarce po stronie klienta i co jakiś czas zapisuje dane (np. położenie paneli) w wybranej tabeli w bazie danych, wysyłając je metodą POST przez AJAX. Biorąc pod uwagę, że równocześnie z aplikacji może korzystać kilkaset osób, jak zoptymalizować wydajność serwera WWW i bazy danych?

1. Tabela, do której zapisywane są dane, powinna mieć blokowanie na poziomie wiersza (a nie całej tabeli), zgadza się?
2. Trzeba zachować kolejność zapisywania, żeby pakiet, który został wysłany wcześniej, a dotarł później, nie nadpisał pakietu wysłanego w międzyczasie, tak?
3. Czy wywoływać zapis danych metodą POST w momencie zmiany położenia paneli (ludzie mogą bawić się panelami, generując dużo zapisów w jednym czasie), czy np. co 5 s. (niezależnie od tego czy użytkownik rusza panele są generowane zapisy)?
4. Na co jeszcze zwrócić uwagę?

[erix]

Zacznijmy od tego, czy POST rzeczywiście jest Ci tutaj potrzebny. Najprostszy GET wystarczy, nawet wywoływany przez fikcyjny obrazek.

3. Czy wywoływać zapis danych metodą POST w momencie zmiany położenia paneli (ludzie mogą bawić się panelami, generując dużo zapisów w jednym czasie), czy np. co 5 s. (niezależnie od tego czy użytkownik rusza panele są generowane zapisy)?

Ja bym to zrobił inaczej: user zaczyna się bawić i odpalasz stoper (setTimeout). Jeśli w ciągu tych np. 5 sekund znowu poruszy, resetujesz stoper. I jeśli przestanie się bawić -> wówczas stoper się wykona, Ty zapisujesz dane do bazy i czekasz na kolejny ruch.

I teraz co i po co:

• stoper: umożliwia zareagowanie na chwilową przerwę w zabawie widgetami; czas opóźnienia musisz dobrać wg testów
• zerowanie - jeśli znowu zacznie się bawić, wtedy na czas drag'n'dropa zamrażasz odliczanie i czekasz aż przestanie się bawić
• ondrop znowu start stopera i jeśli nie będzie się bawił, wtedy możesz spokojnie zapisać na serwerze

I teraz sprawa po stronie serwera: jeśli obciążenie jest naprawdę duże - zrób plik log-transakcyjny zamiast bezpośredniego zapisu do bazy.