ru.cgi.perl

 
 - RU.CGI.PERL ------------------------------------------------------------------
 From : Artem Chuprina                       2:5020/371.32  07 Jul 2000  11:37:09
 To : Alexander Temerev
 Subject : Re: Session Management
 -------------------------------------------------------------------------------- 
 

 <Alexander_Temerev@p6.f21.n5004.z2.fidonet.org> wrote:
 
  AT>>>  Работает скрипт - поисковик. Работает он приблизительно так: для
  AT>>> каждого запроса делает CREATE VIEW, после чего пользователь по
  AT>>> нему может лазить и выводить нужные результаты. Задача - делать
  AT>>> DROP VIEW после того, как
  AT>>> перестал с ним общаться. Возможные средства решения: CGI/Perl +
  AT>>> Cookies, mod_perl. Что делать?
  AC>> Ввести удовлетворяющее тебя определение "клиент перестал с ним
  AC>> общаться", и по наступлении соответствующего события делать DROP VIEW.
  AC>> Внешним процессом, скорее всего.
 
 AT>  Тааак. То есть без внешнего процесса не обойтись. Впрочем, меня вполне
 AT>  удовлетворит определение "не проявляет активности в течение энного
 AT>  времени".  Как тогда?
 
 Тогда отмечать факт активности данного клиента на данном view в некоторой
 таблице. И по крону запускать либо держать демоном что-нибудь душевное,
 которое раз в проверяет оную табличку на предмет устаревших сессий и делает им
 DROP VIEW.
 
  AC>>  А вообще я бы не рекомендовал - если
  AC>> у тебя нагруженный сервер, то БД не переживёт столько views
  AC>> одновременно. Делать запрос каждый раз, скорее всего, дешевле.
 
 AT> Замерял производительность - нифига подобного. Уж чего-чего, а VIEWS в
 AT> нормальных базах может быть много. Главное - убивать их вовремя, дабы уж
 AT> совсем много не формировалось...
 
 Сколько? Давай считать. Hагруженный поисковик (допустим, мы пока не про
 альтависту и даже не про рамблер) должен выдерживать не менее 10 запросов в
 секунду. По моему опыту лазания по поисковикам повторных (к тому же view) не
 более половины, а таймаут неактивности - не менее получаса. Итого в течение
 получаса 5 новых view в секунду.
 
 ==== 8< [!echo '5*60*30' | bc] ====
 9000
 
 ==== >8 [!echo '5*60*30' | bc] ====
 
 9000 views одновременно. А если ещё многие из них делают себе большие
 временные таблицы....
 
 AT>  Впрочем, было найдено альтернативное решение - использовать курсоры. Хотя
 AT>  их ведь тоже нужно каким-то образом DROP-ать... Да и транзакции
 AT>  закрывать... А без нормального распараллеливания транзакций оно вообще не
 AT>  работает...
 
 AT>  Hаверное, придется все же делать так:
 
 AT>  1) Транслируем запрос пользователя в SQL-запрос
 AT>  2) Создаем курсор для этого запроса
 AT>  3) Извлекаем нужные значения по этому курсору
 AT>  4) Закрываем курсор
 AT>  5) Убиваем хандлер запроса
 AT>  6) Выводим результаты пользователю
 AT>  7) Убиваемся, сохраняя открытым соединение с базой.
 
 8) По приходе нового запроса мучительно пытаемся получить то самое соединение
 с базой, где был тот курсор.
 9) Предположим, мы даже решили эту задачу (DBD::Proxy нам поможет).
 10) Открываем курсор.
 11) Фетчим результаты предыдущих обращений (или у твоих курсоров бывает
 быстрый seek?)
 ...
 
 N) Осознаём, что не держать курсор было бы дешевле.
 
 AT>  Вроде бы, при наличии mod_perl и постоянного соединения с базой,
 AT> производительность должна быть достаточной для серьезного использования...
 
 Я бы скорее пробовал так: для типичных запросов создаются stored procedures,
 что даёт базе возможность избавиться от компиляции SQL-запроса. Даже если их
 будет несколько десятков, это фигня по сравнению с несколькими тысячами views
 или курсоров. Hетипичные запросы редки, а для типичных несколькими десятками
 обойтись удастся. Держим постоянное соединение с базой и 
 
 $sth = $db->prepare("execute sp_smth ".join(", ",map($db->quote($_),@args)));
 while (...)
     $sth->fetch
 }
 
 $sth->finish
 
 -- 
 Счастливо!
   Ран.
 --- ifmail v.2.14.os-p7-tma3
  * Origin: MemoNet (2:5020/371.32@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

Тема:    Автор:    Дата:    Re: Session Management   Artem Chuprina   07 Jul 2000 11:37:09   Session Management   Alexander Temerev   08 Jul 2000 20:36:22