FreeBSD, сетевая Intel fxp, порт 100Мбит, polling, http accept-filter
в sysctl:

sysctl kern.maxfiles=90000
sysctl kern.maxfilesperproc=80000
sysctl net.inet.tcp.blackhole=2
sysctl net.inet.udp.blackhole=1
sysctl kern.polling.burst_max=1000
sysctl kern.polling.each_burst=50
sysctl kern.ipc.somaxconn=32768
sysctl net.inet.tcp.msl=3000
sysctl net.inet.tcp.maxtcptw=40960
sysctl net.inet.tcp.nolocaltimewait=1
sysctl net.inet.ip.portrange.first=1024
sysctl net.inet.ip.portrange.last=65535
sysctl net.inet.ip.portrange.randomized=0


Виталию Харисову посвящается

После перевода заметки «Оптимизируем CSS-производительность» и справедливых замечаний Виталия vithar, я решил поставить серию экспериментов по скорости работы CSS-селекторов внутреннего движка браузеров. Результаты получились весьма забавными, а местами, наверное, даже интересными.

Методика. Размер файлов

Естественно, что скорость работы одиночного CSS-правила весьма высока, и даже десятки и сотни их не должны заметно замедлить работу браузеров. Поэтому нужно ставить эксперимент по работе с несколькими тысячами правил, иначе точность результатов будет весьма невысока. Использовать JavaScript для генерации HTML/CSS-кода не представляется разумным, ибо тогда придется учитывать еще и скорость работы JS-движка в браузерах, в итоге, эксперимент будет недостаточно чистым.

В конце концов, было решено сгенерить статичные файлы (порядка 300Кб), которые будут содержать достаточное число различных CSS-селекторов. Это самое «достаточное» число подбиралось по нескольким параметрам, в том числе: размер файла (гонять несколько Мб через браузер и интернет совсем не хотелось) и скорость работы HTML/CSS-кода в браузерах (она должна быть достаточно низкой, чтобы файлы в несколько сотен Кб уже заметно тормозили при открытии).

читать дальше на webo.in →

Jared Kuolt создал небольшой скрипт кэширования для Django. Всем замечателен: и простотой и размером.

Но у скрипта StaticGenerator и nginx-конфига, приведенного Jared-ом, есть недостатки:
1) актуально только для сайтов без регистрации;
2) работа с ссылками только простого вида;
3) генерация только при изменении/добавлении контента и/или комментариев.

Я исправил эти недочеты, добавил кое-что интересное в скрипт, и получился StaticGenerator Pro.

Чем больше я работаю над своим первым проектом на работе, тем больше мне хочется в нем поменять и тем больше я жалею о том, что перед началом работы я не прочитал до конца «The Definitive Guide to Symfony» и не изучил плагины для Symfony. Многие из них мне бы помогли намного сократить время разработки и, что самое главное, не думать о том, как красиво реализовать те или иные вещи… И еще одно — если у вас уже есть кусок системы (как это было у меня), который вы собираетесь переписывать с использованием вашего фреймворка (или просто переписывать, потому что код вам не нравиться) — то мой вам совет — потратьте время на то, чтобы спроектировать этот кусок на план вашей новой системы, не бросайтесь сразу всё переписывать (каюсь, я поступил именно так), так как после анализа (который, возможно, займет у вас не один день, и даже не одну неделю), возможно, от предыдущей архитектуры системы не останется и следа.
Вообще, я люблю проектировать, продумывать, анализировать те или иные решения, которые хочу внедрить в систему (хотя, признаюсь, опыта у меня в этом маловато), но как обьяснить заказчику, что ты провел день в раздумьях… Эх…
Ну ладно, это я отвлекся. Сегодня хочется рассказать о том, с чего стоит начать при разработке системы с помощью Symfony и каких правил следует придерживаться.

В этом топике я расскажу как установить и настроить Apache2 + PHP5 + MySQL + virtual hosts + xdebug, а также XDebug в Eclipse+PDT.

Очень долго я не мог решить задачу по простому способу передачи параметров в обработчик событий JavaScript, но недавно в обсуждении рабочих моментов с Артемом Горбуновым меня осенила одна идея о которой стоит

За последнее время мне пришлось довольно основательно пообщаться с несколькими сервисами Yahoo! В этой заметке расскажу об одном из них, который для многих может оказаться полезным. Это сервис прогноза погоды Yahoo! Weather.

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

Yahoo! Weather порадовал отсутствием перечисленных недостатков. Информация о текущей погоде, а так же прогноз на ближайшие 5 дней экспортируется с их сервера в формате RSS. На мой взгляд, выбор этого формата притянут за уши, т.к. погодная RSS «лента» содержит всего однин item. Те же данные можно было бы экспортировать в более лаконичном виде, но в Yahoo, по всей видимости, расчитывали на стандартные методы обработки RSS, что тоже довольно весомый довод. Стандарт — это все-таки стандарт.

Адрес RSS фида для интересующего города можно найти на сайте weather.yahoo.com.



В общем виде URL выглядит следующим образом:

xml.weather.yahoo.com/forecastrss?p=код_города&u=единицы_измерения

Первый параметр — идентификатор интересующего города. Второй параметр определяет, в каких единицах будет выдаваться температура. Значение «c» соответствует градусам Цельсия, «f» — градусам Фаренгейта.

Примечание: ниже перевод статьи Dean Edwards «Optimising Performance» с советами по написанию CSS-кода для Internet Explorer'а, который будет быстрее отрабатывать на клиенте. Мои комментарии далее курсивом.

При первоначальном поиске информации по теме удалось только наткнуться на советы от разработчиков Firefox, однако, последняя редакция датирована 2000 годом, да и сами советы несколько противоречивы. Если кто-то может поделиться информацией по теме, сделайте это, пожалуйста, в комментариях.

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

читать дальше на webo.in →

Ниже перевод статьи «Optimizing Page Load Time», в которой автор математически рассчитывает оптимальный размер файлов для эффективной передачи при веб-запросах, рассматривает некоторые прикладные вопросы оптимизации загрузки страницы с учетом особенностей браузеров, а также дает несколько развернутых и ценных советов. Мои комментарии далее курсивом.

Существует распространенное мнение, что быстро загружающая страница положительно влияет на впечатление пользователя (improve the user experience). В последние годы многие сайты начали использовать для этой цели технологию AJAX, чтобы уменьшить время ожидания (при загрузке данных). Вместо того, что запрашивать с сервера новую страницу полностью при каждом клике, браузер часто можно либо поменять вид самой страницы (отобразив или скрыв какие-либо блоки), либо подгрузить небольшую порцию HTML-, XML- или JavaScript-кода и внести изменения на существующую страницу. В любом случае, это значительно уменьшает время, проходящее между кликом пользователя и окончанием визуализации браузером нового содержания.

Что влияет на загрузку страницы?

Однако, для большинства сайтов, загрузка страницы затрагивает десятки внешних объектов, основное время загрузки тратится на различные HTTP-запросы картинок, JavaScript-файлов и файлов стилей. AJAX, возможно, поможет в данной ситуации, но ускорение или удаление этих HTTP-запросов может принести гораздо больше пользы, хотя на данный момент нет единого мнения (a common body of knowledge), как именно это следует делать.

читать дальше на webo.in →

Примечание: ниже находится перевод статьи «Speed Up Your Javascript Load Time», в ней автор рассматривает некоторые наиболее эффективные техники и методы действия по уменьшению времени отработки JavaScript'а на клиенте. Большая часть из них общеизвестна, но в статье важно не просто их перечисление, а общий подход для решения задачи оптимизации времени загрузки. Далее мои комментарии курсивом.

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

Пользователи так ненавидят ждать: им подавай все и сразу. Давайте тогда рассмотрим несколько методов, которые помогут вам «причесать» ваш сайт. Здесь находятся все рабочие примеры, которые будут приведены далее.

читать дальше на webo.in →

Структура правильного HTML-документа базируется на логике, порядке и использовании семантически корректной верстки. Если у вас есть заголовок — используйте для него елементы Heading(h1-h6), если абзац/параграф — paragraph(p). Если у вас есть список — используйте элементы списков (ul/ol), если вы цитируете — используте blockquote или cite. Эти элементы придают смысловое значение разметке, делая ее семантически корректной, в дополнение к правильной структуре.

После составления корректного HTML-макета, используйте CSS для визуального оформления. (Тут уже дело вкуса, некоторые верстают CSS «с лету», а некоторые только после создания HTML-макета)

Стандарт XHTML более строг к синтаксису чем HTML, он не допускает наличия незакрытых тегов, одинарные теги тоже должны быть закрыты (self-closing). Элементы в XHTML прописываются строчными, а не заглавными буквами. Значения атрибутов элементов должны быть указаны в кавычках. Есть и другие отличия, но более подробно я описывать их здесь не буду.

Опубликована новая версия Jevix — 0.9.5.

Основное отличие новой версии в том, что с этих пор Jevix можно использовать как средство для всестороннего контроля и преобразования текстовых данных больших интернет-проектов с «User-Generated» материалом.

Теперь Jevix умеет не только применять правила типографики, унифицировать HTML/XML разметку, но и контролировать перечень допустимых тегов с возможностью определения списка допустимых атрибутов для каждого тега отдельно. Также предусмотрена возможность предотвращения вероятных XSS-атак, скрытых в HTML-коде.

После публикации статьи на тему архивирования JS/CSS-файлов для последующей выдачи клиенту, я задумался на тему, какой же метод минимизации (minify) следует использовать. В докладе на конференции ClientSide'2007 не удалось установить четкого критерия, чем и как лучше всего сжимать JavaScript-файлы. Данная заметка посвящена рассмотрению как раз этой проблемы.

Задача

В качестве цели исследования был закреплен анализ всех известных средств статической минимизации JavaScript-кода, после чего нужно было ответить на три основных вопроса:

• Имеет ли смысл пользоваться каким-либо минимизатором JS-кода?
• Есть ли среди них универсальное средство, показывающее лучшие результаты в подавляющем большинстве случаев?
• Если такого средства нет, то каковы критерии использования набора инструментов?

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

читать дальше на webo.in →

Примечание: ниже находится перевод статьи «CSS Expression Optimization», в которой автор немного освещает использование и проблематику динамических свойств в CSS (aka CSS expressions). Также автор предлагает способ их оптимизации (исполнение один-единственный раз вместо постоянного выполнения). Далее приведены несколько тезисов с ClientSide'2007 по заявленной тематике. Мои комментарии даны курсивом.

CSS expressions были впервые представлены в Internet Explorer 5.0, который позволял назначать JavaScript-выражение в качестве CSS-свойства. Например, следующий код позволит разместить элемент в зависимости от того, какого размера окно браузера.

#myDiv {
   position:   absolute;
   width:      100px;
   height:     100px;
   left:       expression(document.body.offsetWidth  - 110 + "px");
   top:        expression(document.body.offsetHeight - 110 + "px");
   background: red;
}

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

читать дальше на webo.in →

Наткнулся на днях на новость о конкурсе, в котором предлагают создать минимальный JavaScript-код, который будет сам себя копировать дальше. Автор конкурса — Robert Hansen aka RSnake, достаточно крупный специалист по информационной безопасности.

Условия

По условиям конкурса от кода требовалось следующее:

Blitz Templates — быстрый и удобный шаблонизатор для крупных интернет-проектов, разрабатываемых на php. На первых порах может быть не совсем очевидно, зачем нужен Blitz для php, в то время, когда этот язык, по сути дела, и есть шаблонизатор, только весьма навороченный.

Примечание: ниже частичный перевод статьи «Compress JavaScript and CSS without touching your application code», в которой описывается статичное сжатие CSS- и JS-файлов на сервере и корректная выдача их затем клиенту. Далее даны мои комментарии с более комплексным решением. Приношу извинения, если для кого-то тема будет слишком знакома или неинтересна: в Рунете нормальной статьи на данную конкретную тематику обнаружить не удалось.

Для обеспечения корректного архивирования вашего веб-контента, по-видимому, наиболее общий подход будет заключаться в выполнении по порядку следующих пунктов:

• Проверить, умеет ли клиент принимать файлы в формате gzip-encoded.
• Обеспечить соответствующий вывод на стороне сервера через gzip-функции, либо уповать на то, что всем этим займется непосредственно Apache.
• Поиграться с .htaccess, чтобы обеспечить корректный content type.

читать дальше на webo.in →

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

Итак, вот они:

Да-да, все «реальные пацаны» умеют строить веб-системы, способные выдержать монументальные нагрузки. Ну а для «непацанофф» всегда есть гугл и масса сайтов посвящёных данной тематике. Однако «проблема роста» включает в себя не только вопрос верной сервировки данных клиенту и их грамотной репликации/распределении на кластере. Зачастую проблемы возникают от того, что всё как раз-таки наоборот — слишком шустро работает. Рассмотрим пример из недавней практики:

Наш новый фронтенд-сервер сейчас вполне справляется с нагрузкой и в оптимизации не нуждается (чего нельзя сказать о базе данных), но после того, как я очередной раз посмотрел на его top, мне вдруг стало жалко ожесточённо разнашиваемых дисков, и я решил уделить этому пару минут и поставить eAccelerator.