четверг, 30 октября 2008 г.
Генератор тестовых сценариев
Свершилось! Я прикрутил графический пользовательский интерфейс к генератору тестовых сценариев. Прошу наслаждаться: http://www.dmugtasimov.ru/testgenerator/testgenerator.html.
вторник, 7 октября 2008 г.
Как я Java на сайт устанавливал
Сегодня на меня снизошло озарение! Дело в том, что у меня есть сайт www.dmugtasimov.ru, на котором я разместил свою статью о тестировании сложных логических условий. Кроме статьи на сайте выложен исходный код на Java и собранный jar консольного приложения для генерации тестовых сценариев по сложным условиям в соответствии с алгоритмом изложенном в статье. Длится это уже около года. Реально генератором никто не пользуется, по крайней мере я не знаю таких. Причина видимо в том, что интерфейс приложения мягко говоря не очень удобный. Поэтому я решил прикрутить Web-интерфейс, через который можно будет генерировать тестовые сценарии, а потом их копировать в любые приложения через буфер обмена. А дальше мои приключения.
Web-хостинг, на котором живет www.dmugtasimov.ru я покупаю у компании Караван. Они предоставляют стандартный пакет средств Web-разработки CGI, php, perl, mod_perl, python, но среди них нет поддержки Java. Мой генератор написан на Java, причем сам использует генератор парсеров JavaCC, который специфичен для языка, кроме того код я писал около года назад. В общем мне нужен быстрый эффект, поэтому переписывание готового кода с Java на один из поддерживаемых провайдеров языков был для меня последним вариантом.
Наиболее простым вариантом мне показалась компиляция байт-кода Java в исполняемый код и выполнять его под CGI. Здесь стоит оговориться, что под CGI я никогда не программировал (хотя технология простая и довольно древняя), у провайдера установлен FreeBSD, с которым я никогда не работал и тем более никогда не компилировал собственные исполнимые бинарники. Пришлось учиться...
Во-первых, я установил под VMware FreeBSD 6.2, такую как у провайдера. Пытался устанавливать и обновлять приложения, но со временем обнаружил, что версия 6.2 больше не поддерживается и соответственно новые приложения установить не просто. Пришлось сначала обновить версию до 6.3. Потом я долго разбирался с менеджерами пакетов FreeBSD (точнее читал мануалы). В итоге оказалось, что с FreeBSD 6.3 поставляется gcc 3.x.x, в который не включен компилятор gcj. Последний по заявлениям разработчиков умеет компилировать исходный код и байт код Java в исполняемых код посредством gcc. Обновлять gcc под FreeBSD до 4.x.x я не решился, т.к. не понятно что из этого получится и как это сделать, т.к. для FreeBSD 6.3 версия gcc 3.x.x считается актуальной.
На соседней VMware жила Ubuntu 6.x, поэтому я решил собрать под ней исполнимый бинарник, который потом запущу под FreeBSD 6.x. Получилось, gcc и gcj оказались нужных версий, правда последний пришлось устанавливать, но это не страшно...
Создать исполнимый файл из jar-ника удалось, он даже запустился и отработал. Однако оказалось, что логика работы генератора тестов нарушилась. Выяснять почему gcj не смог корректно преобразовать jar в исполнимый файл я не стал и временно отложил эту задачу.
И вот в один прекрасный момент на меня снизошло озарение: нужно написать Java Applet, которой вызывать из JavaScript и выполнять это все в браузере на стороне клиента. Реализацией этой идеи теперь занимаюсь.
Web-хостинг, на котором живет www.dmugtasimov.ru я покупаю у компании Караван. Они предоставляют стандартный пакет средств Web-разработки CGI, php, perl, mod_perl, python, но среди них нет поддержки Java. Мой генератор написан на Java, причем сам использует генератор парсеров JavaCC, который специфичен для языка, кроме того код я писал около года назад. В общем мне нужен быстрый эффект, поэтому переписывание готового кода с Java на один из поддерживаемых провайдеров языков был для меня последним вариантом.
Наиболее простым вариантом мне показалась компиляция байт-кода Java в исполняемый код и выполнять его под CGI. Здесь стоит оговориться, что под CGI я никогда не программировал (хотя технология простая и довольно древняя), у провайдера установлен FreeBSD, с которым я никогда не работал и тем более никогда не компилировал собственные исполнимые бинарники. Пришлось учиться...
Во-первых, я установил под VMware FreeBSD 6.2, такую как у провайдера. Пытался устанавливать и обновлять приложения, но со временем обнаружил, что версия 6.2 больше не поддерживается и соответственно новые приложения установить не просто. Пришлось сначала обновить версию до 6.3. Потом я долго разбирался с менеджерами пакетов FreeBSD (точнее читал мануалы). В итоге оказалось, что с FreeBSD 6.3 поставляется gcc 3.x.x, в который не включен компилятор gcj. Последний по заявлениям разработчиков умеет компилировать исходный код и байт код Java в исполняемых код посредством gcc. Обновлять gcc под FreeBSD до 4.x.x я не решился, т.к. не понятно что из этого получится и как это сделать, т.к. для FreeBSD 6.3 версия gcc 3.x.x считается актуальной.
На соседней VMware жила Ubuntu 6.x, поэтому я решил собрать под ней исполнимый бинарник, который потом запущу под FreeBSD 6.x. Получилось, gcc и gcj оказались нужных версий, правда последний пришлось устанавливать, но это не страшно...
Создать исполнимый файл из jar-ника удалось, он даже запустился и отработал. Однако оказалось, что логика работы генератора тестов нарушилась. Выяснять почему gcj не смог корректно преобразовать jar в исполнимый файл я не стал и временно отложил эту задачу.
И вот в один прекрасный момент на меня снизошло озарение: нужно написать Java Applet, которой вызывать из JavaScript и выполнять это все в браузере на стороне клиента. Реализацией этой идеи теперь занимаюсь.
воскресенье, 21 сентября 2008 г.
Request Metrics тоже интересная штука. Я узнал, что существует некий стандарт Application Response Measurement (ARM) для профилирования приложений. В административной консоли можно указывать ARM-агентов. Это было бы замечательной возможностью выполнить задачу. К сожалению, в интернете я не смог найти бесплатных ARM-агентов, поэтому вариант с Request Metrics тоже пришлось временно отложить.
Мои дальнейшие попытки выявить узкое место были связаны с получением trace с Oracle, который используется WebSphere и прикручиванием JProfiler к JVM WebSphere Process Server.
Мои дальнейшие попытки выявить узкое место были связаны с получением trace с Oracle, который используется WebSphere и прикручиванием JProfiler к JVM WebSphere Process Server.
Попытки профилировать WebSphere продолжаются...
Странно, но почему-то хорошие идеи приходят в критических ситуациях быстрее, чем в других. Дело в том, что когда я понял, что с HProf у меня ничего не получается, то только тогда ко мне пришла идея обратиться к своим знакомым за советом. Они все равно не помогли в полной мере, но удивительно то, что я сразу к ним не обратился. Это могло бы съэкономить уйму времени на хождение по неправильным путям.
Вот, что было дальше. У WebSphere имеются встроенные средства "профилирования", помимо HProf, который встроен в JVM. Эти средства можно найти в административной консоли в разделе Monitoring and Tuning: Performance Management Infrastracture (PMI) и Request Metrics. Первое - это какой-то кусок от продукта Tivoli, а второе тоже что-то в ту сторону.
PMI я включил на уровне ALL и как оказалось он умеет профилировать EJB методы, т.е. собирает аггрегированную статистику (среднее и общее время проведенное в методе и количество вызовов для каждого EJB). Только есть одна проблема: не понятно как расшифрововать эту статистику. Дело в том, что профилируется WebSphere Process Server, а это такая бандура: под JVM запущен WebSphere Application Server, под ним WebSphere Process Server, который уже заворачивает нашу прикладную логику в свои системные EJB. Таким образом, наших java-методов, которые мы писали своими собственными руками не видно. Кроме того, PMI не строит дерево вызовов, что еще больше усложняет задачу анализа. В лучшем случае метрики PMI сможет прочитать разработчик, который помнит взаимосвязи вызовов.
Разборки с PMI я отложил до лучших времен.
Странно, но почему-то хорошие идеи приходят в критических ситуациях быстрее, чем в других. Дело в том, что когда я понял, что с HProf у меня ничего не получается, то только тогда ко мне пришла идея обратиться к своим знакомым за советом. Они все равно не помогли в полной мере, но удивительно то, что я сразу к ним не обратился. Это могло бы съэкономить уйму времени на хождение по неправильным путям.
Вот, что было дальше. У WebSphere имеются встроенные средства "профилирования", помимо HProf, который встроен в JVM. Эти средства можно найти в административной консоли в разделе Monitoring and Tuning: Performance Management Infrastracture (PMI) и Request Metrics. Первое - это какой-то кусок от продукта Tivoli, а второе тоже что-то в ту сторону.
PMI я включил на уровне ALL и как оказалось он умеет профилировать EJB методы, т.е. собирает аггрегированную статистику (среднее и общее время проведенное в методе и количество вызовов для каждого EJB). Только есть одна проблема: не понятно как расшифрововать эту статистику. Дело в том, что профилируется WebSphere Process Server, а это такая бандура: под JVM запущен WebSphere Application Server, под ним WebSphere Process Server, который уже заворачивает нашу прикладную логику в свои системные EJB. Таким образом, наших java-методов, которые мы писали своими собственными руками не видно. Кроме того, PMI не строит дерево вызовов, что еще больше усложняет задачу анализа. В лучшем случае метрики PMI сможет прочитать разработчик, который помнит взаимосвязи вызовов.
Разборки с PMI я отложил до лучших времен.
вторник, 16 сентября 2008 г.
Вчера я потратил целый день для того, чтобы выполнить профилирование WebSphere Process Server в кластерной конфигурации. Сразу скажу, что сделать это не получилось. История следующая.
WebSphere Process Server работает под IBM JVM 1.4.2 под AIX 5.3. JVM имеет встроенный профайлер HProf, который можно включить с помощью параметра -Xrunhprof. Меня интересовало время проведенное сервером в каждом методе, поэтому для профайлера были заданы следующие ключи -Xrunhprof:cpu=samples,file=/tmp/java.hprof,format=b,doe=n. "format=b" обеспечивает бинарный формат файла, что должно снизить дополнительную нагрузку на сервер, вызванную профилированием, "doe=n" обеспечивает запись в файл по мере поступления информации, а не после завершения виртуальной машины. Все эти параметры можно задать в консоли управления Deployment Manager'а.
Результат: сервер начинает стартовать, содержимое указанного файла пополняется, но в какой-то момент обновление логов прекращается и JVM будто замирает. Видимо профайлер становится слишком тяжелым для такого большого приложения как WebSphere Process Server.
Возможно спасение находится в использовании других профайлеров типа JProbe, OptimizeIt и т.д. Однако они в-первых платные, а во-вторых требуют установки на AIX. В идеальном случае хотелось бы найти такой профайлер, для установки которого достаточно прописать в classpath JVM путь к нужному jar-файлу. Вроде как JIP именно такой, однако заявляется, что для его использования нужен JVM 1.5.x, а это не мой случай...
WebSphere Process Server работает под IBM JVM 1.4.2 под AIX 5.3. JVM имеет встроенный профайлер HProf, который можно включить с помощью параметра -Xrunhprof. Меня интересовало время проведенное сервером в каждом методе, поэтому для профайлера были заданы следующие ключи -Xrunhprof:cpu=samples,file=/tmp/java.hprof,format=b,doe=n. "format=b" обеспечивает бинарный формат файла, что должно снизить дополнительную нагрузку на сервер, вызванную профилированием, "doe=n" обеспечивает запись в файл по мере поступления информации, а не после завершения виртуальной машины. Все эти параметры можно задать в консоли управления Deployment Manager'а.
Результат: сервер начинает стартовать, содержимое указанного файла пополняется, но в какой-то момент обновление логов прекращается и JVM будто замирает. Видимо профайлер становится слишком тяжелым для такого большого приложения как WebSphere Process Server.
Возможно спасение находится в использовании других профайлеров типа JProbe, OptimizeIt и т.д. Однако они в-первых платные, а во-вторых требуют установки на AIX. В идеальном случае хотелось бы найти такой профайлер, для установки которого достаточно прописать в classpath JVM путь к нужному jar-файлу. Вроде как JIP именно такой, однако заявляется, что для его использования нужен JVM 1.5.x, а это не мой случай...
Некоторое время я думал создавать мне персонализированный блог или анонимный. Первый вариант может способствовать повышению собственной популярности, если в нем писать умные вещи. Второй тоже может этому способствовать, но нужно в какой-то момент эффектно сказать: "Знаете вот тот парень, который писал, это я!".
Я решил сделать блог персонализированным. Теперь у меня проблема: мне нужно как-то определить какую информацию я могу разместить в блоге, а какую нет. Если учесть, что большую часть времени я провожу на работе и занимаюсь развитием нового направления бизнеса в компании, то любая информация, выложенная в блог, может стать полезной конкурентам.
Я решил сделать блог персонализированным. Теперь у меня проблема: мне нужно как-то определить какую информацию я могу разместить в блоге, а какую нет. Если учесть, что большую часть времени я провожу на работе и занимаюсь развитием нового направления бизнеса в компании, то любая информация, выложенная в блог, может стать полезной конкурентам.
Подписаться на:
Сообщения (Atom)