Почти год назад на RIT 2008 Игорем Сысоевым была анонсирована поддержка кеширования в будущих версиях nginx. И вот сегодня вышла новая бета nginx 0.7.44, в которой появилось это долгожданное кеширование

Этот функционал оценят в первую очередь разработчики высоконагруженных систем, для которых операция установления сетевого соединения с backend «дороже» обычной дисковой операции (с точки зрения затраты ресурсов)

На RIT 2008 автор отмечал, что большим преимуществом nginx перед демоном squid, который тоже можно использовать как reverse proxy, является отсутствие стартового торможения, когда squid начинает сканировать директорию с кешем, что в народе называется «давать сквида».

Хочется отметить, что некого подобия кеширования можно было добиться с помощью использования директив proxy_store + try_files, но управлять таким кешем было достаточно сложно и затратно.

Очень интересно было бы услышать отзывы от пользовалелей замонтировавших кеш на SSD-диск.

Что такое PHP Speedy? Это набор php-скриптов, которые позволяют объединять и сжимать CSS- и JS-файлы для веб-сайта, написанного на PHP. Изначально разрабатывался как приложение к Wordpress, но сейчас получил более широкое распространение.

PHP Speedy был выбран в качестве основы для начала разработки Web Optimizer — веб-приложения, автоматизирующего клиентскую оптимизацию. Предполагается, что такое приложение можно будет максимально быстро и максимально легко развернуть на любой платформе, а оно уже само позаботится о всех действиях, связанных со скоростью загрузки страницы.

Как показала практика, клиентская оптимизация интересует большой круг людей. Но очень многих останавливает то, что нужны специальные знания для освоения этой области. Web Optimizer создается как раз, чтобы убрать этот барьер (и как наш ответ Чемберлену www.getrpo.com :).

Вступление

Забавно, но когда программист разрабатывает какой-либо продукт, он редко задумывается над вопросом могут ли на одну кнопку в один момент времени нажать одновременно 2000 человек. А зря. Оказывается могут. Как ни странно но большинство движков, написанных такими программистами, очень плохо ведут себя под большими нагрузками. Кто бы подумал, а всего один лишний INSERT, не проставленный index, или кривая рекурсивная функция могут поднять load averages чуть ли не на порядок.

В этой статье я опишу как мы, разработчики проекта, сумели выжать из одного сервера с Pentium 4 HT / 512Mb RAM, максимум, держа одновременно 700+ пользователей на форуме и 120,000 на трекере. Да, проект этот — торрент трекер. Предлагаю сразу оставить в стороне разговоры о копирайтах и правах, мне это не интересно, что действительно интересно — это HighLoad.

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

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

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

Под катом много букв! Чтоб не потеряться в их обилии все пункты выделены заголовками.

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

Здесь я попытаюсь ответить на эти вопросы, рассмотрев:

• Причемущества от наличия SSL вообще, и подписанного сертификата в частности.
• Типы SSL-сертификатов.
• Пути их получения.

Я не претендую за 100% верность данной статьи, она основана только на моем мнении и личном опыте :)

JS Charts является бесплатным JavaScript-генератором графиков и схем, который требует минимум знаний программирования. С JS Charts рисование диаграмм становится простой и легкой задачей. Он не требует никаких дополнительных плагинов и серверных модулей. Просто подключите скрипты, подготовьте данные для схемы в XML или массиве JavaScript и ваша таблица готова.

В данный момент стоит вопрос о разработке высокопроизводительного веб-приложения, которое могло бы выдерживать миллионы хитов в день.
Целевая нагрузка от 1000 хитов в секунду и выше (вплоть до заполнения гигабитного канала).

Имел ли кто-либо из читателей опыт разработки веб-приложений на С++? Предлагаю обсудить сложности и ограничения.
Подразумевается что приложение не будет иметь утечек памяти(и соответственно проблем со стабильностью), и 2-3-х кратное увеличение цены разработки по сравнению с PHP приемлимо.

Какие варианты вижу я:

Сервис userfly даёт возможность визуально посмотреть, что и как делал пользователь на вашей странице.
Пока все это в разработке и видимо еще много чего нужно сделать, но основу уже можно попробывать

После регистрации userfly генерирует небольшой Яваскрипт, который нужно вставить в header страниц. После этого все передвижения пользователей будут записыватся, а вы вскоре сможете посмотреть, как небольшой видеоролик, что-же делают посетители на вашей странице, что ищут, какие функции используют чаще и т.д.

Уже давно использовал плеер производства http://flv-mp3.com/, который отличался простотой и элегантностью, но давеча получил письмо с новостью о выходе новой версии их замечательного плеера. Мое описание возможно покажется слишком эмоциональным, но это только потому, что плеер — Это бомба!

Прежде всего, демо-сайт — http://uppod.info/. После часа разборок с настройками, я могу заверить, что все фишки демосайта реализуются плеером на ура.

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

Хотел бы сразу отметить, что статья достаточно объемная и часть информации уже была опубликована мной на Хабре. Цель данной статьи объединить максимальное количество информации про новую версию Internet Explorer и представить ее в приемлемом объеме.

В комментах принимаю замечания и исправления.

Столкнулся с необходимостью масштабирования большого количества фотографий. Конечно, думаю есть и более элегантное решение,
но поскольку гугла под руками не было — быстро набросал фронт к imagemagick на bash. Думаю, кому-то он может пригодиться.

Свойство clear со значениями left, right, both действительно очищает поток в отличие от overflow со значеним hidden, которое создаёт отдельный контекст форматирования для выбранного элемента, тем самым локализуя действие свойства float внутри элемента к которому применён.

Тег <marquee> известен многим. Этот тег позволяет создавать на странице простейшую анимацию в виде плавного скроллинга текста. <marquee> появился в Internet Explorer и не является стандартным тегом, тем не менее, поддерживается большинством браузеров в целях совместимости. В наши дни W3C не рекомендует использовать <marquee>.

Однако не многие знают, что marquee обретает жизнь в новом лице.

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

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

Большинство имеющихся руководств посвящено тому, как надо писать. Я же расскажу о том, как писать НЕ надо :-)

Данный текст является вольным переводом вики-страницы «Bash pitfalls» по состоянию на 13 декабря 2008 года. В силу викиобразности исходника, этот перевод может отличаться от оригинала. Поскольку объем текста слишком велик для публикации целиком, он будет публиковаться частями.

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

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



Последний, шестой пост, будет посвящен различным техническим вопросам работы с memcached: анализу статистике, отладке и т.п.

Предположим у Вас есть сайт. Предположим вы его оптимизировали по самое «немогу», но всеравно хочеться больше.
Лично мне хотелось, но долгое время не получалось.
Когда я победил тормознутость базы кэшированием запросов, тормознутость блоков — кэшированием блоков, а целые страницы кэшировать я не мог…
Cайт конечно стал работать много быстрее, но начал тормозить уже… мемкэшед?

Предыстория

Как известно, перед тем, как выложить сайт в нет, мы его разрабатываем. И делаем мы это, как ни странно, на машине разработчика. И давно замечено, что javascript, а в некоторых случаях и css удобнее при разработке держать в нескольких файлах.Проблема в том, что, согласно принципам, описанным в статье Best Practices for Speeding Up Your Web Site (перевод доступен на сайте webo.in), для ускорения загрузки сайта нам нужно произвести следующие манипуляции над javascript и css файлами:

1. Слить весь javascript в один файл, причем, желательно так, чтобы сохранился нужный порядок — т.е., скажем, библиотека jQuery — была ближе к началу, а функции и объекты, которые ее используют — после нее.
2. Слить весь css в один файл
3. Сжать эти большие файлы с помощью какой-нибудь утилиты вроде yui-compressor (за исключением css-файлов, название которых начинается, скажем, с префикса ie_, которые содержат data:URL, и поэтому критично относятся к переходам со строки на строку, так что их для собственного спокойствия лучше не сжимать)
4. Расположить их в таком порядке — css-файл как можно ближе к открывающему тэгу head, а js-файл — как можно ближе к закрывающему тэгу body.
5. Выставить HTTP-заголовок expires на подольше, чтобы браузер пользователя их закешировал. Ну а для того, чтобы при следующем билде у пользователя обновился js и css надо этим файлам дать какое-нибудь уникальное имя.
6. Перед отдачей файлов клиенту сжимать их с помощью gzip

К чему это я?

Пункты 5 и 6 уже подробно расписаны в других местах.
Я же хочу рассмотреть в этой статье вопрос автоматизации пунктов 1,2,3,4. А точнее, я хочу предложить инструмент, с помощью которого одним (ну, максимум — двумя-тремя :) нажатием кнопки можно выполнить пункты 1, 2, 3, 4 настоящего списка и получить готовые к заливке на сервер javascript и css файлы.

Или об особенностях управления отдаваемым контентом в PHP.

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

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