Записи с тегом «programming»

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

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

Сегодня мы сделаем краткий обзор нескольких сайтов, которые работают на базе веб-фреймворка Django. Вот список, с краткими пояснениями.

• vepr.com.ua - Сайт украинского внедорожника "ВЕПР". По словам разработчиков работа еще не доделана, но мы видим уже вполне функциональный и информативный сайт. Начали обзор с него, т.к. сам по себе проект очень интересный. Любой автолюбитель не без интереса посмотрит фото и видео галерею.
• rupy.ru - Сайт конференции разработчиков, использующих языки программирования Python и Ruby. Первая конференция прошла 10 февраля в Омске. В работе конференции принимали участие сорок восемь человек, в том числе гости из Новосибирска, Абакана, Екатеринбурга. Надеемся что конференция будет развиваться и привлекать новых людей в число разработчиков на Ruby и Python.
• fact.kiev.ua - Сайт известного киевского издательства "Факт", работающего с 1997 года. На сайте есть как общая информация про издательство, так и регулярно обновляемый каталог выпускаемой продукции с хорошим поиском и сортировкой. Также есть регулярно обновляемый раздел со статьями.
• kvant.net.ua - интернет-магазин с легким и простым интерфейсом.
• unt-systems.com - Сайт компании, занимающейся разработкой и реализацией новых технологий. Сайт компании еще наполняется, но уже вполне можно можно понять род деятельности и общую информацию о компании.
• gardi.com.ua - Сайт цветочной группы "Гарди", занимающей лидирующие позиции по производству тепличных цветов и горшечной продукции в Украине. Каталог продукции компании еще в стадии заполнения.
• dina.com.ua - Сайт предприятия по производству трикотажных изделий. На сайте есть довольно полный каталог продукции.

Вот наш скромный обзор и закончился, позже мы еще сделаем обзор уже rails-сайтов, которые у нас хостятся. Могу сказать еще, что в ближайшее будущее появятся еще новые сайты, сделанные с помощью Django, т.к. некоторые разработчики используют наш хостинг как платформу для разработки и мы уже наперед знаем общую информацию о проектах.

Так что ждем Ваших приложений! Пишите смелее на Ruby и Python .  

Хостинг python приложений имеет некоторые нюансы, не всегда удобные и приятные для хостера. Мы уже больше года предоставляем python-хостинг и столкнулись с рядом особенностей. Да, не все в нашем мире идеально :-)

Вся суть в способах связки python-приложения с веб-сервером. С тех пор как php прочно вошел и закрепился в среде веб-разработчиков, его постоянно стали сравнивать с другими языками программирования, применимыми для написания веб-приложений. В том числе сравнивали и производительность. Естественно скорость работы php-парсера была высока по сравнению с perl-кодом, работающим через cgi. Да и вообще cgi стандарт себя уже изживал.

Поэтому серверные веб-технологии пошли двумя основными направлениями в плане сопряжения программной части с веб-сервером:

1. разработка всяких mod_* — встроенных интерпретаторов в веб-сервер;
2. переботка стандарта cgi с целью увеличения производительности (FastCGI);

Оба направления популярны и успешны по сей день, т.к. у каждого есть свои плюсы и минусы. Переходя на детали о Python, хочется сделать отдельную заметку общего плана.

В тредовой (thread) модели python есть такое понятие как Interpreter Lock. Это когда тред блокирует интерпретатор на определенное время (пока не выполнит операцию, выполнит определенное кол-во инструкций или не пройдет таймаут). В принципе этот метод разделения ресурсов вполне хорошо работает на практике. Но в случаем с хостингом есть свои нюансы...

Представте вполне реальную картину. Веб сервер (Apache) с встроенным mod_python обслуживает 50 python-приложений. Если апач работает в тредовом режиме, тогда и mod_python тоже (апач настраивается на тредовый режим через опции компиляции, а модуль уже при сборке сам определяет в каком режиме работает апач и собирается в этом же режиме). Теперь сама ситуация: 50 веб-сайтов смогут вполне создать нагрузку 1-5 запросов в секунду, а на каждый процесс апача у нас приходится, например, по 25 тредов и одному интерпретатору python. Теперь вспомним про Interpreter Lock и прикинем какие могут быть ситуации. В общем говоря в тредовом режиме mod_python работает достаточно нестабильно. Выглядеть это будет как таймауты (код будет долго ждать разблокировки интерпретатора).

При работе в fork() режиме веб-сервера, проблема блокировок снимается (т.к. на каждое соединения клиента выделяется отдельный процесс веб-сервера и следовательно отдельный интерпретатор), но возникает проблема с экономией оперативной памяти. Т.к. каждый процесс потребляет значительное кол-во памяти (от 20 до 50 Мб ориентировочно).

Теперь вспомним про второй способ сопряжения приложенияс веб-сервером и подумаем о связке не встроенным способом — т.е. через популярный FastCGI. Веб-сервер в этом случае разгружается и никак практически не зависит от стабильности приложения. Т.е. конечный пользователь в любом случае получит или запрашиваемый результат или страницу с ошибкой, что намного лучше таймаута без каких либо объяснений. В этом случае сам веб-сервер может работать в тредовом режиме и экономить память. Но есть другая проблема. Каждое отдельное python-приложение будет запущено отдельным процессом и будет также потреблять память, что в итоге может дать не экономию, а большие затраты.

Интересно что приложение запущенное в режиме FastCGI может также работать в тредовом и fork() режимах, что соответственно влияет на потребление ресурсов. В тредовом режиме проблемы остаются те-же что и с mod_python. Только кол-во запросов к отдельному FastCGI-процессу в принципе сокращается, что дает меньшую вероятность таймаута в связи с блокировкой интерпретатора.

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

Желаем успехов в разработке!

Наш Хостинговый Блог работает теперь под управлением Django. Переход с wordpress был практически безболезненный, не считая конвертирования many-to-many sql-таблиц. Но это дело 20 минут. Самое трудное было написать саму логику и темплейты. Теперь наш блог выглядит как и весь сайт, в одном стиле. URL-ы все остались целыми, а некоторые редиректятся на новые.
Это далеко не последняя версия блога. Мы продолжаем работать над сайтом дальше!

В новостях на opennet.ru попалась ссылка на интересную статью про кеширование в php. Очень толковые мысли и примеры. Скажу ещё раз что проблема производительности веб-приложения напрямую связано с кешированием, при чём не только на стороне сервера, но и на стороне клиента. Conditional get никто не отменял, он для чего-то был создан в HTTP/1.1. Что проще отдать? строку заголовка 'Not modified' или сгенерить и отдать страницу текста. Даже если страница уже готова к отправке, как минимум экономится траффик и уменьшается загрузка канала. Поэтому я не понима почему Ruby On Rails даже картинки отдаёт через скрипт и при этом не даёт нормальных заголовков для кеширования. Хотя надо ещё уточнять... В общем интересное чтиво с примерами для php-программеров. Давайте писать по стандартам не только всякие там XHTML/CSS/etc... но и заголовки.