Twisted или Tornado - без разницы - все идиоты

Внимание - Важное сообщение для блоггеров-питонистов!

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

Похоже, что уже всем стало ясно что "матч века" - Twisted.web против Tornado от Friendfeed показал, что ни одна из сторон не особо победила, но и не особо проиграла - и в тоже время стопудово - что обе стороны выглядят достаточно глупо.

Во-первых, Twisted. Сейчас моя компания использует его за небольшую часть функциональности, потому что ТОГДА - это был самый простой способ, что мы нашли для отправки трафика через различные сетевые интерфейсы на Linux машинах. Мы никогда не имели с ним никаких проблем. Единственная причина, по которой мне необходимо его когда-нибудь тронуть - это чтобы увидеть, как что работает.

Тем не менее, Twisted, вероятно, самая запарная программная библиотека. Каждый раз, когда я открываю этот код, я чувствую, что я забрел в ночной бар на берегу Джерси, где все пьяные в хлам и уже давно сорвали свои рубашки. Twisted классная библиотека, но в тоже время - НЕДОСТАТОЧНО классная, чтобы действительно называться "Twisted". Это Python- программистская версия одежды и бейсболок Ed Hardy, которая все еще висит в стороне (модная вещь, которая не используется). Когда я копался в этом коде и мои коллеги спрашивают меня, что случилось, единственным адекватным ответом было я "НЕ СЕЙЧАС, шеф - я запускаю этот хренов реактор ".

Теперь вы можете понять, почему появилась и существует такая хрень, как Tornado.

Хотя я постоянно не рекомендую делать такие вещи как Tornado - Friendfeed все-таки ее сделали. Из тех графиков, которые я видел, Tornado просто незначительно быстрее, чем Twisted на обслуживании большого количества одновременных запросов. НЕЗНАЧИТЕЛЬНО. Очевидно, в Friendfeed полагали, что достаточно небольшая разница в скорости была достаточным основанием тратить свое время и что-то переписывать заново- что обычно и делает каждый разработчик, которому становится скучно на работе. Веб-фреймворк на Python? О боже - как это оригинально! Я думаю, что это один из последних уроков книжки "Изучи Python за 24 часа".

В Friendfeed потратили много времени, пытаясь оптимизировать количество запросов в секунду, отображаемого на графике, но, возможно, им следовало бы тратить больше времени на оптимизацию ВОТ ЭТОГО графика - вместо первого:

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

Достаточно вольный перевод вот этой заметки. Спасибо автору

Кстати, достаточно интересно пишет, хотя и многие слова приходится долго думать - перед тем как перевести на русский.

Как избавиться от залипающих клавиш в VmWare vSphere Console для Linux Guest?

Возможно, вам знакома эта проблема...

Вы залогинены в vSphere клиент, у вас открыта Linux консоль виртуалки и когда вы что-то печатаете в ней - вместо одного символа появляются несколько одинаковых. Если честно - безумно раздражает, особенно когда нужно что-то сделать БЫСТРО на удаленной машине.

Если описать суть проблемы вкратце - по причине сетевых задержек клиент думает, что вы нажимаете клавишу несколько раз - и, соотвественно, посылает несколько сигналов терминалу - клавиша как бы "залипает".

Вот тут рецепт как это сделать, правя .vmx файл, но я предпочитаю делать это прямо в клиенте vSphere.

• Входим в клиент и "застреливаем гостя" (с) ;-)  "Shut Down Guest" (прости, друг ;-) )
• Клик на "Edit Settings"
• Выбираем вкладку "Options"
• В списке под "Advanced" выбираем "General"
• Справа нажимаем кнопку "Configuration Parameters"
• Клик на "Add Row"
• Вписываем имя новой переменной "keyboard.typematicMinDelay" и значение "2000000"
• Перезагружаем виртуалку

Теперь вы сможете Войти как "root", вместо "rrrroooooott". ;-)

Весьма вольный перевод вот этой заметки, спасибо автору.

Как оптимизировать сервер? - реальные данные - теория без практики мертва

Это судьба - вслед за вчерашней заметкой про оптимизацию выделенного сервера на сайте были опубликованы весьма интересные материалы, которые привели к росту просмотров страниц на 54 тысячи - это составляет рост примерно 140%.

Итак, график LI

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


Трафик, прокачанный через firewall - разумеется, вырос, причем - значительно



Процессы и потоки - увеличились

MySQL немного изменился в пределах погрешности; коннекты - не изменились.





Memcache немного подрос, но незначительно


А самое главное - ЦПУ и Load Average практически не изменились

Вывод

nginx с кешом HTML страниц сильно спасает от резких скачков нагрузки от незарегестрированных пользователей.

Рискну предположить, что создатели многих супер-пупер-мега-стартапов, постоянно падающих от пресловутого великого и ужасного Хабраэффекта, об этом не знают ;-)

З.Ы. Люблю, когда теоретические выкладки подтверждаются практическими данными.

Как настроить сервер? или оптимизация сайтов на PHP (Nginx, PHP, MySQL, Memcache)

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

Если же вы еще и не профессиональный HighLoad Linux-админ, а, например, разработчик (как я), то в процессе настройки прийдется ловить много-много граблей...  ;-)

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

Ниже рассматривается достаточно часто встречаемая комбинация для сайтов: nginx + php (nginx+apache c php немного отличается - вместо fastcgi_xxx будет proxy_xxx).

Да, и считаем, что сейчас все компоненты вашей системы (nginx, php, mysql, memcache) крутятся на одной машине - как оно обычно и бывает на частных ресурсах.

PHP

• Пускаем как fastcgi через сокет
• Pconnect к базе - спорно
• Не забываем акселератор (моя юзает eAccelerator) - хотя тоже есть спорные моменты

eAccelerator

Только для production машин можно отключить проверку Modified time - это абсолютно не подходит, если на сервере идет отладка скриптов - иначе будете ловить постоянные глюки и проблемы - включать только после того как сайт стал стабилен.

eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="0"
eaccelerator.shm_only="1"

Временые диски

tmpfs для /tmp и сессий PHP - все это сносится в память, если ее достаточно. В /etc/fstab добавляем

tmpfs                   /tmp                    tmpfs   defaults        0 0
tmpfs /var/lib/php tmpfs size=200M,nr_inodes=1m,nosuid 0 0

MySQL

• Проверяем, включен ли query кэш
• Также используем сокет
• Если в вашей CMS используется таблица сессий - ставим для них тип MEMORY (если нет текстовых полей) - это приведет к сбросу всех залогиненных пользователей при перезагрузке сервера, но добавит немного скорости. Ну или если это неприемлемо - то надеюсь, она уже переведена в InnoDB? ;-)
• Определяем оптимальное количество коннектов - статистика хотя бы за месяц (я юзаю munin). Ставим в 1.5-2 раза больше среднего.

Более подробно про оптимизацию MySQL можно прочитать тут.

Memcache

Если вся солянка крутится на одной машине - то также используем коннект через сокеты (по умолчанию не используется - стоит ip адрес). В таком варианте работы memcache возможны проблемы с некоторыми средствами мониторинга memcache (которые работают также по IP).

Не забываем в PHP использовать сжатие при работе с MEMCACHE.

Nginx

Ограничиваем число коннектов и запросов, особенно на ресурсоемкие скрипты

http {
...
    limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;
    limit_zone three $binary_remote_addr 10m;

Включаем кэширование для неавторизованных гостей

http {
...
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=wholepage:50m inactive=15d max_size=5000m;
        location ~ .*\.php$ {
            limit_conn three 20;
            include         /etc/nginx/fastcgi.conf;
            fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_pass    unix:/var/run/php-fastcgi/php.socket;
            #access_log  /var/log/nginx/domain.access.log  my_combined;
            fastcgi_cache wholepage_guest;
            fastcgi_cache_valid 301 302 304 10m;
            fastcgi_cache_valid 200 360m;
            fastcgi_cache_valid 404 5s;
            fastcgi_cache_key "$request_method|$host|$request_uri";
            fastcgi_pass_header "Set-Cookie";
            fastcgi_ignore_headers "Cache-Control" "Expires";
            fastcgi_cache_bypass $cookie_phpbb_session $arg_nocache $arg_PHPSESSID;
            fastcgi_no_cache $cookie_phpbb_session $arg_nocache $arg_PHPSESSID;
    }

Где phpbb_session - имя куки по которой идет авторизация

Все запросы с ?nocache=1 и PHPSESSID попадают на PHP-бэкенд сразу без кэша не забываем открыть скрипт, по которому идет авторизация (в том числе и всякие капчи - их можно переписать на ?nocache=1) - тут возможно прийдется немного поковыряться и в коде CMS тоже.

        location /register.php {
                limit_conn three 20;
                include         /etc/nginx/fastcgi.conf;
                fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_pass    unix:/var/run/php-fastcgi/php.socket;
        }

Nginx - общие рекомендации

Очень нежелательно использовать location с регекспами - только простые префиксы вида

location /mymodule {}

Если от регекспов никак не избавится - то лучше их обрамлять простым location (Причина - сложноуловимые перехлесты в логике парсинга URL - кто за кем будет следовать)

location /mymodule {
  location ~ \/mymodule\/(.*)\.php$ {
    чего-то
  }

}

Отрубаем access лог для картинок

Разумеется - это только основные моменты оптимизации, на самом деле их гораздо больше. А какие трюки для уменьшения нагрузки на сервер знаете вы? Пишите в комментах.

Как удалить MacPorts?

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

После 2 дней попыток обойти все баги перекомпиляции MacPort, решил их снести к чертовой матери и попробовать собрать все начисто.

Итак, как удалить MacPorts?

# port -f uninstall installed

После чего ставлю/собираю заново то, что нужно - пока "коробочка жужжит" (с) ;-)

Если же нужно вычистить всю жизнедеятельность MacPorts из системы, то

$ sudo rm -rf /opt/local \
    /Applications/DarwinPorts  /Applications/MacPorts \
    /Library/LaunchDaemons/org.macports.* /Library/Receipts/DarwinPorts*.pkg \
    /Library/Receipts/MacPorts*.pkg /Library/StartupItems/DarwinPortsStartup \
    /Library/Tcl/darwinports1.0 /Library/Tcl/macports1.0 \
    ~/.macports

Да, если у вас вторая версия - то удаляемые каталоги, разумеется, меняются на те, что у вас. 

Найдено тут, HomeBrew ставить не собираюсь. ПОКА не собираюсь, во всяком случае.

Как сохранить/восстановить настройки-сайты/Sites в Panic Coda под MacOS?

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

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

~/Library/Preferences/com.panic.Coda.plist

Где ~/ ваш домашний каталог.

P.S. И да, принимаю поздравления с долгожданным новым Pro 13' (MD314RS/A). Теперь Aperture ведет себя вполне прилично - и даже матрица нормальная, без цветовых искажений ;-) ;-)

/me почти счастлив ;-)

Skyrim: The Dragonborn Comes - Female Cover by Malukah

Уж на что я обычно спокойно отношусь ко всяким фэнартам и прочему user-generated контенту "по мотивам" чего-бы-то-не-было... но вот эта девушка сильно зацепила.



Our Hero, our Hero, claims a warrior's heart
I tell you, I tell you, the Dragonborn comes
With a Voice wielding power of the ancient Nord art
Believe, believe, the Dragonborn comes

It's an end to the evil of all Skyrim's foes
Beware, beware, the Dragonborn comes
For the darkness has passed and the legend yet grows
You'll know, you'll know, the Dragonborn comes

Dovahkiin, Dovahkiin
Naal ok zin los vahriin
Wah dein vokul mahfaeraak ahst vaal
Ahrk fin norok paal graan
Fod nust hon zindro zaan
Dovahkiin, fah hin kogaan mu draal