#include

Зачастую, краеугольным камнем производительности работы сервера является скорость работы файловой системы. Её можно увеличить с помощью создания дисковых массивов RAID0 — запись/чтение побитово производится на оба диска, однако рано или поздно слоты под диски заканчиваются, надёжность RAID0 оставляет желать лучшего — при выходе одного из дисков, рушится вся система. RAID10 опять же упираемся в количество дисков.

Как альтернатива, использование сетевых фс. Наибольшее распространение получила NFS, но для боевых задач с её скоростью и неочевидностью настройки прав доступа практически непригодна.
«Сравнивать GPFS и LustreFS — это как сравнивать IBM и SUN.»
Анонимус из интернетов.
В ТОП-300 суперкомпьютеров Мира половина из первых 50 используют LustreFS, которая очень проста в первоначальной настройке.

Я делаю шаблоны на чистом HTML/CSS уже больше восьми лет. За это время я убедился, что различные соглашения и документирование помогают в работе. Конечно, они не спасают от периодических CSS-кошмаров. Они лишь делают их менее болезненными. Мое решение — следовать определенным принципам в написании стилей. Эти принципы образуют основание, на котором будет строиться все дальнейшее написание стилей, облегчая работу над растущим проектом.

Некоторое время назад мы представляли уважаемой публике наши open source продукты для веб-разработчиков — редактор elRTE и файловый менеджер elFinder. После анонса мы получили немало отзывов и надо сказать были изрядно удивлены, что интерес к файловому менеджеру оказался заметно выше чем к редактору.

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

И сегодня с удовольствием от хорошо сделанной работы предлагаем попробовать наше фирменное блюдо elFinder!

Здравствуй, хабралюд.

Вступление

С выходом symfony 1.4 разработчики фреймворка фактически обязали нас использовать вместо привычного Propel, новую, мною неизведанную ORM Doctrine. Нет, конечно они не заставляют использовать Doctrine, при желании в 1.4 можно подключить и Propel, но как мне показалось — если разработчики такого масштаба сделали Doctrine по–умолчанию в своём фреймворке, то значит это говорит о большей пригодности нежели Propel. Я не стал противиться ещё по той причине, что просто напросто хотелось чего–нибудь нового и стал работать с Doctrine.

В связи с появившейся задачей, с желанием повысить собственную квалификацию и просто из интереса решил попробовать на себе, что такое Doctrine Behaviors, а полученным опытом поделиться с вами. Как писать плагины для symfony framework'a я уже рассказывал, на этот раз хотелось бы рассказать о написании плагина, который использует «Doctrine Behavior».

-О чём вы, Морфеус?

Количество фреймворков в мире растёт с пугающей скоростью. Тысячи их уже на данный момент. Благо, лучших из низ — не так много. Весь мир Web разработчиков просто подразделился на несколько групп, которые отадют предпочтение тому или иному фреймворку. Я не люблю тёрок и холиваров, так что бог с ним с тем, что лучше. Я лишь хочу поговорить с разработчиками ASP.NET о Ruby on Rails.

Зачем?

Расскажу свою историю. На ASP.NET я пишу с 2004 года. Знаю множество закоулков данной системы и знаю, что она сама по себе восхитительна. Я пережил 3 больших проекта на .NET и написал с 10 сайтов, которые сейчас продолжают стабильно работать. Если говорить о фрейворкнутости, то .NET меня удовлетворял всем. В самых больших проектах я находил решения самых сложных задач. И вот, через 6 лет мне просто захотелось посмотреть, а что же есть другого на рынке? Естественно, первым делом я наткнулся на RoR.

Появилось желание воспользоваться CDN, но оставался вопрос, «а на сколько оно мне будет по карману?» В принципе можно посмотреть расценки на самом сайте или воспользоваться даже калькулятором, но всё же остаётся не понятным сколько оно может в итоге выйти $1 или $30.

Минимальный прайс

В обязательном порядке придётся заказать Amazon S3, т.к. облака могут работать только в связки с ними, он стоит минимум 4 цента (по центу за место + трафик + PUT, COPY, POST, LIST + GET и остальные запросы).

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

Итого минимум: 12 центов ( ~ 3.6 рубля)

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

Почему бы не избежать этих неприятностей, прогнав нагрузочный тест?

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

Под катом рассказываю, как с нуля организовать незамысловатый нагрузочный тест сайта при помощи Apache JMeter.

На данный момент, порт VirtualBox на FreeBSD уже достаточно стабилен и вполне пригоден для постоянного использования. Но при установке на gui-less машинах возникает несколько проблем. Дальше речь пойдет об установке и использовании VirtualBox на FreeBSD машине без X11.

В качестве распределенного хостинга возьмем классический пример — создание блогосервиса на основе mu-Wordpress.
Задача — при ограниченном бюджете собрать отказоустойчивую (насколько это возможно) геораспределенную систему. Соответственно все оборудование берется в аредну в различных Дата-Центрах.
И тут следует сказать что не все Дата-Центры одинаково полезны. Высококачественные сдают сервер за 800$, а у низкокачественных вполне можно взять примерно такой же сервер в аренду уже за 100$. И именно эти особенности надо учитывать при создании геокластера.

Теперь о небольших хаках. По умолчанию в mu-Wordpress функция отдачи загружаемого контента сделана крайне неудачно — через PHP. Соответственно она была заменена на загрузку отдельным сервисом и вставкой загружаемого контента прямой ссылкой на статику.
Вторым хаком была модификация контроля кеширования. Кроме указаний кешировать статичные элементы дизайна был введен еще такой хак, который запрещал кешировать запись на время ее обсуждения (по умолчанию — 14 дней), а уже после она отдавалась с заголовком разрешающим кеширование. Кроме того хитро кешировались фиды RSS.
Финальным хаком стала система синхронизации БД — каждый INSERT/DELETE/UPDATE выполнялся на «соседе». Получился такой себе софт-рейд в контексте MySQL+PHP.

За 2.5 года использования symfony мне постоянно приходится сталкиваться с проблемой недопонимания программистами на symfony идеи html-кеширования. Цель этого поста — донести до светлых умов symfony-девелоперов осознание парадигмы использования partials & components.

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

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

Коротко о ясном

В интернете есть множество сайтов где выкладываются разного рода иконки, но по настоящему хороших сайтов мало. Но я нашел такой сайт. Иконки высшего качества собранные воедино совершенно бесплатно распространяются на сайте weloveicons.com. Иконки предоставляются в форматах для Mac OS, Windows и в .PNG

Каждый найдет себе то, что ищет

С момента публикации первого топика о создании хабраподобной статистики (которую, кстати, почему-то тут не обновляют) с импортированием данных из Google Analytics прошел ровно год.



Весь этот год все работало, статистика обновлялась, графики рисовались… пока все не сдохло. Как это и присуще гуглу, сдохло оно не сразу у всех, а потихоньку, в течение недели. При беглой диагностике проблемы выяснилось, что она заключается в гугловой авторизации. Учитывая, что скрипт авторизации мною был заимствован, разбираться в нем не было никакого желания, и тут до меня дошло — ведь Google выпустил API для аналитикса! Поэтому было решено не обрабатывать напильником существующую версию, а просто получить данные цивилизованно, посредством API, тем не менее, оставив при этом «структуру» и основные моменты предыдущей версии.

Небольшое исследование на тему, какие все-таки возможности поддерживает view.yml в symfony.

Мне давно хотелось, чтобы все css и js файлы были подключены в одном месте. Из-за того, что я постоянно пользуюсь условными комментариями для отделения «богомерзких» браузеров, мне приходилось хранить все файлы прямо в шаблоне. В случае, если шаблонов — несколько, начинались проблемы из разряда «там добавили, здесь забыли». Поэтому было решено поковыряться в недрах symfony, благо в changelog к 1.2 русским по белому написано: добавлена поддержка условных комментариев.

Я часто вижу ошибки, связанные с созданием индексов в MySQL. Многие разработчики (и не только новички в MySQL) создают много индексов на тех колонках, которые будут использовать в выборках, и считают это оптимальной стратегией. Например, если мне нужно выполнить запрос типа AGE=18 AND STATE='CA', то многие люди просто создадут 2 отдельных индекса на колонках AGE и STATE.

Намного лучшей (здесь и далее прим. переводчика: а обычно и единственной верной) стратегией является создание комбинированного индекса вида (AGE,STATE). Давайте рассмотрим почему это так.

Сегодня был неожиданно удивлен, какие удобные штуки таит в себе MySQL. ;-)

Хочу представить вашему вниманию фичу MySQL — профайлинг.
Появилась она начиная с версии 5.0.37.

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

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

Итак, как пользоваться:

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации

Это не попытка создать список всех существующих инструментов для CSS разработки. Только некоторые, наиболее полезные были отобраны и размещены в соответствующих категориях.


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

Люди не очень любят регистрироваться. Это же нужно (в общем случае) придумать логин и пароль, зайти в свою почту, дождаться письма, открыть его, перейти по ссылке активации аккаунта, а потом еще этот логин с паролем не забыть. Но ведь уже давно есть способ, с помощью которого все эти шаги не нужны. Более того, не нужно вообще ничего вводить с клавиатуры, 2 щелчка мышью и все, человек зарегистрирован.

Заметно, что на Хабре в последнее время всё чаще поднимается вопрос типографики, и это не может не радовать, ибо «оттипографленные» тексты и читать приятнее, и выглядят они куда аккуратнее обычных. Да и в целом создается ощущение, что автор заботился о своих читателях.

Примерно год–полтора назад я написал свой плагин для популярного редактора TinyMCE, который умел типографить тексты посредством веб-интерфейса типографа Студии Лебедева. С того времени плагин успешно используется в проектах студий Nimax и Artilleria. После недавнего поста я решил таки его опубликовать, а также немного его усовершенствовал — добавил Типограф тов. spearance, а также Типограф студии Муравьёва. Способ типографирования можно выбрать непосредственно перед «операцией».

Усовершенствованный типограф я сегодня и представляю на суд публики.

• Демка (UTF-8): test.dis.dj/typograf
• Демка (CP1251): test.dis.dj/typograf/cp1251.php
• Качаем по адресу: test.dis.dj/typograf/typograf.zip
• Скрипты самих типографов: test.dis.dj/typograf/typograf-engines.zip (рекоммендую ознакомиться с инструкцией)