|
|
|
Supreme Being
участник
Last Login: 23.05.2007 20:20
Сообщ.: 662,
Visits: 5 795
|
|
Эээ, boombastik, я бы не был столь категоричен по поводу драйвера. Почему? Потому что вспоминается мне опыт, когда пришлоcь декомпилировать оракловый драйвер. И вот что там было обнарудено: если тип данных в БД INT, и доступ к полю происходит через getInt(), то драйвер использовал один алгоритм преобразования к числу. Если же тип данных -- NUMBER, то применялся какой-то ужасный алгоритм строковых преобразований с генерацией просто мегатонн короткоживущего мусора, что в конечном итоге приводило опять же к тому же int на выходе.
Мораль: JDBC драйверы обычно очень и очень кривые. И это подтверждает мой опыт с тремя СУБД. Нет-нет, да и выскочит какой-нть глюк. Этим грешать все производители СУБД. Видимо именно поэтому существуют и платные JDBC драйверы для разных СУБД, а также драйверы, входящие в Weblogic, к примеру.
Теперь по сути вопроса.
1) 0.2-0.3 км -- это о4 близко, => влияние latency отметаем.
2) Возможно boombastik прав, и DB2 и/или OS-390 просто долго выдает данные. Как проверить? (1) Выполнить этот самый "медленный" запрос с командной строки на OS-390. (2) Выполнить его же на каком-нть другом боксе, напрмер, там, где крутится томкат. Если мне не изменяет память, то для DB2 на unix это делается примерно так:
db2 "select..."
3) Уже третий раз просим, ну пожааалуйста, проверь, как getTimestamp() работает.
4) Раз сужение снижает время, то, скорее всего, проблема в подготовке данных СУБД/передаче их по сети. Возможно, если увеличить буфер приема на стороне клиента, то это сможет помочь. НО!!! Вожможно, это просто отсрочит проблему, так как она не будет проявляться, пока объем возвращаемых данных не превысит объема буфера.
5) Интересно, может ли uncommitted read влиять на время, которое требуется СУБД, чтобы по строчкам открытого на стороне сервера баз данных курсора бегать?
6) Можно ещещодим способом проверить, скока же времени программа в драйвере проводит. Там же можно увидеть, скока времени ожидался ввод/вывод. Если ожиданий практически нету, то это означает, что данные сервером отдаются сразу. Профилировщик -- хорошая штука. Второй раз рекомендую, попробуй. Он встроен в JVM.
|
|
|
|
|
Supreme Being
модератор
Last Login: 10.11.2008 0:08
Сообщ.: 1 298,
Visits: 12 501
|
|
Эээ, Danissimo, ты все мои сообщения читал? :) Как ты думаешь, для чего я просил выполнить запросы: SELECT date_field и SELECT CHAR(date_field)? Именно для того, чтобы избавить JDBC драйвер от нагрузки преобразования Date -> String и заставить DB2 выполнять эту операцию.
Согласен, проблемы могут быть все еще в JDBC, единственное что могу предложить, чтобы по быстрому проверить насколько сильно влияет JDBC драйвер на производительность в данном случае - это попробовать различные альтернативные JDBC драйвера для DB2 и померять производительность.
Кстати, возможно имеет смысл написать маленькое консольное приложение и тестировать производительность драйвера и запросов через него, а то неизвестно какими дополнительными Wrapper'ами обвешано соединение к БД вызываемое из JSP-страницы.
С уважением,
Владимир
|
|
|
|
|
Supreme Being
участник
Last Login: 23.05.2007 20:20
Сообщ.: 662,
Visits: 5 795
|
|
| О, Neznajka111! Вот еще один раз попросили написать консольное приложение и псмотреть, че к чему. Давай, показывай результаты =))
|
|
|
|