Dklab_multiplexor — это инструмент, который позволяет держать одновременно сотни тысяч долгоживущих открытых HTTP-соединений с сервером. Например, если на вашем сайте находится одновременно несколько сот тысяч посетителей, каждый из них может быть связан с сервером постоянным соединением, установленным из JavaScript. Это например, полезно при организации онлайн-чатов или мгновенных уведомлений.

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

Зачем это нужно?

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

Данную задачу можно решить двумя способами.

1. Неправильный способ. Раз в 10 секунд делать из JavaScript запрос на сервер для проверки, не появилось ли новых сообщений. Этот метод не работает, если на сайте одновременно находится очень большое количество пользователей, т.к. нагрузка на сервер растет слишком быстро. Кроме того, потребление трафика пользователем также оказывается крайне высоким.
2. Правильный способ. Устанавливать постоянное и длительное соединение с сервером, ожидая поступления данных через него. Если сообщений нет, соединение просто держится открытым на протяжение нескольких минут. Если соединение по каким-либо причинам закрылось, оно вновь открывается. В итоге и трафика потребляется мало, и нагрузка на сервер оказывается невелика. Так работает GMail, Мой Круг и т. д., и именно на этом принципе построен dklab_multiplexor.

+-------------------+                    ------------------ 
| Сервер обработки  |                   |                  |   <===WAIT=== Клиент A
| и базы данных     |  ======IN=======> |   Мультиплексор  |   <===WAIT=== Клиент B
| (e.g Apache + PHP |                   |                  |   <===WAIT=== Клиент C
+-------------------+                    ------------------ 
(указаны направления установления TCP-соединений).

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

Итак, описание алгоритма, который я использовал:

Люди не очень любят регистрироваться. Это же нужно (в общем случае) придумать логин и пароль, зайти в свою почту, дождаться письма, открыть его, перейти по ссылке активации аккаунта, а потом еще этот логин с паролем не забыть. Но ведь уже давно есть способ, с помощью которого все эти шаги не нужны. Более того, не нужно вообще ничего вводить с клавиатуры, 2 щелчка мышью и все, человек зарегистрирован.

Надеюсь, что данный материал будет кому-нибудь полезен.

Siege – это утилита для нагрузочного тестирования веб-серверов. Она была создана для того чтоб дать разработчикам возможность проверить ресурсоёмкость своего кода в условиях, максимально приближенных к реальным. Так же Siege может имитировать обращения к сайту сразу нескольких пользователей. Это позволяет держать сервер как бы «под осадой» долгое время. Количество запросов, произведённых при «осаде», рассчитывается из общего количества пользователей и количества их обращений к серверу. Например 20 пользователей, обратившись по 50 раз, создают в общей сложности 1000 запросов. Результат, выводимый программой после тестирования, включает в себя время затраченное на проверку, общее количество переданной информации ( включая заголовки ), среднее время ответа сервера, его пропускную способность и число запросов на которые пришёл ответ с кодом 200. Эти данные формируются и выдаются при каждой проверке. Подробно они описываются ниже. Siege имеет 3 основных модели работы – режим регрессионного тестирования, режим имитации Интернета и режим грубой силы. Программа считывает порцию ссылок из конфигурационного файла и обращается к ним по очереди ( режим регрессионного тестирования ) или случайно ( имитация интернета ). Или же пользователь может указать один единственный адрес к которому будут производиться все обращения – режим грубой силы.

UPD: спасибо за плюсы, перенес в тематический блог.

Понадобилось сделать несколько параллельных http запросов на php. Интуиция подсказывала что делается это через неблокируемые сокеты. В интернете в общем то есть несколько готовых классов для работы с ними, но как всегда захотелось легкости и простоты, поэтому был срочно изобретен новый велосипед. Под катом чуть больше 100 строк кода с комментариями и пример использования.

Не секрет, что пользователи любят, когда контент на сайте обновляется чаще, чем раз в год. Эту любовь пользователей к динамическим страничкам разделяют и поисковики. Google, например, умеет определять наличие обновляющихся блоков на страничке и добавляет ей немного кармы (читай, PR).

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

Отслеживая блоги про веб-разработку, я вдруг обнаружил, что все ждут выхода некоего php-5.3. Естественно, это не могло не заинтересовать меня как хостера. Я заглянул в список новых возможностей… Очень подкупила обратная несовместимость. Я вообще считаю, что не надо тащить всякую древнюю муть. На сайте анонсированы более 100 багфиксов, а это значит, что десятки новых багов не дадут мне соскучиться. И совершенно невозможно было пройти мимо долгожданного оператора goto. Я сначала посчитал это ошибкой. Мне показалось, что компании с названием «Дремучий Лес» остро необходимо иметь в своём активе язык с таким оператором.


Вы не поверите, но первый раз собирал php «руками». Раньше-то всё из портов FreeBSD ставил. Собирать новую разработку руками — это, естественно, мечта админа. Особенно в выходные.

Забавный эффект был, когда, провозившись полдня с экспериментальной поддержкой апача, который всё понимает и молчит, я плюнул на неё и собрал с обычной. Всё работает. Уже потирая руки, я вдруг вижу… нет, вы даже представить себе не можете… phpinfo() обрывается ровно на половине. За 7 лет такое первый раз. Вот хоть убей — половина и всё тут. Решение пришло ночью во сне. Как таблица Менделееву. Оказалось, что как-то криво поддерживается sqlite2. Утро убил на поиски как его оттуда вычленить, оставив поддержку sqlite3.

И вот — бинго! php-5.3 установлен на хостинге на радость страждущим нового.
Как и ко всему архиновому, к этому бы присовокупить сиськи, но к сожалению не нашёл. Вот так всегда, в урезанном варианте…

Итак, php 5.3 уже прямо сейчас. Вы можете опробовать новый драйвер MySQl Native Driver, функциональное программирование через замыкания (closures) и выход из них оператором goto в свой namespace

P.S. А кто-нибудь может мне подсказать, зачем нужен open_base_dir в варианте PHP_INI_ALL?..
P.P.S. Теперь всё зависит от сисек, только от них.

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

Memcached применяется для кеширования данных. Это делается для того, чтобы избежать лишних обращений к базе данных, т.е. в Memcached сохраняют результаты запросов. Это ускоряет работу сайта и уменьшают время выдачи страниц.
Кеш кроме преимуществ имеет свои недостатки. Одна из проблем кеша — это его актуальность. В режиме работы «только чтение» трудностей не возникает. Если же мы имеем дело с данными, которые изменяются, или изменяются часто, то эффективность кеширования резко падает.

Вступление. Эту статью написал мой друг — Семён Шторкин, владелец нижегородского сайта-коммьюнити для фотографов (фотогорький). Пока его, к сожалению, нет на Хабре, но попробую этим топиком заработать для него инвайт :)

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

Memcached community предприняло немало попыток написать «родные» патчи для кода memcached, добавляющие в него поддержку тэгов. Наиболее известный из таких патчей — проект memcached-tag. К сожалению, memcached-tag все еще очень далек от стабильной версии: нетрудно написать скрипт, приводящий к зависанию пропатченного memcached-сервера. Похоже, на момент написания данной статьи не существует ни одного надежного решения проблемы тэгирования на уровне самого memcached-сервера.

Библиотека Dklab_Cache

Dklab_Cache — это (в основном) библиотека поддержки тэгирования ключей для memcached, использующая интерфейсы Zend Framework. Сама библиотека написана на чистом PHP. Вот полный список возможностей библиотеки:

• Backend_TagEmuWrapper: тэги для memcached и любых других backend-систем кэширования Zend Framework;
• Backend_NamespaceWrapper: поддержка пространств имен для memcached и др.;
• Backend_Profiler: подсчет статистики по использованию memcached и др. backend-ов;
• Frontend_Slot, Frontent_Tag: каркас для высокоуровневого построения систем кэшиирования в сложных проектах.

Собственно, для поддержки тэгов имеется класс TagEmuWrapper. Он представляет собой декоратор («обертку») для backend-классов кэширования Zend Framework. Другими словами, вы можете с его помощью «прозрачно» добавить поддержку тэгов в любую подсистему кэширования Zend Framework. Мы будем рассматривать backend для работы с memcached: Zend_Cache_Backend_Memcached, но, если в вашем проекте используется какой-то другой backend-класс, вы можете подключить тэгирование и к нему без каких-либо особенностей.

TagEmuWrapper реализует стандартный backend-интерфейс Zend_Cache_Backend_Interface, поэтому с точки зрения вызывающей системы он сам является кэш-backend'ом. Вообще, Zend Framework хорош тем, что на уровне интерфейса он поддерживает тэги с самого начала! Например, в методе save() уже имеется параметр, позволяющий снабдить ключ тэгами. Однако ни один из backend-ов в составе Zend Framework тэги не поддерживает: попытка добавить тэг к некоторому ключу вызывает исключение (в частности, для Zend_Cache_Backend_Memcached).

Технические подробности, документацию, а также примеры использования можно посмотреть тут: dklab.ru/lib/Dklab_Cache

Что такое тэги?

Работа с типичной кэширующей системой (в том числе с memcached) заключается в выполнении трех основных операций:

• save($data, $id, $lifetime): сохранить данные $data в ячейке кэша с ключом $id. Можно указать «время жизни» ключа $lifetime; спустя это время данные в кэше «протухнут» и удалятся.
• load($id): загрузить данные из ячейки с ключом $id. Если данные недоступны, возвращается false.
• remove($id): очистить ячейку кэша с ключом $id.

Ни для кого не секрет, что работа с базой данных занимает большую часть работы практически любого сайта. И именно работа с БД чаще всего является узким местом веб-приложений.
В этой статье хотелось бы дать практические советы использования MySQL.
Сразу оговорюсь:

• данная статья написана про MySQL, хотя общие вещи скорее всего справедливы для любой СУБД.
• все написанное в статье является моей личной точкой зрения, и не является истиной в последней инстанции.
• советы не претендуют на новизну и являются результатом обобщения прочтенной литературы и личного опыта.
  
• в рамках данной статьи я не буду касаться вопросов конфигурирования MySQL.

Проблемы при использовании MySQL можно разделить на следующие три группы(в порядке значимости):

1. Неиспользование или неправильное использование индексов.
2. Неправильная структура БД.
3. Неправильные \ неоптимальные SQL запросы.

Остановимся на каждой из этих групп подробнее.

Многие разработчики используют Memcached, систему кэширования различных объектов в оперативной памяти. Устанавливается она очень просто

Вступление

Забавно, но когда программист разрабатывает какой-либо продукт, он редко задумывается над вопросом могут ли на одну кнопку в один момент времени нажать одновременно 2000 человек. А зря. Оказывается могут. Как ни странно но большинство движков, написанных такими программистами, очень плохо ведут себя под большими нагрузками. Кто бы подумал, а всего один лишний INSERT, не проставленный index, или кривая рекурсивная функция могут поднять load averages чуть ли не на порядок.

В этой статье я опишу как мы, разработчики проекта, сумели выжать из одного сервера с Pentium 4 HT / 512Mb RAM, максимум, держа одновременно 700+ пользователей на форуме и 120,000 на трекере. Да, проект этот — торрент трекер. Предлагаю сразу оставить в стороне разговоры о копирайтах и правах, мне это не интересно, что действительно интересно — это HighLoad.

Всем привет.

Боремся с пробками вместе

В рамках этого проекта в г. Красногорск, мы решили установить пару сетевых камер и сделать удобным просмотр потокового видео. Забегая вперед, результат можно посмотреть на нашем сайте или с мобильного телефона по wap www.ventumnet.ru/camera

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

На Хабре есть фишка связанная с ним, если в профиле ввести свой Twit-аккаунт, то последнее сообщение будет стоять у вас в статусе — мелочь, а приятно, не нужно делать одно и тоже дважды.

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

В техническом исполнении все оказалось не сложно.

Приветствую хабравчане!

Сегодня я хочу рассказать Вам свою историю и донести до общества текущие проблемы у одного из лидеров хостинга в России — "Хостинг Центра РБК".



Мое первое знакомство с «Хостинг Центром» началось еще в июле 2008-го года, тогда мне пришлось отказаться от выделенного сервера и искать альтернативы. Выбирал я долго и основательно. Остановился на 2х вариантах: Агава или ХЦ. Агаву я невзлюбил за почтовые фильтры и мой выбор пал на ХЦ, как на более популярного, а следовательно, надежного провайдера. Как оказалось, зря…

Update: Хабр — сила. Сегодня позвонил саппорт и предложил перенести VPS на другой сервер.

Уже давно использовал плеер производства http://flv-mp3.com/, который отличался простотой и элегантностью, но давеча получил письмо с новостью о выходе новой версии их замечательного плеера. Мое описание возможно покажется слишком эмоциональным, но это только потому, что плеер — Это бомба!

Прежде всего, демо-сайт — http://uppod.info/. После часа разборок с настройками, я могу заверить, что все фишки демосайта реализуются плеером на ура.

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

Надеюсь уважаемые комментаторы помогут дополнить список и выявить абсолютного лидера среди проигрывателей.
Уже помогли. Отдельные спасибы Elected, atri, rmb. Кармы всем за мой счет ^_^

Немного истории

Где-то в конце августа — начале сентября, постепенно понимая парадигмы объектно-ориентированного программирования и приходя в ужас от своего старого кода, я решил забыть Explay 2.1 как страшный сон и взялся писать все с чистого листа. Да, это, вероятно, было не самым лучшим шагом в сторону пользователей Эксплея, но вы уж извините мою глупую натуру.

Некоторые статьи вызывают оживлённые дискусии с сотнями коментариев, ветки которых занимают по два экрана на 1280х1024.

Например, вот на этом снимке экрана легко запутаться в уровнях коментариев.

Мне хотелось чтобы дерево коментариев было оснащено такими вертикальными линиями с минусиками к которым мы привыкли во многих современных редакторах. И я это сделал на выходных.

Сравните со снимком экрана после.