Вдохновившись общением с Эндрю Босвортом на РИТ++, решил воплотить идею Facebook по социализации всего в интернете у себя на проекте www.bitrixonrails.ru, прежде всего добавив систему комментариев. Хотел рассказать о ее внедрении и узнать ваше мнение о ее полезности/удобности.

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

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

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

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

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

В web-сервер и reverse-proxy nginx встроены очень мощные возможности по кэшированию HTTP-ответов. Однако в ряде случаев документации и примеров не хватает, в результате не все получается так легко и просто, как хотелось бы. Например, мои конфиги nginx-а местами написаны кровью. Этой статьей я попробую немного улучшить ситуацию.

В этой статье: а) подводные камни при полностраничном кэшировании; б) кэширование с ротацией; в) создание динамического «окна» в закэшированной странице.

Я буду предполагать, что вы используете связку nginx+fastcgi_php. Если вы применяете nginx+apache+mod_php, просто замените имена директив с fastcgi_cache* на proxy_cache*

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

Кэширование всей страницы целиком

Если на вашем сайте главная страница хоть и генерируется динамически, но меняется достаточно редко, можно сильно снизить нагрузку на сервер, закэшировав ее в nginx. При высокой посещаемости даже кэширование на короткий срок (5 минут и меньше) уже дает огромный прирост в производительности, ведь кэш работает очень быстро. Даже закэшировав страницу всего на 30 секунд, вы все равно добьетесь значительной разгрузки сервера, сохранив при этом динамичность обновления данных (во многих случаях обновления раз в 30 секунд вполне достаточно).

Введение

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

Такая вот ситуация: дизайнер присылает макет, а у верстальщика открывается какая то лабуда светлая, или темная (если верстальщик испольует МасOS, а дизайнер Win.). Или же верстальщик сохраняет картинку, а там цвета другие стали.

Разберемся почему так и как с этим жить.

О ssh и системных администраторах:

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

Вот здесь вот и начинается самое интересно:
одни системные администраторы запускают свои скрипты в несколько потоков, другие придумывают как отмазаться от части машин.

С 1 июля 2009 года общества с ограниченной ответственностью будут действовать на основании единственного учредительного документа – устава. Учредительные договоры обществ с 1 июля 2009 года утрачивают силу учредительных документов. Все ООО с момента регистрации обязаны вести список своих участников. В него войдет информация об учредителях, включая данные об их адресах, сведения о принадлежащих им долях и их оплате, данные о долях, перешедших к обществу.
Обществам с ограниченной ответственностью необходимо внести изменения в свой устав. Сделать это нужно не позднее 1 января 2010 года. Изменения в устав вступают в силу с момента регистрации. То есть в срок, установленный в законодательстве, нужно успеть не только внести изменения в устав, но и зарегистрировать их. Поскольку 1 января 2010 года – нерабочий день, окончание срока переносится на первый рабочий день года.

Изменения в законодательстве прежде всего коснулись содержащихся в уставе сведений:

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

Slow Lori — это животное, живущее в юговосточной Азии и известное своей медлительностью и размеренными движениями. По нему была названа новая DoS и DDoS атака на веб-сервер Apache.



Данный тип атаки был обнародован специалистом по безопасности RSnake 17 июня и подробно описан на странице http://ha.ckers.org/blog/20090617/slowloris-http-dos

Атака заключается в очень медленной посылке все новых и новых HTTP заголовков в рамках одного HTTP запроса, никогда его не завершая.

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

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

Что самое неприятное, Slowlori атака не оставляет никаких следов, кроме огромного количества открытых cоединений со статусом ESTABLISHED. Не будет никаких записей даже в access_log-е.

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

Веб-серверы основанные на state machine не подвержены данной атаке. Таким образом простейшим способом обезопасить себя от Slowlori атаки является использование двухуровневой архитектуры, когда первым на пути является веб\прокси сервер, основанный на state machine, такой как nginx.

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

Кроме собственно изменения архитектуры, разработчики Apache согласны в необходимости внедрения более мелких, локальных таймаутов. На данный момент в Apache 2.2 реализован один обший таймаут, влияющий на практически все IO действия.

Более подробную информацию можно получить в списке рассылки httpd-dev и в пока не открытой для публичного доступа статье на LWN.

Дано

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

Ситуация

Вы только что радикально переработали шаблон страницы (выровняли отбивки, поменяли цвета, прописали фоновые картинки). Получилось реально круто! Пора закачивать изменения на сервер. Вы запускаете FTP-клиента, перетаскиваете gif-ки и css-ки с левой панели на правую и, весь такой довольный, открываете вебсайт в своем любимом браузере…

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

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

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

Итак, разберем по частям регистрацию компании на примере общества с ограниченной ответственностью (ООО) на упрощенной системе налогообложения. В подробности вдаваться не буду, описания этого процесса можно найти, а вот некоторые нюансы можно узнать только из своего, блин, жизненного опыта. Подробнее:
Нужно подать документы в ФНС № 46 (список документов в яндексе). Мой совет — запишитесь на подачу, узнайте телефон (www.n46.ru) и запишитесь. Вы сэкономите кучу времени и нервов.
Через неделю вам отдадут документы в составе: 2 свидетельства, копии устава и учредительного договора, что-то еще и вот тут начинается самое интересное.

Поехали!

Готовим макет для клиента. Часть I: Гладить или нет?

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

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

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

Важно другое. Верхняя половина с шапкой из нереально синего неба, чрезмерно зелёной травки, блестящих хромированных небоскрёбов и пластмассовых людей с приклеенными улыбками — всё это очень нравится клиентам, и сами дизайнеры пузырятся от гордости, показывая подобные коллажики своим коллегам. А вот нижняя половина… Тут, в большинстве случаев, как раз всё очень и очень уныло.

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

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

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

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

Нет ничего лучше пассивного дохода, все это знают!

Разработка сайта — проект, это одно. Бюджет относительно высокий, но и трудозатраты значительные. Намного интересенее после завершения разработки сайта оказывать услуги по так называеммой «поддержки сайта».

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

Основной вопрос с которым может сталкнуться студия и в частности менеджеры, обслуживающие клиента это необходимость регулярно напоминать о себе и «создавать видимость» работы. Несмотря на то, что вы четно исполняете свои обязательства, обновляете контент, управляете почтой или что-то еще… когда вопрос доходит до платежа очень часто говорят «Ну а за что єто я плачу? Работі же не видно, да и как-то дорого!»

Если бы своевременно менеджер (раз в неделю), хотя бы писал письмо о том, что мы сделали тото и тото. «Пришлите нам свежие новости!», «как ваши дела?» ситуаций таких было бы меньше и колличество проектов на поддержку только увеличивалось.

Предлагаю составить список работ, таких как 1. обновление контента или 2. управление почтой которые на самом деле не составляют большого труда, но дают «плюс» к общей картине.

Буду рад хорошим комментам. Спасибо!