Основные принципы тестирования юзабилити веб-сайта

Basics of Website Usability Testing

With the development of web space and virtual services, methods of usability testing are constantly updated. Today we’d like to present the basic principles and ways of usability testing of websites.
http://blog.templatemonster.com/2011/09/14/usability-testing-basics/?utm_campaign=Mass+TM+Newsletter%3A2011-09-14&utm_medium=email&utm_source=rptaha%40yandex.ru

Cufon - Технология пользовательских шрифтов в Веб

Наверное большинство из веб-разработчиков хоть раз сталкивался с ситуацией, когда вынужден объяяснять заказчику что по дизайн-макету выполнить верстку в HTML или натянуть на движок со 100% совпадением - не получается (или крайне трудоемко). Причина - в большинстве случаев - шрифты. Господа дизайнеры очень любят предоставлять заказчкам навороченные "креативные" макеты, не имеющие под собой ни малейшего понимания как оно должно работать в интернет. Как правило, было два пути решения этой проблемы: использовать заголовки и пункты (меню) в виде картинок, либо использовать FLASH.
И вот появилась потрясающая технология CUFON, которая позволяет внедрять в код станицы пользовательские шрифты - т.е. при загрузке страницы, JAVA-скриптом подтягивается специально сгенерированный файл шрифта, который распознается абсолютно всеми броузерами с поддержкой Java.
Ссылки по теме:
https://github.com/sorccu/cufon/wiki
http://cufon.shoqolate.com/generate/

Лента про веб-дизайн

Стал читателем интереснейшего блога про веб-разработки "Лента про веб-дизайн". Респект автору!

Как работает mytop

В процессе разработки web-приложений периодически остро встает вопрос использования ресурсов системы и, в большинстве случаев, базы данных. Наиболее распространенное сочетание это Apache + MySQL + PHP. В данной статье речь пойдет о простой, но очень важной консольной утилите mytop. По сути это клон знакомой любому админу системной утилиты top. Mytop показывает текущее состояние mysql-сервера и использование ресурсов системы. Утилита следит за потоками MySQL -она подключается к серверу MySQL, периодически выполняя команды SHOW PROCESSLIST, SHOW STATUS и отображает сводные результаты, к которым можно применять различные фильтры.
Совместимость.
* Linux (2.2.x, 2.4.x)
* FreeBSD (2.2, 3.x, 4.x)
* Mac OS X
* BSDI 4.x
* Solaris 2.x
* Windows NT 4.x (ActivePerl)
Установка.
Утилита входит в состав большинства дистрибутивов серверных операционных систем (за исключением Windows 2003-2008, там используются свои утилиты для MSSQL). Тем не менее, можно установить mytop из дистрибутива: http://jeremy.zawodny.com/mysql/mytop/
Использование.
Запуск утилиты производится из консоли стандартым синтаксисом команды: mytop -u пользователь -p пароль -d база_данных
(Подробнее о дополнительных параметрах: http://jeremy.zawodny.com/mysql/mytop/mytop.html)
Экран Mytop разбит на 2 части.
Заголовок (верхние 4 строки) содержат суммарную информацию о состоянии вашего MySQL сервера. Он может выглядеть например так:
MySQL on localhost (3.22.32) up 3+23:14:20 [23:54:52]
Queries Total: 617 Avg/Sec: 0.00 Now/Sec: 0.05 Slow: 0
Threads Total: 1 Active: 1 Cached: 0
Key Efficiency: 88.38% Bytes in: 0 Bytes out: 0

• Первая строка: имя хоста и версия запущенного сервера MySQL. Верххний правый угол - аптайм сервера (время непрерывной работы) дней+часов+минут+секунд.
• Вторая строка выводит: общее количество обработанных запросов к базе, среднее количество запросов в секунду (производительность сервера), текущее кол-во запросов в секунду (реалтайм) и кол-во медленных запросов.
• Третья строка показывает информацию о процессах: всего, активных, кешированных. В версиях MySQL ниже 3.23.x эти ззначения остаются нулевыми (сервер не предоставляет такую информацию).
• Четвертая строка: сведения об эффективности буфера ключей - как часто MySQL находит ключи в буфере, не обращаясь к диску, среднее число байтов, посланных и полученных сервером, и число байтов, пересылаемых в данный момент.

Вторая часть экрана показывает все активные потоки (в том числе тот, который использует MyTop). Здесь выводятся в табличной форме имя пользователя, базы данных и узла, а также текущий запрос и состояние.
Id User Host Dbase Time Cmd Query or State
-- ---- ---- ----- ---- --- --------------
61 jzawodn localhost music 0 Query show processlist

С помощью данной утилиты легко "подсмотреть" кто и что используется сервер БД.

nginx (engine x) – отказоустойчивый HTTP сервер

nginx (engine x) — веб-сервер и почтовый прокси-сервер, работающий на Unix-подобных операционных системах (тестировалась сборка и работа на FreeBSD, OpenBSD, Linux, Solaris, Mac OS X).

http://sysoev.ru/nginx/

http://ru.wikipedia.org/wiki/Nginx

Основная функциональность HTTP-сервера:

• обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;


• акселерированное проксирование с кэшированием, простое распределение нагрузки и отказоустойчивость;


• акселерированная поддержка удалённых FastCGI серверов с кэшированием, простое распределение нагрузки и отказоустойчивость;


• модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно.


• поддержка SSL и расширения TLS SNI;

Популярность

По данным Netcraft за декабрь 2009 года, число сайтов, обслуживаемых nginx, превышает 15,5 миллионов ^[2], что делает его третьим по популярности веб-сервером в мире.

Как и lighttpd nginx часто используют для отдачи статического содержимого, генерируемого «тяжёлым» веб-приложением, работающим под управлением другого веб-сервера.

Следующие проекты используют nginx:

• Rambler


• Yandex


• Begun


• Wordpress.com


• Wrike


• SourceForge.net^[3]


• vkontakte.ru


• megashara.com


• Либрусек


• Taba.ru


• и многие другие.^[4]

Почему Apache — плохо?

(http://greenmice.info/ru/node/115,  http://greenmice.info/ru/node/116)

Для начала нужно объяснить, как вообще работают сетевые серверы. Те, кто знаком с сетевым программированием, знают, что по сути существуют три модели работы сервера:

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


2. Многопроцессная (многопоточная). Сервер открывает слушающий сокет. Когда приходит соединение, он принимает его, после чего создает (или берет из пула заранее созданных) новый процесс или поток, который может сколь угодно долго работать с соединением, а по окончании работы завершиться или вернуться в пул. Главный поток тем временем готов принять новое соединение. Это наиболее популярная модель, потому что она относительно просто реализуется, позволяет выполнять сложные и долгие вычисления для каждого клиента и использовать все доступные процессоры. Пример ее использования — Web-сервер Apache. Однако у этого подхода есть и недостатки: при большом количестве одновременных подключений создается очень много потоков (или, что еще хуже, процессов), и операционная система тратит много ресурсов на переключения контекста. Особенно плохо, когда клиенты очень медленно принимают контент. Получаются сотни потоков или процессов, занятых только отправкой данных медленным клиентам, что создает дополнительную нагрузку на планировщик ОС, увеличивает число прерываний и потребляет достаточно много памяти.


3. Неблокируемые сокеты/конечный автомат. Сервер работает в рамках одного потока, но использует неблокируемые сокеты и механизм поллинга. Т.е. сервер на каждой итерации бесконечного цикла выбирает из всех сокетов тот, что готов для приема/отправки данных с помощью вызова select(). После того, как сокет выбран, сервер отправляет на него данные или читает их, но не ждет подтверждения, а переходит в начальное состояние и ждет события на другом сокете или же обрабатывает следующий, в котором событие произошло во время обработки предыдущего. Данная модель очень эффективно использует процессор и память, но достаточно сложна в реализации. Кроме того, в рамках этой модели обработка события на сокете должна происходить очень быстро — иначе в очереди будет скапливаться много событий, и в конце концов она переполнится. Именно по такой модели работает nginx. Кроме того, он позволяет запускать несколько рабочих процессов (так называемых workers), т.е. может использовать несколько процессоров.

Итак, представим следующую ситуацию: на HTTP-сервер с каналом в 1 Гбит/с подключается 200 клиентов с каналом по 256 Кбит/с:

Что происходит в случае Apache? Создается 200 потоков/процессов, которые относительно быстро генерируют контент (это могут быть как динамические страницы, так и статические файлы, читаемые с диска), но медленно отдают его клиентам. Операционная система вынуждена справляться с кучей потоков и блокировок ввода/вывода.

Nginx в такой ситуации затрачивает на каждый коннект на порядок меньше ресурсов ОС и памяти. Однако тут выявляется ограничение сетевой модели nginx: он не может генерировать динамический контент внутри себя, т.к. это приведет к блокировкам внутри nginx. Естественно, решение есть: nginx умеет проксировать такие запросы (на генерирование контента) на любой другой веб-сервер (например, все тот же Apache) или на FastCGI-сервер.

Рассмотрим механизм работы связки nginx в качестве «главного» сервера и Apache в качестве сервера для генерации динамического контента:

Nginx принимает соединение от клиента и читает от него весь запрос. Тут следует отметить, что пока nginx не прочитал весь запрос, он не отдает его на «обработку». Из-за этого обычно «ломаются» практически все индикаторы прогресса закачки файлов — впрочем, существует возможность починить их с помощью стороннего модуля upload_progress (это потребует модификации приложения).

После того, как nginx прочитал весь ответ, он открывает соединение к Apache. Последний выполняет свою работу (генерирует динамический контент), после чего отдает свой ответ nginx, который его буферизует в памяти или временном файле. Тем временем, Apache освобождает ресурсы.

Далее nginx медленно отдает контент клиенту, тратя при этом на порядки меньше ресурсов, чем Apache.

Такая схема называется фронтэнд + бэкенд (frontend + backend) и применяется очень часто.

Настройка авторизации на web-сервере apache с помощью персональных SSL-сертификатов

Очень грамотная и технически развернутая статья (де-факто - руководство) по настройке авторизации на web-сервере с помощью персональных SSL-сертификатов.
Автор раскрывает проблему безопасности серьезных сайтов, при которой юзвери зачастую сами открывают дыры:

Не всегда авторизация на web-ресурсах по логину и паролю безопасна, к тому же при такой авторизации возникает необходимость заставлять пользователей использовать длинный и безопасный пароль, а не как это обычно бывает – «qwerty» или еще хуже просто «1″. Более безопасный способ это авторизация по персональным сертификатам и ключам, что мы и попробуем сделать.

Построение веб-сервера на базе кластерных решений

Отличный манул по построению Веб-сервера высокой нагрузки и с распределением этой самой нагрузки описан marchost.
Это howto по построению сервера высокой доступности с распределением нагрузки на базе 2 реальных серверов и технологий Xen, hearbeat и ldirectord. Кластер обеспечивает работу сервисов: http, mail, DNS, MySQL и обеспечивает полный мониторинг системы. Кластер реальный, работающий на некоторых хостингах - т.е. прошедший "полевые" испытания.

Краткий список сервисов, установленных на кластере:

* Apache
* MySQL + phpmyadmin
* Postfix (SMTP) и Spamassassin (управление через веб-интерфейс)
* Courier (IMAP & POP) и squirrelmail
* Bind (DNS server)
* Munin и monit для мониторинга через веб-интерфейс
* Самописные скрипты для мониторинга