Главная > AJAX, ExtJS Framework, Open Source, веб-обзоры > Новости с мира ExtJS: теперь и в облаках… в CDN то есть.

Новости с мира ExtJS: теперь и в облаках… в CDN то есть.

27 ноября 2008

Приветствуем наших читателей. Давно я как то не трогал тему фреймворка ExtJS, хотя каждый день с ним постоянно работаю. Даже мой сотрудник уже написал основу для статьи, никак руки не дойдут к ней. Но вчера посмотрев непрочитанные записи в официальном блоге компании-разработчика ExtJS, я понял, что молчать дальше нельзя, и надо бы рассказать, что нового и интересного.

Начнем мы с первой новости. Если вы разрабатываете проекты на ExtJS, то наверняка в вашем дереве исходных кодов есть сам дистрибутив библиотеки и вы его подключаете на всех страницах, где используются ее возможности. И храните саму библиотеку также у себя на хостинге. Это, конечно, правильный и простой подход, но имеет свои ограничения.

Во-первых, в большинстве случаев именно ExtJS будет самым большим компонентом страницы, ведь его общий объем около 1 Мб, а значит и будет тормозить страницу, пока браузер не загрузит всю библиотеку. Как выход, все рекомендуют настраивать сжатие (например, mod_deflate, хорошо, что браузеров, которые не понимают сжатый контент, теперь почти нет, а у кого есть, тот, как говорится, сам себе злобный буратино), теги кеширования и т.п. Ну и на крайний случай - собирать под свой проект, или даже под каждую страницу, свою версию библиотеки, включая туда необходимые компоненты. Мы уже писали о структуре фреймворка и расположенном на сайте конструкторе, который сможет автоматически сформировать вам ваш личный дистрибутив.

Однако теперь есть еще одна возможность хранить эти подключаемые файлы. Существуют такие системы как CDN - Content Delivery Networks, которые имеют собственную сеть географически разнесённых серверов, которые подключены к мощным скоростным каналам и находятся поблизости от пользователя, запрашивающего тот или иной файл. Если он хранится в CDN, то отдача файла будет происходить с сервера, который ближе всего к пользователю, а значит - файл загрузится быстрее.

В партнерстве с компанией CacheFly, ExtJS теперь может хранить свои сборки в такой сети. Кроме самих JS файлов хранятся так же и стилевые файлы (ext-all.css, который также достаточно объемный). Более того, теперь создавая собственную сборку фреймворка через веб-интерфейс, вы можете сразу поместить ее в CDN и использовать напрямую, просто поменяв ссылки. Учтите, что если ваш вариант сборки фреймворка уже кем-то используется, то новый файл не будет создаваться, а вам просто выдадут ссылку на уже закешированный.

Конечно, для многих проектов ускорение, достигнутое таким способом, может быть несущественным, ну выиграли мы пол-одну секунду... но поверьте, в борьбе за оптимизацию предела нет, а все, что помогает выиграть хоть самое малое время в работе приложения, будет оценено клиентами.

Я решил не только написать, но и проверить, действительно ли загрузка с серверов CacheFly будет идти быстрее, чем при подключении файла напрямую с сервера проекта.

Честно говоря, грузится не медленнее уж точно. В частности из-за того даже, что загрузка идет с другого хоста, а значит параллельно браузер запрашивает другие файлы, а это важно, так как одновременное количество запросов к одному домену ограничено. Проверяя доступность сайта по пингу, в среднем значения были на уровне или ниже данных для моего сервера, хотя когда я проверял в прошлый раз, различие было значительнее, раза в полтора, на пользу  CacheFly. Так что советовать что-то сложно - это надо лично пробовать, однако хуже не будет, это уж точно.

А про вторую новость, на счет более тесной интеграции с платформой Adobe AIR, а также про нововведения в 1.5 самого AIR - об этом поговорим завтра.

  1. 27 ноября 2008 в 19:23 | #1

    google недавно добавил в свой CDN http://code.google.com/apis/ajaxlibs/ две библиотеки YUI и swfObject. Возможно дойдет дело и до ExtJS, однако специфика этого фреймворка больше бекенды, и позицируется ExtJS в несколько другом свете.

  2. 13 декабря 2008 в 22:01 | #2

    Вообще разнесение компонентов страницы описынным методом — «палка двух концах».
    Кроме описанных выше плюсов имеем такие минусы:
    1. Дополнительный DNS-resolve запрос занимает время
    2. Дополнительный socket запрос — долгая операция. (в то же время для запросов к одному серверу используется единожды открытый сокет + keep alive + оптимизация TCP стека)
    3. Появляется ещё одна точка отказа: что увидит пользователь вашего ExtJS приложения если вдруг CacheFly сервер вдруг немного «затупит»?

    Конечно же первых 2 проблемы по сравнению с третьей — детский лепет, но все три — весьма актуальны.
    К тому же в условиях UA-IX — вероятность третьей проблемы повышается раз так в 10.

    P.S. Все утверждения основаны на личном опыте при работе с Google Ajax Libs.

    • 13 декабря 2008 в 22:26 | #3

      Конечно, никакое решение не идеально. Но.
      1. Этот пункт имеет место только при первом посещении, ведь почти все фаерволы на клиентах кешируют, да и дальше роутеры и прокси делают то же.
      2. Так учитывайте, что дополнительный запрос также один, а запрашивается то несколько файлов, а если учесть графику, подключаемую в css, так и того больше.

      В то же время, оптимизация на стороне CDN все же, во многих случаях, лучше, чем можно себе позволить. как минимум, я в одном из проектов получит аналогичные показатели, в ряде случаев даже лучше. Например, сжатие контента я так и не настроил (ну да, наверное, руки кривые, но на обычном виртуальном хостинге это вообще может не получится и т.п.).

      3. ну а если мой сервер затупит, то что? А мне кажется, что учитывая инфраструктуру, доступную для обычных хостингов и клиентов, вероятность тупления их оборудования все же несколько выше, чем у специальной CDN. А про UA-IX не понял? Как минимум, с нее вышли много провайдеров, или это касается хостинга — так, скажем, в свете недавнего скандала в Infostore я бы трижды подумал, чем ставить сервера у нас (а смотря на цены/параметры, еще несколько раз подумаю).

  3. 14 декабря 2008 в 11:29 | #4

    >> ну а если мой сервер затупит, то что?
    То вы получите 2 точки возможного отказа, вместо одной, как это было раньше. Следовательно и вероятности отказа всей системы — суммируются (думаю теорвер ещё помните).

    Про UA-IX было сказано потому, что скорость подключения у клиентов в его пределах очень высокая, а за его пределы — намного хуже. А ваша CDN находится скорее всего вне Украинских сетей. Итого получается что время ответа вашего приложения будет всегда MAX(T-вашего сервера, T-CDN).

    И разговор про провайдеров покинувших UA-IX, ваше мнение о проблеме вокруг infostore, и где бы вы ставили / не ставили сервера — отношения к теме не иммет.

    P.S. Сделайте шрифт крупнее — читать тяжело.

    • 14 декабря 2008 в 14:47 | #5

      Ну про отказ то оно так, но давайте не будем забывать про порядок величин. Вообще-то, мне кажется, вы забываете основное предназначение CDN — я в любом случае полагаю, что вероятность отказа или сбоя, который приводит к недоступности сервиса (заметьте, не единичного сервера) у такой компании намного ниже, чем у обычного хостинга обычного проекта, тем более, если он ориентирован на Украину и опирается на UA-IX. также рекомендую почитать SLA (http://cachefly.com/legal_sla.html), особенно в части про доступность. Сталкиваясь с такого рода сервисами зарубежными, я накопил некоторый положительный опыт, особенно в части доступности и возмещения простоев, если таковы были по вине хостера.

      Я вам снова говорю, достаточно большие провайдеры выходят с UA-IX, в частости, Укртелеком, а значит ориентироваться на нее, это не означает, что получить бОльшую скорость. Кроме этого, для получения такого выигрыша это должен быть такой проект, ориентированный на внутренний рынок, да еще и отдельный сегмент, где такое различие в скорости будет, как минимум, заметно, что, для веб-приложений, уровня, где требуется ExtJS, достаточно спорно (да, первая загрузка будет, конечно, дольше, но на фоне других затрат такого уровня приложений, она, поверьте, несущественна).

      Позвольте, я все же сам решу, что имеет отношение, тем более, что эти аргументы как раз имеют отношение. Или вы про сферического коня в вакууме/на площадке UA-IX говорите? Тогда да, не имеют, а если реально обсуждать — то еще как имеют. Впрочем, мне кажется, здесь не лучшее место для выясения вопроса рисков и предпочтений для установки серверов.

      P.S. Вид > Стиль страницы -> Только текст (галочка) + опция в этом же меню Увеличить.

  4. 14 декабря 2008 в 15:16 | #6

    >>Вообще-то, мне кажется, вы забываете основное предназначение CDN
    Мне кажется это Вы забываете — CDN отлично справляется с распределением медиа ресурсов (картинки/видео/музыка/файлы), но в случае хостинга JS — создает только дополнительную точку отказа и дополнительный «тормоз» для клиента.

    >> Ну про отказ то оно так, но давайте не будем забывать про порядок величин.
    >> у такой компании намного ниже, чем у обычного хостинга обычного проекта
    Вы вообще математику в университете учили? Пофиг какие бы величины там не были — вы к вероятности сбоя своего сервера добавляете ещё и вероятность сбоя(или в межпровайдеского «тормоза» на пути) CDN, которая отнюдь не нулевая.
    А ещё вы видуть забыли как AmazonS3 + EC2 падал?
    И толку после этого от их возмещения? Потерял я куда больше.

    >> большие провайдеры выходят с UA-IX, в частости, Укртелеком
    Укртелеком вышел из UA-IX около 5ти лет назад по политическим причинам и на качество их услуг для пользователя это не повлияло.

    >> мне кажется, здесь не лучшее место для выясения вопроса рисков и предпочтений для установки серверов
    Ну не я же начал. 🙂

    А вообще я вижу что весь ваш опыт — ближе к сферическому коню в вакууме — основан на чистой теории, которая по всем законам жанра в реальной ситуации качественно сбоит.

    Вообщем спорить дальше не буду, думаю приведенных аргументов будет достаточно читателю (а не автору) дабы перед использованием CDN снять розовые очки и включить мозг.

    P.S. Просто шикарный совет по увеличению читабельности.
    Как всегда продемонстрировали свой большой болт, который ложите на своих читателей

    • 14 декабря 2008 в 15:31 | #7

      Ну давайте, расскажите мне про предназначение CDN. И также, почему в случае других ресурсов это не точка отказа, а в случае JS-библиотеки — становится. Я внимательно послушаю, честно.

      И про вероятности тоже знаю. И знаю, что если было 1, а стало 1.001, то пусть по математике это и увеличение величины, но на практике все это комплексно рассматривается, и другие стороны вполне могут увеличить привлекательность решения, после которого, по снова таки математике, вероятность сбоя увеличивается.

      Я про сбои Амазона слышал, да. И что, вы хотите сказать, что у них надежность ниже, чем отечественных датацентров? Как-то не верится…
      Да, выход Укртелекома не повлиял, соответственно, это не повлияет и расположение некоторых файлов за пределами этой точки обмена, верно?

      Да я тоже, знаете ли, много чего вижу, Вы как то тоже своего опыта не показываете, с чего же мне заключать о нем что-то, я не беру на себя подобную смелость. Да, действительно, люди, снимите свои очки, CDN это фигня, Акамаи тоже фигня, свой сервер на воле или мирохосте (я никоем не хотел бы задеть эти компании, просто в качестве крупнейших отечественных хостеров, которых вспомнил) вот это надежно.

      P.S. Каков вопрос, такой, уж извините, ответ. Вы сообщили об единичной и личной сложности, я вам предложил вариант, который никого больше не затронет (а с чего бы должен был затрагивать?). Остальную часть вашего комментария я, уж извольте, не стану комментировать, как говорится, дабы не уподобляться… Мы с вами, как припомню, уже сталкивались на почве Ваших комментариев и предложений, и я, как помнится, изъяснил свою позицию по этому вопросу. Лично от себя, могу посоветовать — если Вас так много чего не устраивает, зачем читаете? И впредь попрошу Вас вести себя более корректно в частном публичном месте, которым является этот блог.

Комментирование отключено.