Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

GWT – подглядываем в передаваемые данные

Anna | 5.06.2014 | нет комментариев

imageGWT – чудесный фреймворк. Я — Java-разработчик, и мне приходилось трудиться с тонкими заказчиками с применением JSP, JSF и GWT. Про JSP говорить особенно нечего, спецтехнология теперь фактически вымерла, а вот в JSF-е пришлось повариться пару лет на 2-х планах, и ощущения, мягко говоря, не из наилучших: мешанина JSTL, HTML, JavaScript и прочего доставляет несказанное “удовольствие”, доходящее до экстаза в моменты разбора непонятного поведения какой-нибудь трудной страницы. Да, в примерах все выглядит старательно и легко, но настоящая жизнь не такая, и JSF-страницы плана даже среднего размера и, как бы бы, с грамотным неспешным подходом при проектировании, с применением образцов, все равно начинает “попахивать”, исключительно в части читабельности. В GWT все довольно старательно, чай пишем на родном языке Java, пускай и в урезанном варианте, но того что есть больше чем довольно.

Если говорить о том, что в GWT на заказчика грузятся громадные файлы JavaScript-а, то здесь суждение мое такое. В GWT при первом входе на заказчика грузится логика, пускай и много, но лишь один раз. Позже загрузки между заказчиком и сервером ходят только чистые данные бизнес-логики. Реально у меня первая загрузка 3МБ, после этого AJAX-запросы/ответы, здесь уж зависит от того, что у вас за объемы данных. В JSF-е же, при входе на всякую страницу в браузер идут и данные и изложение интерфейса, в котором они отображаются. В большинстве случаев размер изложения интерфейса (html-а) во много раз огромнее размера самих данных. Дабы показать на заказчике 1КБ данных (несколько строчек таблицы, скажем), вам придется передать в браузер 15-30 кБ html-а (считаем, что изображения и скрипты закешированы). А чай данных на странице обыкновенно значительно огромнее: заголовки, меню, разные блоки и т.д. Реально, довольно интенсивная данными и функционалом страница обыкновенно весит не менее 100-200 кБ. GWT же для отображения такой же страницы заберет с сервера 1 кБ данных и всё. Если пользователи непрерывные и подолгу находятся на сайте, то потеря первичных 3МБ компенсируется за 30 мин. С учетом этого, GWT безупречно подходит для реализации рабочих мест, а вот для обыкновенных сайтов он может быть не так отличен.

В любом случае, это лишь введение для того, Дабы немножко “окунуться” в рассматриваемую тему, а статья не о сопоставлении спецтехнологий, а о том, как подглядывание за данными, которые ходят между браузером и сервером, может подмогнуть в решении задач и в оптимизации заказчик-серверного взаимодействия. На момент написания, у нас применялся теснее дюже крепко устаревший GWT 1.5, а для передачи DTO столь же ветхая и теснее не поддерживаемая библиотека Gilead. У меня в планах обновление до последней версии GWT и отказ от Gilead в пользу GWT-шного RequestFactory. Самостоятельно от спецтехнологий, инструментарий и способы отладки остаются теми же. Я применял FireFox с установленным плагином FireBug.

Как мы обнаружили утрату памяти

Некогда мы решили обновить используемые спецтехнологии – GWT, Gilead, JBoss, Hibernate. Заменили библиотеки, развернули сервер, перекомпилировали план. Запустили, оттестировали, и решили выходить на индустриальную эксплуатацию. Обновили сервер, ожидаем. Первые отзывы – работает стремительней. Через час все предисловие “подвисать”, через 15 минут “встало колом”, еще чуть позднее сервер упал по OutOfMemory. Начали судорожно пытаться разобраться в задаче, перезапускали сервер всякий час в это время. Вновь же, статья не вовсе об этом, кончилось тем, что утрату найти так и не удалось, и мы откатились на ветхую версию. Я длинно пытался исследовать дампы, делать нагрузочное тестирование, но так и не обнаружил источник задачи.

через месяц, тестировщик стал жалиться на то, что один из журналов в Системе длинно открывается (ему в свою очередь на это пожаловались пользователи). У меня эта задача не воспроизводилась, я попросил его установить FireFox и FireBug и посмотреть, что там происходит. Оказалось, что при открытии журнала на заказчика грузится пакет размером около 4-х мегабайт (!!!), для того, Дабы отобразить табличку из десятка записей. Источник задачи был сразу обнаружен – на сервере, при выборке данных для отображения, не было установлено лимитация на число записей, считываемых из БД, и на заказчика грузилось все содержимое таблицы БД. У меня в тестовой базе разработчика в таблице было полсотни записей, а у тестировщика был свежий дамп индустриальной базы с тысячами записей в этой таблице. Исправление задачи – добавление одной строчки кода.

Я думаю, что повод “падения” сервера при обновлении спецтехнологий была именно в этом журнале. Отчего ветхие спецтехнологии справлялись?

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB