LINUX.ORG.RU

Вышел QTP 1.3.5


0

0

Выпущен bugfix-релиз QTP 1.3.5, который нормально функционирует на x86_64 платформах.

Препроцессор шаблонов QTP enterprise предназначен для изготовления встраиваемых в код программы шаблонов. Он преобразует файлы определенного синтаксиса (.q) в исходные тексты (.c и .h), которые с помощью call-back процедур заполняются данными.

>>> Cайт разработчика

anonymous

Проверено: Shaman007 ()

для KA6AH: Для чего сие нужно? А для того, чтобы иметь вменяемый, пригодный к исправлениям HTML шаблон. + иметь нормальное кэширование (зачем каждый раз дергать базу?) + иметь сессии из этой же оперы + иметь гарбаж коллектор для сессий и кэша который устарел - парсинг шаблона (пусть даже прекомпилированного) при каждом отображении страницы.

Получаем (по тестам) PHP vs QTP (рассматривается один и тот же проект, сделанный в друх исполнениях на одном и том же железе): разработка PHP:7 дней, QTP+C: 13 дней (явный минус) нагрузка: PHP:63 запроса в секунду, QTP+C: 850 запросов в секунду. база (на 100 запросов к web): PHP:110 запросов к базе, QTP+C: 18 запросов к базе.

Делаем выводы: Разработка занимает времени больше нежели на PHP примерно в 2 раза, скорость работы быстрее в 10 раз минимум. То есть, если проект посещаемый очень, то стоит поднапрячся. Если нет - нафиг. Для сайтов типа "домашний фотоальбом" применять QTP не стоит.

twin.

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

> Получаем (по тестам) PHP vs QTP (рассматривается один и тот же проект, сделанный в друх исполнениях на одном и том же железе): разработка PHP:7 дней, QTP+C: 13 дней (явный минус) нагрузка: PHP:63 запроса в секунду, QTP+C: 850 запросов в секунду. база (на 100 запросов к web): PHP:110 запросов к базе, QTP+C: 18 запросов к базе.

Это говорит только о том, что программа написанная на пыхпых сделана без поддержки кэшировния, скорее всего не использовался никакой фрэймворк. А в QTP+C кэширование встроевно вот и всё. Если использовать нормальный фрэйморк... ну для пэхэпышники сами скажут.. а я скажу RoR, где кэширование поддерживается на должном уровне, то ускорение от того что это написано на С не будет заметно. А уж если на ПХП написано за 7 дней, занчит на РоР можно было за 3 написать, соовтеветвенно в 4 раза быстрее QTP+C примерно аналогично по скорости:)) осюда вывод, писать на С под веб -- большой изврат.

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

>PHP:63 запроса в секунду

Кхм. Вообще-то, любой нормально написанный фреймворк лимитирует скорость обращения к БД. А что из Си, что из PHP, что из, например, Java она будет одинаковой.

Если же "тормозит" - что в консерватории править нужно.

"Машина должна работать. Человек - думать" (c) IBM

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

KRoN73 - не приписывайте им благости которых у них нет: >"Машина должна работать. Человек - думать" (c) IBM девизом у них всегда было, есть и будет: "Машина должна приносить деньги! Человек - приносить деньги! Все должно приносить деньги!"(С) Idiots Become Manager (IBM).

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

> "Машина должна приносить деньги! Человек - приносить деньги! Все должно приносить деньги!"

Надо заметить что это девиз любой коммерческой организации.

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

Правильно. Но некоторые ведутся на пиар, что типа есть компании отличные от других. Тот же IBM - в молодости ваш бох Столлман называл их фашистами и воевал с ними яко сейчас с M$ ... :)

anonymous
()

как вышел так и вошёл видимо..Смысл был публиковать новость о брошенном проекте ??

"Из-за отсутствия времени разработка QPLATFORM практически заморожена. Выпущен bugfix-релиз 1.3.5, который нормально функционирует на x86_64 платформах. Дальнейшее развитие QPLATFORM будет продолжено в ближайшее время."

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

Если RoR такой великолепный, где более-менее приличная, а главное легко расширяемая (т.е. должна быть вменяемая дока по API, примеры модулей расширения и т.д. в общем все как в drupal) CMS построенная на RoR? С удовольствием бы взглянул.

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

Да забудь. ROR - тормоз. Если ты на пришедшие запросы вручную будешь ответы набивать с консоли - раз в 15 быстрее рора будет :)

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

> Если RoR такой великолепный, где более-менее приличная, а главное легко расширяемая (т.е. должна быть вменяемая дока по API, примеры модулей расширения и т.д. в общем все как в drupal) CMS построенная на RoR? С удовольствием бы взглянул.

1. Многие разарботчика RoR сознательно избегают использования CMS, но используют раличные плугины, генераторы и эндженты. Тем самым достигая произвольной гибкости в отличие от CMS.

2. Сам я не одну не смотрел ибо см пункт 1. но вот страница с информацией по теме: http://wiki.rubyonrails.com/rails/pages/Ruby+on+Rails+based+CMS

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

> Да забудь. ROR - тормоз. Если ты на пришедшие запросы вручную будешь ответы набивать с консоли - раз в 15 быстрее рора будет :)

Ты навреное продакшн сервер запустил в development mode через вебрик, а потом начальнику показал, вот теперь так и думешь:)

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