Параметр thread_cache_size играет немаловажную роль в производительности нагруженного MySQL-сервера. В некоторых случаях можно увеличить производительность на 30-50%.

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

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

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

Подробные инструкции, которые даются на code.google позволят вам:

• Сжать все многочисленные скрипты JS и стили CSS
• Соединить все полученные файлы в один JS и в один CSS
• Сжать полученные два файла в формат GZIP, который понимают почти все браузеры и умеют распаковывать на лету
• Прописать такой .htaccess, который заставляет браузеры кэшировать данные два файла

Всё это будет происходить при запуске единственного скрипта compress.php

Для примера, результат сжатия скриптов моего сайта:

• JS: сжато в gzip 26 698 B, сжато без gzip 95 796 B, было 120 147 B
• CSS: сжато в gzip 46 049 B, сжато без gzip 160 001 B, было 281 870 B

Получается, что экономия трафика составляет 329 270 B. Но основной выигрыш для скорости загрузки в том, что теперь загружается не 14 файлов, а всего 2 (а это намного быстрее, так как браузер не тратит время на запросы). Причём делается это один раз, а не динамически силами самого сервера (тем более, что не все сервера поддерживают подобное конфигурирование сжатия для экономии ресурсов процессора).

В итоге, получится:

<link rel="stylesheet" type="text/css" href="min/styles_1349888114.cssgz" />
<script src="min/all_1349888114.jsgz" /></script>

Оригинальный текст — что-то вроде сборника ссылок с минимальным комментарием и картинкой. Я постарался немного дополнить статью, поэтому это теперь не совсем перевод, а скорее «расширение» оригинала. P. S. Да простят меня уважаемые читатели за немного издевательские хабы.

Такое чувство, что люди уже запустили веб-сервер на основе всего, до чего только добрались их руки. Ниже список нескольких очень нестандартных подходов к выбору железа для сервера.

Spud: Веб-сервер, работающий на электричестве из картофеля

Нужны какие-нибудь комментарии? По-видимому они столкнулись с проблемой гниения картофеля.

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

На одном из проектов часто разворачивались/удалялись новые ноды в облаке, соответственно, появилась задача добавления/удаления новых хостов в Zabbix для мониторинга доступности и снятия статистики. Для саморазвития было решено использовать библиотеку zabbix API на питоне. Это был первый опыт написания скриптов, поэтому буду благодарен за отзывы и замечания по коду.

Как вы уже могли узнать, Instagram продается Facebook за $1 млрд. У многих возник вопрос: За что такие деньги? Кто-то на хабре сравнил это с бумом доткомов. Да только весь этот бум на одном Facebook и держится.

В течении двух лет CEO Instagram Kevin Systrom думал, как же монетизировать свое быстрорастущее детище, но так и не придумал. При том много раз просказльзывали слухи о его отказе в сделке с Facebook. Автоподсказчик Google уже давно выдавал первым вариантом к запросу «kevin systrom» фразу «Kevin Systrom net worth». Дела шли в гору и без Facebook.

Неделю назад они выпустили приложение на Android и продались Facebook за сумму с 9 нулями в долларах. Владельцы андроидов были рады:

Разработчики же, не очень: «Куда так топят? За что им платят? Я тоже так могу, там же ничего сложного и инновационного!» кричал каждый второй разработчик на Android / iOS.

Лично я ждал падения сервиса в день релиза приложения в магазине Google Play. Но этого не случилось. Количество зарегистрированных пользователей в первые 24 часа составило около миллиона человек. Немалая цифра, я вам скажу.

И как же команде из 9 человек удалось вытерпеть такой наплыв и не сломаться?

Добрый день, уважаемые хабрапользователи, несмотря на тенденцию падения Oracle в глазах системных инженеров и компаний заказчиков. Операционная система, теперь уже Oracle Solaris продолжает жить и радовать наш глаз.
Недавно столкнулся с вопросом оптимизации некоторых параметров TCP/IP стека. Данная тема показалась мне интересна, многим она может показаться уже избитый, а кого то познакомит с новыми интересными моментами настройки. Итак начнем…

Есть у меня серверок (да, да, именно серверок, сервером его назвать сложно). Железо старенькое (2 гига оперативы, AMD Athlon(tm) 64 Processor 3500+, програмный RAID). Админю я его сам, без особых навыков и познаний. Когда-то давным давно (больше года назад) поставил на него Debian 5.0 Lenny (это была вторая в жизни установка linux-системы, до этого ставил только Ubuntu на рабочий ноутбук) и панель управления ISPConfig3 по мануалу. Держу на нем несколько (штук 40) сайтов друзей и клиентов, Redmine, SVN и еще немного по мелочам.
Периодически все это безобразие падает (load average > 20), и приходится на сервере раз в пару часов перегружать apache или высасывать из пальца очередную попытку оптимизации. В общем полный раздрай и разруха. И вот в одну прекрасную субботу я подумал — а почему бы не решить вопрос раз и… И вот в общем.
Под катом — история убитых выходных + предыстория. Интересна в первую очередь мне, чтобы потом легко вспомнить что именно и зачем я ставил. Может быть интересна новичкам в интересном и нелегком (ох, ...) деле серверной оптимизации постепенным(!) переводом сайтов из-под Apache c его ModRewrite под Nginx (кстати, правильно это слово читается «энжинкс»меня поправили, Сысоев на конференциях не раз говорил, что название сервера стоит читать, как «энжин-икс», спасибо bayandin и DorBer ). Возможно, будет интересна более-менее опытным товарищам, оказавшимся в тех же условиях (Debian Lenny, ISPConfig3, слабое железо, несколько хороших, не сильно хороших и разных сайтов). И более опытным может быть интересно зайти, оставить пару комментариев.

Уважаемые жители Хабра!

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

Всё. На этом можно было бы статью закончить, так как эта аксиома повторяется из года в год на форумах и конференциях и кочует из текста в текст на всех технических ресурсах. Однако это ёмкое «Всё» не поясняет деталей. Ведь существует достаточно широкая прослойка программистов, движки и проекты которых справляются с задачей без мемкеша и шардинга. Но момент нагрузки приходит, и приходится разбираться.
Для таких людей я и разобрал на запчасти это универсальный ответ высоконагруженных проектов.
Ограничимся изучением системы для веба. Попросту говоря, на привычном обычном сайте. Используете ли вы готовую CMS, или уже выросли до каркаса, или написали «с нуля» код для нестандартного проекта – основными элементами процесса приёма-отдачи данных всегда будут одни и те же узлы. Я их рассмотрю с точки зрения «Где что можно закешировать».

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

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

Вступление

Продолжу цикл статей на тему «Apache 2.x под наблюдением. Мониторинг загрузки системы веб-сервером». Опять же под рассмотрением остается известный ранее[2] модуль Apache — mod_performance. На время написания этой статьи на сайте модуля[1] была выложена для доступа новая версия модуля — 0.2. Дальнейшее повествование в статье будет по принципу «Вопрос-Ответ».

Apache 2 под наблюдением

Вступление

Уже написано немало постов на просторах интернета, о мониторинге веб-сервера Apache. При вводе такой фразы, как «мониторинг нагрузки apache» в строке поиска Google, результаты поиска указывают на полезнейший модуль mod_status. А также о еще большей полезности этого модуля в сочетании с perl-расширениями. А если еще и немного пропатчить эти perl-расширения — то вообще супер система получается. Но настроив такую систему — системный администратор на этом, как правило, не останавливается, ему уже необходимо история нагрузки по серверу в целом, потом по каждому хосту, а далее и с точностью до скрипта. И чтоб потом сравнить можно было, а как раньше было, а как теперь нагрузка распределяется.
И вот здесь на помощь может прийти модуль для веб-сервера Apache — mod_performance.

Год назад, как участник академ. программы IBM, я прослушал курс IBM AIX 6 Jumpstart for UNIX Professionals в московском офисе IBM. Инструктор осветил большинство тем, чтобы опытный администратор Linux или UNIX сел за AIX и стал работать, а также рассказал основные положения линейки серверов IBM Power Systems. Как оказалось, это довольно интересные системы Enterprise уровня, которые предоставляют цельные бизнес системы, включающие в себя встроенные средства виртуализации, мониторинга, диагностики и т.д., которые поддерживаются и со стороны операционной системы.
Я не претендую на исчерпывающее описание архитектуры, статья — скорее экскурс в технологию, для общего развития.

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

Это вольный перевод моего поста из блога моей компании — о том, как я разгребал последствия хакерской атаки на наш сервер.

Если в двух словах — мой сервер взломали. Злоумышленник получил пароль к FTP-серверу и в течении почти 10-ти часов скачивал все, до чего дотянулись ручонки. То, как, собственно, был взломан сервер — отдельная история. Вкратце — хакер отправил фальшивый саппорт-тикет моему хостеру с просьбой помочь создать FTP-юзера. И хостер, в общем-то, повелся. Мало того, что создал юзера, да еще и дал ему админские права… Переписку хакера с хостером (мне удалось завладеть копией) я — если хабровчане захотят — выложу обязательно, это отдельная веселуха. А пока просто перечислю шаги, которые я предпринял, чтобы защитить свой сервер и ликвидировать последствия:

2147483647 (2³¹-1), число Мерсенна — максимально возможное значение для 32-битного целого числа со знаком, то есть самое большое целое число, которое можно записать в 32 бита.

Какое отношение это имеет к телефонным номерам? Как ни странно, самое прямое. Оказывается, немалое число американских программистов в целях оптимизации разрабатывают системы, где телефонные номера на сервере хранятся в виде 32-битных целых чисел. Таким образом, максимально возможный телефонный номер в США равняется (214) 748-3647, где 214 — это код Далласа. При внесении в базу данных большего числа, сохраняется максимально возможный номер 2147483647.

Скотт Гатри анонсировал у себя в блоге выпуск финальной версии Web Farm Framework Version 2.

Web Farm Framework – это дополнение к серверу IIS7, которое предназначено для быстрого создания веб-ферм, наполнения контентом, масштабирования, использования балансировщиков нагрузки и централизованного управления множеством серверов одновременно.

Во второй версии инструмента, согласно записи блога, добавлены следующие возможности:

• инструмент Workflow Builder для определения и планирования задач, которые должны быть выполнены на всех серверах;
• поддержка Windows Credential Store позволит сохранить полномочия администратора используемые для инспекции серверов в безопасном хранилище Windows Credential Store;
• поддержка сторонних балансировщиков нагрузки через расширения Web Farm Framework позволит интегрировать Web Farm Framework с аппаратными балансироващиками вместо использования модуля IIS Application Request Routing;
• улучшена поддержка операций с MSDeploy;
• улучшена поддержка задачи синхронизации большого количества файлов.

Дополнительную информацию по Web Farm Framework можно получить по следующим ссылкам:

• запись блога Скотта Гатри с описанием возможностей Introducing the Microsoft Web Farm Framework;
• замечания к выпуску Download the Web Farm Framework V2 Release;
• документация по Web Farm Framework 2.0;
• форум посвященный Web Farm Framework.

Загрузить финальную версию Web Farm Framework 2 можно по следующим прямым ссылкам: для x86 и для x64. Либо можно воспользоваться установкой через Web Platform Installer.

Несколько дней назад Джейсон Зандер (Jason Zander) написал в своем блоге о выходе Visual Studio 2010 SP1 Beta (ссылки ниже, в конце статьи). Я рад поделиться с вами, друзья, новостями о том, что SP1 Beta добавил возможность интеграции с IIS Express в Visual Studio. Для этой интеграции вам потребуется скачать IIS Express отдельно, после того как вы установите SP1 Beta. После загрузки и установки IIS Express вы получите возможность создавать веб-проекты и веб-сайты, использующие IIS Express вместо Cassini (веб-сервера, который используется в Visual Studio по умолчанию). Для того, чтобы узнать побольше о разнице между IIS Express и полноценным IIS или Cassini, пожалуйста ознакомьтесь с записью блога Скотта Гатри, ссылка на которую приложена в конце статьи. Visual Studio 2010 предлагает два варианта веб-проектов: проект Web Application Project (WAP) и проект Website. Вы можете использовать оба типа проектов с IIS Express.