Есть такая задача:
— Имеем ASP приложение, интенсивно общающееся с MS SQL. При этом, все запросы формируются прямо из ASP через механизм ADODB и т.д. Быстродействие уже давно оставляет желать лучшего.

Вопрос слебующего характера:
— Как можно исправить сложившееся положение ?

Перейти на использование ISAPI Extensions / Filters, или попробовать оптимизировать используемый механизм ?


C уважением, Виктор.

Здравствуйте VictorV, вы писали:

VV>Есть такая задача:
VV>- Имеем ASP приложение, интенсивно общающееся с MS SQL. При этом, все запросы формируются прямо из ASP через механизм ADODB и т.д. Быстродействие уже давно оставляет желать лучшего.

было-бы хорошо замерить, где самый медленный участок.

VV>Вопрос слебующего характера:
VV>- Как можно исправить сложившееся положение ?

сменить машину, на которой база вертится или сменить базу.

VV>Перейти на использование ISAPI Extensions / Filters, или попробовать оптимизировать используемый механизм ?

исходя из моего опыта: чаще всего тормозит база.
1) грамотно проиндексировать базу.
2) проабгрейдить машину для DB. если вертиться там-же где и web-сервер — перевести на другую.
3) продумать "сохраненные процедуры" для оптимизации наиболее частых запросов и "сборки мусора".
4) попробовать таки другую СУБД. :-)

VV>C уважением, Виктор.

Олег

Здравствуйте VictorV, вы писали:

VV>Вопрос слебующего характера:
VV>- Как можно исправить сложившееся положение ?

VV>Перейти на использование ISAPI Extensions / Filters, или попробовать оптимизировать используемый механизм ?

Переход на ISAPI здесь вряд ли поможет, а вот оптимизация процесс перманентный... ;))

Для начала надо посмотреть насколько грамотно БД спроэктирована, затем построить все нужные индексы, перенести большинство запросов в хранимые процедуры и заоптимизировать эти самые запросы до невозможного состояния. Ну и последним этапом поиграться с настройками ADO...

Здравствуйте Merle, вы писали:


VV>>Перейти на использование ISAPI Extensions / Filters, или попробовать оптимизировать используемый механизм ?

M>Переход на ISAPI здесь вряд ли поможет, а вот оптимизация процесс перманентный... ;))

Неужели перенос функции общения с базой из ASP в С++ программу (с использованием OLEDB) не даст заметного прироста производительности ?

M>Для начала надо посмотреть насколько грамотно БД спроэктирована, затем построить все нужные индексы, перенести большинство запросов в хранимые процедуры и заоптимизировать эти самые запросы до невозможного состояния. Ну и последним этапом поиграться с настройками ADO...

Спасибо. Попробую поиграть с БД.

Хранимые процедуры — оч-чень полезно!!!

Здравствуйте VictorV, вы писали:

M>>Переход на ISAPI здесь вряд ли поможет, а вот оптимизация процесс перманентный... ;))
VV>Неужели перенос функции общения с базой из ASP в С++ программу (с использованием OLEDB) не даст заметного прироста производительности ?

скорее — выростет время ответа сервера. :-)
у тебя добавиться еще одно звено при запросе.
...хотя — это как напишешь.
но скорее всего будешь пользовать то-же ADO, но уже из COM-а, написаного на C++. :-)

по "медленности" IMHO можно так расписать:
самый медленный — запрос ответ через интернет.
медленный — ответ базы.
быстрый — запрос в базу сервера.
самый быстрый — формирование запроса для базы.

но это — обычно. что у тебя конкретно — надо смотреть.
сделай пару тестовых программ, там разберешься, кто у тебя тормозит.

Олег

Здравствуйте VictorV, вы писали:

VV>Неужели перенос функции общения с базой из ASP в С++ программу (с использованием OLEDB) не даст заметного прироста производительности ?

Не а... Как правило самая медленная часть именно зпрос к базе... Это если ты пишешь афигенски навороченую систему к которой одновременно обращаются несколько сот юзеров, тогда имеет смысл задуматься о написании ISAPI Ext. и работать через него, но перед этим базау всё равно надо вылизать до блеска...

Здравствуйте Merle, вы писали:

M>...но перед этим базау всё равно надо вылизать до блеска...

А не подкините ссылки, где можно поподробнее узнать об оптимизации базы. Я конечно понимаю, что тема слишком обширная, но все-таки...Может есть несколько конкретных советов, так, для затравки...

Спасибо, Виктор

Здравствуйте VictorV, вы писали:


VV>А не подкините ссылки, где можно поподробнее узнать об оптимизации базы. Я конечно понимаю, что тема слишком обширная, но все-таки...Может есть несколько конкретных советов, так, для затравки...

Уфф... Ну например http://www.sql.ru. Если MSSQL, то Microsoft Books Online (BOL) — незаменимымая штука... А вообще тут действительно сложно советовать. Как показывает опыт, всё приходит с опытом... ;)))
А начать я бы советовал с вопросов проэктирования... Ошибки на этом этапе устранить потом сложнее всего.

Здравствуйте VictorV, вы писали:

VV>А не подкините ссылки, где можно поподробнее узнать об оптимизации базы.

Случайно наткнулся....
INF: Optimizing Microsoft SQL Server Performance
http://support.microsoft.com/support/kb/articles/Q110/3/52.ASP

Там правда написано, что всё это для 6.5, но это не так важно, общие принципы не меняются...

Здравствуйте, VictorV, Вы писали:

VV>Есть такая задача:
VV>- Имеем ASP приложение, интенсивно общающееся с MS SQL. При этом, все запросы формируются прямо из ASP через механизм ADODB и т.д. Быстродействие уже давно оставляет желать лучшего.

VV>Вопрос слебующего характера:
VV>- Как можно исправить сложившееся положение ?

VV>Перейти на использование ISAPI Extensions / Filters, или попробовать оптимизировать используемый механизм ?

ISAPI ИМХО не сильно поможет. Главное узкое место как мне кажется — это обращение к базе. Предлагаю:
1. Пересмотреть еще раз базу
2. Попробовать оптимизировать запросы
3. Если возможно — перевести на ASP.NET (главное, правильно спроектировать, иначе результата не будет).