Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный 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. Минусы оптимизации

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

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

Раньше, эта проблема решалась увеличением количества процессов-воркеров. Теперь есть альтернативное решение. :) Однако, перед тем, как включать файловый AIO, стоит учесть ряд нюансов.

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

Во-вторых, файловый AIO работает только на FreeBSD 4.3 и выше, либо в Linux, с версии ядра 2.6.22 и выше.

В-третьих, AIO во FreeBSD имеет смысл включать только в версиях FreeBSD-6.4 STABLE, FreeBSD 7, или новее. В более ранних версиях, при включении AIO, сетевая подсистема начинает использовать Giant Lock, что означает невозможность одновременного выполнения какого-то другого системного вызова. Другими словами, почти никаких выгод от асинхронности мы не получим.

Ну и наконец, при использовании AIO под Linux надо также включать directio. Также, если я всё понял правильно, в линукс пока невозможно использовать AIO для подгрузки данных для sendfile, поскольку включение directio отключит использование sendfile автоматически.

Если вы по-прежнему считаете, что оно вам нужно, AIO включается очень просто. Для Linux, фрагмент конфига будет выглядеть примерно так:

aio on; # включаем AIO
directio 512; # включаем O_DIRECT для файлов, размером 512 байт или больше
output_buffers 128 512k; # зная размер и примерное количество одновременно отдаваемых файлов, можно подобрать более подходящие значения


Ссылки:
Описание AIO в документации на Nginx
Changelog

Простой способ защиты от HTTP DDoS — включить syn-cookies и заблокировать подонков. Но что делать если атакует 5к-10к хостов да еще и с динамическими IP? Тут нам на помощь придет frontend-backend архитектура c промежуточным кэшированием! Почему с промежуточным кэшированием? А потому что в моем случае от шквала запросов от frontend'а backend умирал унося за собой систему.

Зачем всё это? — спросите вы. Да просто захотелось поделиться с общественностью некоторым опытом, полученным в процессе оптимизации vds под нужды одного общеизвестного блого-социального движка, который на обычном хостинге чувствует себя, мягко скажем, некомфортно.

Началось всё с того, что я ушёл от firstvds, где уже ничто не спасёт от тормозов. Ушел на ганди.нет, взял одну шару (1 share), которую дали на месяц бесплатно. Кстати, акция эта (This summer, your server is free!) вроде еще не закончилась. ;) И начал на этой шаре проводить зверские эксперименты с установкой разного ПО. Тестировал результаты с помощью siege.

В итоге конфигурация из сабжа оказалась самая быстрая. Опытом её установки и настройки я и хотел бы с вами поделиться.

Часть I — Часть II — Часть III — Часть IV — Часть V — Часть VI

Часть V

Очевидно, что в сфере высоких технологий развитие зачастую происходит быстро и бурно. Так произошло и со средствами отображения информации. В течении каких-то двух-трёх лет обычные ЭЛТ-мониторы почти целиком и полностью были вытеснены стремительно дешевеющими ЖК-собратьями. Что позволило существенно улучшить как геометрию отображения, так и цветопередачу, а также снизить утомляемость глаз за счёт отсутствия вредного мерцания. И если несколько лет назад подобное утверждение в пользу TFT-панелей можно было бы оспорить, то теперь этот факт не вызывает ни у кого сомнений: ЖК-дисплеи намного лучше для повседневной работы рядового пользователя. В связи с этим фактором возникла необходимость поиска качественно новых алгоритмов отображения шрифтов. Одно из таких решений пусть не сразу, но всё же получило определённое признание в среде пользователей, и на сегодняшний день является чуть ли не самым популярным на современных платформах. Речь, конечно же, о технологии рендеринга ClearType, которая послужила причиной разработки новых веб-ориентированных шрифтов…

Готовим макет для клиента. Часть II: Если гладить, то как?

Часть I: Гладить или нет?
Часть II: Если гладить, то как?

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

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

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

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

ВНИМАНИЕ: в статье имеется большое количество крупных изображений.

Перевод «Operating System Interface Design Between 1981-2009»

Графический пользовательский интерфейс (GUI — Graphical User Interface) это средства позволяющие пользователям взаимодействовать с аппаратными составляющими компьютера достаточно комфортным и удобным для себя образом.
В течении многих лет для большого количества операционных систем, таких как OS/2, Macintosh, Windows, AmigaOS, Linux, Symbian OS, и т. п., было создано еще большее количество графических интерфейсов.
Давайте попробуем взглянуть на эволюцию дизайна интерфейсов этих систем, начиная с 80-х годов.
Должен заметить, этот топик демонстрирует только значительные достижения и этапы в области графического дизайна (а не операционных систем в целом), да и не все системы существуют и по сей день.