LINUX.ORG.RU

Вышел QTP 1.0


0

0

Вышла в свет стабильная версия QTP 1.0 enterprise edition
QTP является частью проекта QPLATFORM компании ainmarh.
Препроцессор шаблонов QTP enterprise предназначен для изготовления встраиваемых в код программы шаблонов. Он преобразует файлы определенного синтаксиса (.q) в исходные тексты (.c и .h), которые с помощью call-back процедур заполняются данными. QTP поддерживает механизмы сравнения (if), встраивания (include), внутренних структур (intern) и вызова внешних структур (extern). Также есть возможность (программно) заполнять шаблоны цыклическими данными (таблицы, списки). QTP реализует диалект QLang dialect version 2.0, который рассчитан на масштабируемость и быструю разработку/изменение структуры cgi-приложения.

>>> Домашняя страница QPLATFORM



Проверено: maxcom

> заполнять шаблоны цыклическими данными

цИклическими, двоечник!

anonymous
()

Недавно развернулась дискуссия по поводу цыгана на цыпочках, оказывается есть еще и цЫклические данные.

anonymous
()

Цитата с сайта:

======================================
заполнять шаблоны цыклическими данными
======================================

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

anonymous
()
Ответ на: комментарий от anonymous

Ага. Мы цИплята, цИгани и на цИпочках. :)
И конечно же, у нас есть шарашка. :)
И опечатки бывают, конечно, только у шарашек и у цИплят. :)

Кстати, новость про софтину, а не про русский язык!

Melon
() автор топика
Ответ на: комментарий от Melon

Еще есть АукцЫон!!! ЕЕЕЕЕЕЕЕЕЕЕЕЕ

anonymous
()
Ответ на: комментарий от Melon

да мало ли про что ты постишь! грамотность надо соблюдать!

anonymous
()
Ответ на: комментарий от anonymous

Во что превратили LOR.... подумать страшно. :(

Melon
() автор топика
Ответ на: комментарий от Melon

>Кстати, новость про софтину, а не про русский язык!

Извольте и про софтину.
А нафига козе баян?
В смысле, а что не устраивает авторов в туевой хуче шаблонов на perl/php/что-там-ещё.

(ехидно так) Или выигрыш в производительности настолько заметен по сравнению со скажем mod_perl или mod_php вкупе с каким-нить _ПРИСТОЙНЫМ_ темплейтнвым движком ?

avg
()
Ответ на: комментарий от avg

2avg
Немного не понятен вопрос. Когда я проводил тесты mod_perl, mod_php и Java, при этом Java использовал более чем пристойный движок шаблонов FreeMarker (www.freemarker.org) плюс работа с базой, получалась следующая последовательность:
1 место: Java
2 место: PHP
3 место: Perl

при этом Perl использовал самый простейших движок шаблонов.

Korwin ★★★
()
Ответ на: комментарий от Korwin

> Когда я проводил тесты mod_perl, mod_php и Java...

Что именно тестировалось? mod_perl, mod_perl 2, или всё-таки Apache::Registry/ModPerl::Registry???

> при этом Perl использовал самый простейших движок шаблонов

Какой именно?

P.S. Совсем уж голословные утверждения выдаёте.

anonymous
()
Ответ на: комментарий от Korwin

2 Korwin:
> Немного не понятен вопрос. Когда я проводил тесты mod_perl, mod_php и > Java, при этом Java использовал более чем пристойный движок шаблонов > FreeMarker (www.freemarker.org) плюс работа с базой, получалась следующая последовательность:
> 1 место: Java
> 2 место: PHP
> 3 место: Perl

Гы, конь на java в вакууме оказался сферичнее?
По какому критерию места распределялись?
Не говоря уж о том, что как-то глупо сравнивать язык программирования (Java) c _модулями_к_апачу_ ( mod_perl, mod_php ).

avg
()
Ответ на: комментарий от avg

2avg
Сферический конь - это не ко мне. Был Интернет магазин на Perl плюс аналогичный на PHP был заказ провести анализ кода и направление развития, т.к. существующий код не справлялся с обслуживанием большого кол-ва клиентов. В ходе анализа и тестирования было однозначно определено преимущество Java (Servlets, freemarker. J2EE не применялось).
В ходе опытной эксплуатации версия Java исп. в 2 раза больше памяти, но при этом в 2-7 раз быстрее работает. Сейчас версия Java обслуживает на тех интернет магазинах в 4 раза больше клиентов при меньших нагрузках как на сервер, так и на сервер БД.

В итоге все довольны - заказчик перестал постоянно наращивать железо, надежность повысилась за счет кластеризации и load balancing, клиенты - их стало больше, ну а я... В общем тут все ясно :)

ЗЫ
>Не говоря уж о том, что как-то глупо сравнивать язык программирования (Java) c _модулями_к_апачу_ ( mod_perl, mod_php ).
А что модули к апачу умудряются работать, собственно, без языка программирования? А я думал, что они реализуют интерфейс к нему 8[]

В общем начальству равно как и пользователем начихать на чем написанно главное скорость и надежность. И стоимость разработки и поддержки разумеется тоже волнует начальство.


ЗЫ-ЗЫ
пару узких мест в движке на Perl были написаны на C. Java код реализующих их функциональность + еще кучу другую выполнялся в 2.5 раза быстрее чем C код. Внимание вопрос: почему такое имело место быть при условии, что C код максимально оптизимизован и работал по CGI протоколу?

Korwin ★★★
()
Ответ на: комментарий от Korwin

По поводу производительности

Товарищи!
QTP по скорости выигрывает у всего, что только возможно! :)
Сами подумайте, в результате получается нативный код, который исполняется процессором, а не Java-машиной или чем-то там еще.
Схема прироста производительности в обработке шаблонов следующая:
(расставим по скорости)

Машина для тестирования: P3 800MHz/RAM 1024M/
Исходный шаблон: 2573 байт
Результирующие данные: 15Kb

1. QTP: 27500 заполненных шаблонов в секунду.
2. Парсеры на C (нативный код, средняя величина) 1200-2000
3. Java: (средняя величина для рассмотренных парсеров) 450-700 заполненных шаблонов
(берем в расчер Java на linux-платформе i386)
4. PHP: (средняя величина для рассмотренных парсеров) 450-650
5. Perl: (средняя величина для рассмотренных парсеров) 450-600
5. Прочее (Python, Tcl...): 300-450

Делайте выводы!
Отрыв от ближайшего соперника более чем в 10 раз. Не буду говорить
про Java,PHP,Perl и прочее...

Melon
() автор топика
Ответ на: комментарий от Korwin

Поставь максимально легкий apache + mod_accel как frontend, apache+mod_perl как backend и потом тестируй.

Как именно использовался mod_perl в магазине ? Подозреваю что это были cgi скрипты под Apache::Registry.

anonymous
()
Ответ на: комментарий от Korwin

А насчет узких мест - про cgi протокол давно пора забыть. Критически важные по скорости вещи пишутся как апачевские модули. Почитайте "Writing Apache Modules with Perl and C".Там встречается утверждение об отсутствии принципиальной разницы в скорости между модулями на c и perl.

anonymous
()
Ответ на: По поводу производительности от Melon

>Товарищи!
>QTP по скорости выигрывает у всего, что только возможно! :)
>Сами подумайте, в результате получается нативный код, который >исполняется процессором, а не Java-машиной или чем-то там еще.
>Схема прироста производительности в обработке шаблонов следующая:
>(расставим по скорости)

>Машина для тестирования: P3 800MHz/RAM 1024M/
>Исходный шаблон: 2573 байт
>Результирующие данные: 15Kb

>1. QTP: 27500 заполненных шаблонов в секунду.
>2. Парсеры на C (нативный код, средняя величина) 1200-2000
>3. Java: (средняя величина для рассмотренных парсеров) 450-700 >заполненных шаблонов
>(берем в расчер Java на linux-платформе i386)
>4. PHP: (средняя величина для рассмотренных парсеров) 450-650
>5. Perl: (средняя величина для рассмотренных парсеров) 450-600
>5. Прочее (Python, Tcl...): 300-450

>Делайте выводы!
>Отрыв от ближайшего соперника более чем в 10 раз. Не буду говорить
>про Java,PHP,Perl и прочее...

>Melon (*) (22.12.2003 13:44:22)

гы, бред какой-то
я про то, что нижняя цифра у java-perl-php совпадает, а верхняя отличается

А так - смешны все эти сравнения.
Узкое место обычно таки хождение за данными в базу. Если движок дольше рисует страницу, чем получает данные из базы - в печку его. Если страница строится из статических шаблонов, то и нефиг её строить на каждый запрос - один раз при изменени шаблона.

Мы ведь говорим про применение шаблонов на http сервере?
"27500 заполненных шаблонов в секунду" - это при скольки дитях-потоках на сервере? Сколько времени занимает обработка одного шаблона - без хождения в базу и с таковым?

avg
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.