HandlerSocket — это noSQL-плагин для mySQL, позволяющий обращаться к базам данных в обход уровня SQL.

Данная статья предназначена для тех, кто успешно поставил HandlerSocket и php-handlersocket, а также столкнулся со скудным мануалом и странным поведением этого плагина для php.

Когда я ходил в детский сад, забывал раздеваться: сидел в раздевалке и думал о своем. Когда ходил в школу, я забывал портфель. Когда вырос, ситуация не улучшилась. Волей-неволей приходится приспосабливаться. Один из способов — не отвлекаться на остальное. На то, что волнует в данный момент. Иными словами, меньше волноваться. Вот три моих способа (о других как-нибудь потом, если вам понравятся эти).

Способ меньше волноваться №1: Отключите вторую линию

Не мог выбрать одну фотографию и вставил обе

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

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

Стоит ли вообще браться за JMeter

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

Составление сценария

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

В предыдущем посте про JMeter я описывал создание примитивного нагрузочного теста. При разработке более сложных сценариев не обойтись без отладки. К сожалению, в JMeter эта техника не совсем очевидна. Ниже на несложном примере покажу несколько приемов отладки тест-плана. Заодно продемонстрирую использование таких элементов, как HTTP Request Defaults, Regular Expression Extractor, If Controller и некоторых других.



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

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

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

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

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

Это не туториал, поэтому вот сразу окончательный вариант скрипта: www.webasyst.com/etc/ru/selfupdate-1 (скрипт index.php; ≈20 КБ).
Скрипт содержит класс selfUpdate, который выполняет обновление самого себя (скачивает обновленную версию файла index.php и заменяет ей работающую в текущий момент).

Под катом рассмотрим как устроен процесс обновления и какие могут возникнуть проблемы при обновлении.

Введение

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

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

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

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

Тем не менее, я решил собрать все частные позиции в один топик и опубликовать их в одном месте, а так же представить в качестве выступления со сцены 15-го июня в рамках Founder Showcase, проходящего в Сан-Франциско.

Одну из тем я подниму прямо сейчас. Это небольшой совет, который я чаще всего даю начинающим предпринимателям: «берите деньги на максимуме нормального уровня».

Вот что я имею ввиду.

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

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

На Хабре уже не раз и не два публиковались статьи о необходимости разрешить пользователю войти через Google/Twitter/Facebook и т.д. Собственно говоря, прогрессивное человечество давно решило, что требовать от пользователя придумывать логины и пароли — вчерашний день. В данной статье я хочу обсудить возникающие проблемы и способы их решения.

На Хабре много статей о завершённых проектах (стартапах), советов как стать успешным и как доделать игру. Мне, к сожалению, довелось поучаствовать и в нескольких незавершённых проектах.

Так вот, советы как завалить проект:

1) Если вам в проекте нужна графика, каждый человек в команде должен попробовать себя в роли художника. Если задание отдано одному художнику, всем обязательно нужно принимать участие в обсуждении результата, давать советы и вообще всячески помогать. Художнику при этом нужно постоянно перерисовывать и править, дабы угодить всем сразу. Вообще, демократия – лучший метод для решения всех задач в проекте.

2) Концепт не нужен, зачем тратить время? Главное, начать как можно быстрей писать код, а идеи и концепт обязательно придут в пути. Кто быстрей начнёт программировать, сможет забронировать самые интересные задания.

3) Очень важно менять существенные вещи примерно в середине проекта, а лучше несколько раз. Ведь нужно было срочно программировать, и выбрали не ту технологию, не тот способ, 3D графику вместо 2D.

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

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

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

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

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

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

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

Может кому будет интересно как «по-быстрому» провести нагрузочное тестирование своего веб-приложения.
Подробности под катом

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

Дано: таблица размером в несколько десятков гигабайт данных. Задача — изменить структуру таблицы.

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

В интернете достаточно много информации на данную тему, но, несмотря на это, многие обходят её стороной. Цель данного поста, разъяснить на пальцах основы взаимодействия с Memcached.

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

Введение

Восемь лет назад у меня была идея открыть сеть ресторанов быстрого здорового питания в городе Красноярске. Я достаточно долго проработал в сфере общепита, начиная от официанта, бармена, повара до помощника директора + было неплохое видение будущего бизнеса. При этом отсутствовали всего лишь знания и опыт в области предпринимательства и необходимые денежные средства. Мелочь :-) Но я был полон энтузиазма и намерения воплотить задуманное.