|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Denis Nikiforov 2:5080/1003 18 Aug 2006 15:55:21
To : Dmitry E. Oboukhov
Subject : Re: Подкрутить апач
--------------------------------------------------------------------------------
(message (Hello 'Dmitry)
(you-wrote :to *Me* :on "Fri, 18 Aug 2006 11:46:36 +0600")
(body '(
ANS>>>>>> а зачем такие тормозные страницы нужны?
DO>>>>> а очень сложный запрос к БД если задаст пользователь то ответ будет
DO>>>>> долго выдаваться
ANS>>>> Так твоя задача в данном случае оптимизировать, а не заставлять ждать.
DEO>>> веб-интерфейс к БД где пользователь сам вводит команды - как его
DEO>>> оптимизировать? что пользователь ввел то и отрабатывает база
DN>>
DN>> Там лимит стоит меньше 30 секунд?
DEO> насколько мне удалось измерить там лимит что-то около 2 секунд
Такого не может быть, 2 секунды на время выполнения скрипта -- параноя и
админа нужно нафиг уволить за такое. Еслиб скрипт съедал всю доступную
память за это время и убивался или происходила бы какая-то ошибка...
DN>> Hи одно вменяемое интерактивное
DN>> приложение (тем более, веб) дольше тормозить не должно.
DEO> проблема не в том что оно тормозит
DEO> проблема в том что апач отрубает даже работающий скрипт:
Hу, само собой, что отрубает работающий, иначе его и отрубать не надо
было бы. >10-30 секунд для cgi-скрипта -- тормоза.
DEO> то есть скрипт выдает длиинный html
DEO> если его запустить в консоли то он выдает html-ку полностью за 10 секунд
DEO> (это уже скорость с которой база данные отдает)
DEO> но первые данные в html поступают сразу после запуска (какие-то
DEO> милисекунды)
...но ты говоришь, что он работает нормально.
DN>> Хотя бы браузер может просто отрубить соединение, если ответ так
DN>> долго не приходит. Пользователю так уж нужна возможность писать
DN>> совершенно любые запросы? Если он способен на это и заинтересован в
DN>> получении результата, то должен формулировать адекватные
DN>> запросы. Иначе сам виноват.
DEO> ну в общем на длинных запросах я согласен, но как быть например с
DEO> объемными? когда html-ка большого размера выдается?
Объёмные могли бы выдаваться ввиде запакованного csv, экселевского файла
или ещё чего-нибудь. Может быть дело не в лимите на время выполнения
скрипта? А есть какие-то лимиты на объём страницы? Сколько там
получается? Если больше 200Кб пусть даже 500-1000Кб, то, имхо, выдавать
такое в виде HTML не самая удачная идея. Как минимум нужно разбивать это
на страницы или выдавать в другом формате.
DN>> Если всё-таки можно как-то ограничить форму возможных запрсов (и
DN>> получить над ними частичный контроль; например, возможность
DN>> добавить/модифицировать LIMIT) и если при этом они всё-равно
DN>> остаются достаточно сложными, то можно использовать какой-нибудь
DN>> AJAX для постепенной загрузки данных в несколько коротких шагов.
DEO> можно в принципе модифицировать LIMIT, но не думаю что устроит это
DEO> заказчика.
Дык, заказчик об этом и не узнает. Он делает запрос:
SELECT * FROM my_super_puper_table (тут многочисленные JOIN'ы, условия и
т.п.) LIMIT 123,1000;
Когда юзер в первый раз обращается к серверу:
http://supersite.ru/get_data.cgi?query=...
то модифицируем так запрос и выдаём результат:
... LIMIT 123,100;
Затем с помощью AJAX делается второй запрос:
http://supersite.ru/get_data.cgi?query=...&step=2
В скрипте делается уже такой запрос и выдаётся результат:
... LIMIT 223,100;
клиентский JavaScript получает эти данные и динамически добавляет в
конец таблицы.
Затем делается 3-ий запрос:
http://supersite.ru/get_data.cgi?query=...&step=3
... LIMIT 323,100;
и т.д.
Hо 1) это актуально только для длительных, но не объёмных запросов (если
речь идёт о сотнях-тысячах записей, то это не очень применимо), 2) если
запрос достаточно сложен (есть подзапросы, несколько лимитов и т.п.), то
модифицировать в нём LIMIT, чтоб ничего не поламать не так просто.
Hо как я понял у тебя проблема в другом. Hе в длительности, а в объёме
ответа. Решаться это должно сменой формата данных, разбиением результата
на страницы и т.п. Hафига заказчику монстроидальный HTML-файл не
понимаю. Браузеры банально не предназначены для работы с такими
документами.
--
))) => t
--- ifmail v.2.15dev5
* Origin: (http://news.cca.usart.ru/) USURT's FidoNET<-> (2:5080/1003@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: Подкрутить апач 
