В этой статье мы поговорим о некоторых иногда упускаемых разработчиками аспектах, влияющих на общую производительность веб приложения. В частности рассмотрим как влияет на производительность множественные подключения внешних файлов, наличие «мертвого» кода, акселерация путем кешеров опкода и FastCGI для PHP.

Заметка посвящена не столько возможным методам защиты (о них уже было много написано), сколько обзору небольшого списка для быстрой проверки при подготовке к возможных скачкам посещаемости. Судя по статистике нагрузки на электронные магазины на прошлой неделе (когда начался рождественский сезон продаж на Западе), даже для крупных магазинов время ответа может колебаться на 20%, что же говорить о менее крупных веб-сайтах?

Такую проверку обязательно нужно проводить перед выпусками новых продуктов, а также перед сезоном массовых покупок (для России это время в канун Нового Года и Рождества). Итак, с чего начать?

Ни для кого не секрет, что в протоколе HTTP, а точнее в той его части, что является ответом с сервера, есть такие замечательные заголовки, как Last-Modified и ETag (Подробнее можно прочитать в спецификации протокола). Призваны они ускорить процесс получения контента с сервера, а точнее избавить клиента от загрузки данных, которые не были изменены с момента предыдущего запроса.

Так вот. Для меня факт существования двух, по-сути одинаковых, механизмов сообщить клиенту изменилось ли содержимое страницы или нет немного настораживал. Немного. Точнее я его не понимал для чего нужен ETag, если мне всегда было достаточно одного Last-Modified и юзкейса для другого я даже и представить не мог (хотя меня этот вопрос, признаться честно, не особо и волновал).

Доброго времени суток!

Еще одна часть серии моих переводов раздела о моделях из документации Django.

Перевод Django Documentation: Models. Part 1
Перевод Django Documentation: Models. Part 2

___Мета-параметры
___Методы моделей
_____Переопределение предопределенных методов
_____Использование SQL
___Наследование моделей
_____Абстрактные базовые классы
_______Мета-наследование
_______Будьте аккуратны с related_names


Перевод Django Documentation: Models. Part 4 (Last)

Привет!

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

Нашей целью было сделать бухгалтерию доступной для любого человека — поэтому мы сконцентрировались на небольшом сегменте рынка — индивидуальные предприниматели на 6%-ной упрощенке, работающие без кассы. Это позволило сделать сервис очень простым и понятным — без бухгалтерского лексикона, ссылок на нормативные акты и перегрузки ненужной информацией вроде расчета НДС, ЕНВД итд. И, я думаю, у нас это неплохо получилось.

Многие задают мне один и тот же вопрос:
«Как дебажить этот $%*!%$! JavaScript?».

Так вот, во-первых JavaScript — не $%*!%$! А как я его дебажу — сейчас расскажу.

(Примечание: наверное эта статья больше для новичков. Так что не судите строго)

У меня есть на примете как минимум два проекта, в которых понадобится активное управление с помощью клавиатуры. Поэтому, я сел и написал удобный и красивый плагин для jQuery, который выкладываю во всеобщий доступ под свободной лицензией LGPL.

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

Чаще всего прибегают к готовому решению от Google, с помощью которого можно еще и подзаработать на контекстной рекламе. Но для рунета я бы посоветовал сделать поиск при помощи сервиса Yandex.XML, потому что такой поиск больше адаптирован под морфологию русского языка. К тому же вы можете получить шанс получить самые жирные биды для контекста, если будете использовать поисковый директ.

В этом посте я хочу подробно показать вам, что подобный поиск организовать совсем не сложно. Это займет всего несколько минут и выльется в десяток строк на PHP.

Иногда скорость роста проекта несколько выше чем скорость оптимизации веб-приложения или приобретение более мощного оборудования под backend.

Наиболее простая схема «распараллеливания» нагрузки — вынос основной нагрузки на несколько frontend. Раньше приходилось мучиться (или наслаждаться, кому как) с webdav'ами, кластерными ФС и прочими хитростями чтобы обеспечить актуальную информацию, так было до тех пор, пока не появился nginx, а точнее proxy_store и proxy_cache в нём.

Хочу поделиться своим опытом создания простого Comet-чата. Периодически читал про эту технологию, и сейчас решил попробовать сделать что-либо сам. Получился небольшой чат, интерфейс которого я старался сделать похожим на интерфейс irc-клиента mIRC. Так как подобную вещь пишу первый раз, просьба прокомментировать возможные ошибки в программе и статье и описать более оптимальные пути решения задач. Посмотреть на работающий чат можно здесь: http://94.127.68.84:6884/

Появилось желание сделать сервис подобный letitbit.net в отдельно взятой стране на окраине Европы.
Требовалось:

• позволять загружать/отдавать большие файлы;
• не позволять перепубликовывать прямые ссылки на файлы;
• ограничивать количество одновременно скачиваемых файлов.

Для реализации выбрали NGINX в связке с PHP через fastcgi.
В NGINX добавили:

1. великолепный Nginx upload module, который позволяет избежать многократное копирование загруженного файла на пути NGINX-PHP. К тому же, при небольшой доработке, возможна загрузка сразу в нужную папку, что позволяет использовать простое переименование вместо копирования в PHP
2. нужную заплатку к модулю secure_link, позволяющую делать безопасные ссылки действительными ограниченное время

PHP взяли самый обычный и запустили через spawn-fcgi.
Поставили сервачок, напихали туда штук 12 терабайтных дисков.
Программист написал PHP код, а Марис Рускулис придумал следующий трюк с rewrite для NGINX, позволяющий избежать обращение к PHP при скачивании файла.
В результате, конфигурация NGINX выглядела примерно так:
http {
limit_zone regular $zonekey 10m;
limit_zone premium $zonekey 10m;
server {
root /www/oursiteishere;
location / { try_files $uri @files; }
location ~ \.php$ { try_files $uri @files; fastcgi_stuff_here; }
location @files { rewrite ^(.*)$ /index.php?$1 last; }
location /storage/ { root /storages/; internal; }
# Location for regular users
location ~ /download/.+/(.+)/0/.+/.*/(.+)$ {
set $fname $2;
set $username $1;
set $zonekey "$binary_remote_addr $username";
limit_conn regular 1;
limit_rate '100k';
secure_link_secret megasecret;
secure_link_ttl on;
if ($secure_link = "") { return 403; }
add_header Content-Disposition "attachment; filename*=UTF-8''$fname";
rewrite ^/download/([a-f0-9]+)/([\.~0-9a-zA-Z_]+)/([01])/([0-9]+)/(.+)/.+$ /storage/$4/$5 break;
}
# Location for premium users
# Location for upload using upload module
}
}

Замечательной вещью в данном конфиге является тот факт, что при скачивании файла по сгенерированной защищённой от подмены временной ссылке (проверку осуществляет secure_link) не вызывается PHP с последующим X-Accel-Redirect.
Возможно, данное решение накладывает ограничение на присутствие логики перед непосредственной отдачей файла, но тем не менее, на мой взгляд, является довольно оригинальным трюком, позволяющим немного сэкономить на fastcgi.

С mod_rewrite есть одна проблема, об которую набиты уже наверное 15 миллионов шишек: он просматривает список правил снова и снова, пока URL удается хоть как-то изменить.

Очень часто получаеются и бесконечные циклы(например добавление расширения — оно добавляется снова и снова, если специально регэкспом не ограничить), над которыми с непривычки приходится поломать голову. Все надежды на модификатор [L] тщетны — он лишь сразу запускает следующую иттерацию обработки. Да и без бесконечного цикла лишние иттерации скорости работы не добавляют :-)

Хочу поделится достаточно простым и универсальным средством борьбы с такой особенностью, который обнаружил только-что :-)

Много было в последнее время топиков о стартапах, организации команд, разработке ПО и некоторых других вещах, неразрывно связанных с софтверным или интернет-бизнесом. В этой статье я хочу рассказать, что сейчас будет вас ждать, пожелай вы открыть свою компанию по продаже программного обеспечения (ПО, далее софта). Ибо пока полноценных топиков на эту тему я не видел.

Зачем нужен этот топик? Чтобы после прочтения можно было однозначно ответить на вопросы «А оно мне надо?», «Стоит ли переводить проект в разряд стартапа (или наоборот)?», «Как заработать на своем труде в России?» и на ряд других более конкретно. И это только касательно России (если все будет хорошо, то выложу аналогичный топик и относительно международного софтверного бизнеса).

Внимание: вся нижеприведенная информация изложена с позиций минимизации затраченного времени (и увеличения надежности мероприятия) и с учетом отсутствия прописки в городе регистрации юр. лица (и отсутствия рабочего офиса).

Продукт и команда

Перед стартом обязательно имейте хотя бы что-нибудь. Что-нибудь, что приносит деньги. Без денежного потока (пусть даже в 10-20 тысяч рублей) затевать все это бессмысленно (далее будет понятно, почему, но первичные расходы на оформление всей волокиты составляют порядка 30к рублей). Естественно, открывать свое юридическое лицо и оформлять бизнес стоит в том случае, если вы собираетесь расти. И не просто расти, а очень сильно расти. Иметь оборот в 20-30 тысяч рублей можно и не имея никакого юридического лица, а при «нелегальном» обороте в районе 100 тысяч уже могут начаться различные проблемы с государством (и красиво оформить это может уже не получиться).

Итак, в самом начале у нас должен быть продукт. В принципе, все равно какой (если речь идет про бизнес, заключающийся в продаже софта и смежных услуг). Если к этому продукту «прилагается» команда, то поднять всю схему будет значительно проще: пока вы будете бегать по инстанциям с пакетами документов, продажи могут сильно просесть, потому что их некому будет обслуживать. Или просядет разработка. Или еше что-нибудь. Но обязательно просядет. Имейте это в виду.

Ладно, вроде у нас есть, что продавать (будь это хоть утилита «Time Machine для Windows»). У нас есть пара человек, которые разделяют ответственность за компанию и готовы работать во имя ее успешности. Что дальше?

Дальше самое интересное.

Доброго времени суток!

Данный топик представляет собой первую часть перевода документации Django, а именно раздела о моделях. Сразу хочу сказать, что я не являюсь профессиональным переводчиком и изначально делал перевод для себя. Все замечания и вопросы просьба писать в комментариях или посылать по хабрапочте. Надеюсь, информация окажется полезной для вас.

_Модели
___Небольшой пример
___Использование моделей
___Поля
_____Типы полей
_____Параметры полей
_____Автоматические первичные ключи
_____Подробные имена полей

Перевод Django Documentation: Models. Part 2
Перевод Django Documentation: Models. Part 3
Перевод Django Documentation: Models. Part 4 (Last)

Сегодня процесс создания сложных программных приложений невозможно представить без разделения на этапы жизненного цикла. Под жизненным циклом программы будем понимать совокупность этапов:

• Анализ предметной области и создание ТЗ (взаимодействия с заказчиком)
• Проектирование структуры программы
• Кодирование (набор программного кода согласно проектной документации)
• Тестирование и отладка
• Внедрение программы
• Сопровождение программы
• Утилизация

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

Сколько раз я уже перечитывал статьи Пола Грэма, столько раз я удивлялся его потрясающему умению открывать глаза на вроде бы обычные вещи. И потрясающей способности интересно описывать окружающий нас мир.

Да, это он в 1998 году продал свою компанию Viaweb интернет-гиганту Yahoo, которая впоследствии назвала этот продукт Yahoo Store. Да, это он основал венчурный фонд Y Combinator. Да, это его журнал BusinessWeek включил в список 25 наиболее влиятельных людей в Сети за 2008.

Хотите читать по-настоящему интересные аналитические статьи? Вам однозначно к Полу. Я настоятельно рекомендую прочитать его заметки. Особенно если вы it-шник. Особенно если вы собираетесь открывать свой бизнес.

Самый молодой миллиардер в мире, основатель Facebook Марк Цукерберг рассказывает, как занимался хакерством в университете, как запустил первую версию Facebook (10 000 строк кода), какие ошибки сделал после регистрации фирмы вместе со своими однокурсниками и как выходил на контакт с первыми инвесторами.

По словам Цукерберга, у него никогда не получалось хорошо «строить компанию», то есть уделять внимание планированию, финансовым показателям и тому подобным вещам. В реальности Facebook всегда воплощал в себе некую хакерскую культуру, то есть с самого начала они ставили единственную цель: сделать хороший проект с точки зрения программирования и производительности, чтобы понравиться людям. Других целей у компании не было. Они обслуживали растущий поток пользователей и докупались новыми серверами по $85. Расходная часть всегда опережала доходную.

Приветствую всех.

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

Собственно, в выборе системы кэширования особых вопросов не было — на ум сразу приходит всем известный memcached.

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

Итак, представим ситуацию, что мы храним в кэше данные записей блога под ключами post_. В определенный момент нам требуется сбросить все записи с постами, при этом не очищая кэш полностью (там могут хранится другие данные, значения которых все еще актуальны). Ситуация получается безвыходная. Мы не знаем список ключей постов, получить их нет возможности, сбросить ключи по паттерну тоже невозможно. Что же делать?

Conjoon — представляет собой веб-ориентированный персональный органайзер с особым упором на обмене сообщениями. Для наибольшей практичности, легкости в использовании и вообще восприятия информации, система построена на ZendFramework и ExtJS.

Для ускорения Zend Framework очень действенен такой финт: собираем все классы, которые нам нужны, в один фаил, а потом включаем eAccelerator и инклудим его в самом начале. Один фаил + еАкселератор круче, чем много фаилов.

Под катом — рассказ, как я это сделал. Это не самое умное, лучшее и красивое решение, поэтому я рад послушать ваши советы и замечания. В общем, топик этот — ради ваших советов и замечаний — тех, что по делу, а не по поводу всякой херни типа орфографических ошибок. Спасибо!