Witam,

Napotkałem męczący problem całkowie blokujących requestów i tak naprawdę nie wiem jak można sobie dać z tym radę.
A mianowicie jest taka sytuacja:
Otwieram stronę na której jest żądanie ajax wykonujące się 10 sekund i niestety podczas tych 10 sekund (żądanie ajax) nie mogę przejść na inny link (w obrębie tej samej domeny/serwera) dopóki nie zakończy się żądanie ajax.
Zatrzymanie żadania nic nie daje, skrypt musi się zakończyć na serwerze.
Próbowałem ustawić ignore_user_abort na false ale to raczej nie tędy droga.
Czy jest do tego odpowiednie ustawienie serwera apache czy niestety nic nie da się z tym zrobić?

EDIT:
Jedna rzecz, która mi jeszcze wpadła do głowy to może konieczność dodania pewnego nagłówka do żądania?

Nie wiem czy to Ci pomoże, ale spróbuj AJAX pchać nie poprzez stronę główną, ale subdomenę. Kiedyś tak się obchodziło ograniczenia IE6, które mogło z jedną domeną nawiązać tylko jedno połączenie. Tworzyło się wtedy ileś subdomen i wszystkie kierowały do tego samego zasobu. Tak działa choćby googlemaps. Przyjrzyj się w firebugu temu jakie mają adresy poszczególne kafle map. są pchane przez subdomeny m1, m2, m3, m4, by przyspieszyć ładowanie w wyniku nawiązywania kilku połączeń. Może w tym kierunku próbuj, poprzez pchniecie AJAXa, nie główną domeną, ale subdomeną specjalnie dla AJAXów stworzoną

Hej,

Ciekawy temat, pierwsze co mi przychodzi do głowy to przeniesienie tego żądania na inny serwer, jednak wiem że to rozwiązanie nie jest idealne i wiąże się z pewnym ryzykiem przebudowy aplikacji. Ten skrypt, który się wykonuje żądaniem ajax'owym widocznie stwarza duże obciążenie, może dasz radę go zoptymalizować? Ile w sumie się wykonuje?

Poszukam jeszcze informacji na ten temat może coś znajdę.

~thek pomysł ciekawy i sprawdzę czy działa nie blokująco
~strife około 10 sekund, jeżeli chodzi o optymalizację to nic nie zrobię, ponieważ gdyby to był mój system to skrypt nie działał by dłużej niż jedną sekundę, a teraz przebudowywanie molocha byłoby niezwykle trudne
Aczkolwiek nie jest to dla mnie ogromnie potrzebne lecz na przyszłość przydałaby się wiedza, która owy problem rozwiązuje. Przetestuje z subdomenami i pochwalę się wynikami

Okazało się, że to nie ma nic wspólnego z apachem ani innymi ustrojstwami. Wina leży po stronie standardowej sesji.
Skrypty bez niej działają "wielowątkowo".
Standardowa sesja działa na plikach i podczas wykonywania jednego skryptu plik sesyjny jest zablokowany i żaden inny skrypt nie jest w stanie skorzystać z sesji dopóki plik nie będzie odblokowany (dlatego oczekuje na jego dostępność)
Możliwe rozwiązania to:
- wyłączenie sesji dla ajaxa
- przerzucenie sesji do bazy (zmiana save_handlera)
- wywołanie session_write_close znacznie wcześniej

Dzięki wszystkim za chęć pomocy

A nie możesz włączyć synchronicznego żądania?

Jeśli chodzi o inne kwestie - spróbuj workera wydzielić do osobnego skryptu i odpalać w ten sposób: http://www.ibuildings.co.uk/blog/archives/...-with-CURL.html


Tak btw, to co ten skrypt mieli, że aż 10 sekund zajmuje?


Nie zdziwiłbym się, gdybyś wpadł z deszczu pod rynnę. Jeśli chodzi o bazę, to w większości wypadków są w niej trzymane tylko metadane sesji (IP, user agent, jakieś mniejsze pierdoły), ale same dane sesji są trzymane w plikach. (mam tu na myśli tabelę MEMORY, inne raczej nie będą miały zbyt wielkiego sensu).

Jeśli nie masz innego wyjścia, a chcesz mielić w sesji tyle, ile masz, to napisz handlera trzymającego dane sesji via memcached. Tylko nie zapomnij o napisaniu blokera, żeby ktoś inny nie nadpisał. Ale jak to zrobić, to jest nawet w manualu PHP napisane, w którymś komentarzu.


To też jest wyjście, zakładając że dalej już nie potrzebujesz dostępu sesji.

Dobry pomysł, będę pamiętał na przyszłość


Dane statystyczne na sporej tabeli. Nie wnikajmy w to, bo jak pisalem nie chodzi mi o optymalizację


Jeżeli chodzi o session handler to po prostu nie blokuje pliku podczas korzystania z sesji.

No to w tym wypadku lepiej wcześniej skończyć sesję, chyba że operujesz na jakichś danych w niej zapisanych.

Można by było wtedy pójść na kompromis i zrobić kopię na czas miętolenia statystyk, ale pozostaje jeszcze kwestia łączenia danych po zmianach (w czasie nawigowania na innych podskryptach).