Категорія: Performance

 

Огляд швидкодії ColdFusion 9 від Adobe

Adobe опублікувала звіт про ColdFusion 9, в якому розкрила переваги в швидкодії перед версіями 7 (визначено загальний приріст у 500%) та 8 (40%).

Найбільш помітні покращення відносно CF8 включають:

  • Ініціалізація та виклик методів CFC, відповідно 700% та 200%.
  • Flash Remoting - покращення на 800%.
  • Гігантський приріст у роботі CreateUUID, що складає 10000%.
  • На 100% покращено швидкодію конектора для IIS.
  • На 35% покращено швидкодію функцій для роботи з датами.

Про все це докладніше, та ще й з гарними графіками можна дізнатися з документу ColdFusion 9 Performance Brief (pdf).

Автор: Сергій Галашин | Опубліковано: 16.03.2010 о 16:11 | Категорії: Adobe - ColdFusion 8 - ColdFusion 9 - Performance - Using CF -

 

Новий розширюваний кеш у Transfer ORM 2.1

Наближається час випуску нової версії Transfer, і потроху з'являються відомості про головні покращення в ній.

Зокрема, Марк Мендел розповів про нову систему кешування, що прийде на зміну доволі простій нинішній версії. Причинами зміни називаються низька гнучкість поточної реалізації та рідкісні випадки витоків пам'яті, що змусило задуматися над використанням перевірених рішень.

Головною особливістю її буде розширюваність: можливість інтеграції з іншими існуючими рішеннями. Це доволі логічний крок, після аналогічних нововведень в основних серверах застосунків: ACF та Railo.

За умовчанням будуть підтримуватися EHCache та ColdBox Cache. Надалі планується підтримка й інших систем кешування.

Марк зауважив, що напевне будуть потрібні деякі зміни в конфігурації сайтів, що вже використовують кешування з Transfer. Зокрема, він навів декілька прикладів конфігурування.

<objectCache>
    <defaultcache provider="transfer.com.cache.provider.EHCacheProvider">
       <setting name="config" value="/test/resources/ehcache.xml"/>
    </defaultcache>
    <cache class="none.Basic" provider="transfer.com.cache.provider.NoCacheProvider"/>
    <cache class="none.Child" provider="transfer.com.cache.provider.NoCacheProvider"/>
</objectCache>

З прикладу очевидно, що використовується EHCache провайдер з окремим файлом конфігурації та виключаються з кешу два визначення (definitions): none.Basic та none.Child.

В свою чергу наводиться приклад ehCache.xml:

<?xml version="1.0" encoding="UTF-8"?>
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd">

    <defaultCache
        maxElementsInMemory="1000"
        eternal="false"
        timeToIdleSeconds="120"
        timeToLiveSeconds="600"
        overflowToDisk="false"
        />
   
    <cache name="AutoGenerate"
            eternal="false"
            maxElementsInMemory="10" overflowToDisk="false">
    </cache>
   
</ehcache>

Тут визначається налаштування кешу за умовчанням, де максимальна кількість елементів в пам'яті 1000 та час знаходження елементів в пам'яті 120 секунд для бездіяльних елементів і 600 секунд для активних.

Також визначаються окремі налаштування для класу AutoGenerate, що обмежує кількість елементів до 10.

По інші можливості налаштування EHCache можна дізнатися в документації.

 

Для тих, хто зацікавлений в написанні власних провайдерів, потрібно буде працювати з наслідуванням AbstractBaseProvider.cfc та відповідною реалізацією віртуальних та абстрактних методів звідти.

 

Також треба зауважити про інше важливе нововведення: появу методу shutdown(). Він використовується для коректного завершення роботи запиту, що дозволяє системі кешування провести очистку сміття, позачиняти тимчасові файлі та провести інші процедури, необхідні для стабільної та ефективної роботи.

Марк рекомендує виконувати цей метод в момент спрацьовування onApplicationEnd:

<cffunction name="onApplicationEnd" returnType="void">
   <cfargument name="applicationScope" required=true/>
<cfscript>
    arguments.applicationScope.transferFactory.shutdown();
</cfscript>
</cffunction>

Особливо важливим є цей метод при використанні EHCache, бо без нього системний потік і надалі буде виконуватися, не даючи провести очистку сміття.

 

Насамкінець, для контролю за кешуванням рекомендується використовувати компоненту Cache Monitor та її методи getDefaultCache() та getCache(className).

 

Вже зараз можна витягти код нової гілки з описаними оновленнями з репозиторію проекту:

http://svn.riaforge.org/transfer/transfer/branches/pluggable_cache/

 

Як завжди, обговорити нововведення можна в групі transfer-dev.

 

Оригінальна публікація:  Sneak Peak: Transfer's new Plug-able Cache

 

Автор: Сергій Галашин | Опубліковано: 01.12.2009 о 21:12 | Категорії: ORM - Performance - Transfer -

 

Що обрати для Client Storage: Registry чи Datasource

Марк Кругер докладно розповів про те, чому потрібно запобігати використанню реєстру для зберігання клієнтських змінних (client variables).

Він навів приклад, коли за кілька місяців (за умовчанням 90 днів) Adobe ColdFusion починає періодично очищувати реєстр (знову-таки, за умовчанням кожні 67 хвилин), що призводить до несподіваних "залипань" сервера.

Цікаво, що ця проблема стосується й Linux, де реєстр просто емулюється в текстовому файлі (/coldfusion8/registry/cf.registry).

Він слушно зауважив про те, що напевно запобігти використанню цих змінних дуже складно, навіть якщо розробник запевняє, що не користується ними.

Тож він пропонує використати окрему базу (MySQL чи SQL Server цілком підійдуть) та відповідне джерело даних (datasource) для зберігання клієнтських змінних -- з прикладами, та наводить кілька порад щодо ефективного використання цьго методу.

Насамкінець він розповідає про кілька проблем, що можуть спіткати на шляху впровадження цієї оптимізації, особливо коли це стосується налаштувань вже робочого серверу.

Про все це докладно та з прикладами читайте в дописі Марка.

 

 

Автор: Сергій Галашин | Опубліковано: 28.10.2009 о 11:11 | Категорії: ColdFusion 8 - ColdFusion 9 - Blogs - Gotchas - Performance -

 

Щодо швидкодії створення об'єктів

Минулого місяця тривала (й триває досі) хвиля дискусій, що були породжені появою ORM в CF9. Якщо бути точним, реалізацією ORM за допомогою CFC-об'єктів.

Багато хто з розробників піддав сумніву доцільність цього кроку, небезпідставно стверджуючи про те, що створення об'єктів в CF є витратним та повільним процесом, бо потребує ряду операцій та витрат, наприклад сама компонента та кожен метод є окремим Java об'єктом, створення областей видимості та ін. Докладніше про це питання можна прочитати ув одного з інженерів Adobe в замітці ColdFusion ORM and CFC Performance.

Нас же зараз цікавлять приклади та порівняння. Цією справою не полінувалися зайнятися кілька ентузіастів:

І показали вельми цікаві результати, зокрема здивувала значна перевага Railo. Зрозуміло, що це лише один з аспектів швидкодії, котрий сам по собі не може бути базою для висновків.

Зауважу також, що обговорення питання проходить в гілці Object creation performance in CF 9: any better?

Автор: Сергій Галашин | Опубліковано: 02.08.2009 о 13:43 | Категорії: ColdFusion 8 - ColdFusion 9 - Discussions - Links - Open BlueDragon - ORM - Performance - Railo -