[Moscow.pm] Асинхронная обработка: ActiveMQ и другие брокеры сообщений

[Михаил Монашёв]

Здравствуйте, Павел.

>> ОП> Такс, я тут пока забил на очереди и заморочился с MemcacheDB,
>> ОП> попутно сделал сравнение с MySQL для большей уверенности в
>> ОП> выборе:
>> ОП> http://phpsuxx.blogspot.com/2009/03/mysql-vs-memcachedb.html
>> ОП> (если у кого есть какие комментарии по поводу теста или пожелания
>> ОП> погонять это ещё в каком-то режиме, то велкам).
>>
>> ИМХО, второй и третий тест идентичны. Мускул вроде автоматом делает varchar из
>> char, если ширина столбща более 4-х символов.

ОП> Вроде, как раз наоборот -- конвертация идёт из коротких варчаров в чар:
ОП> "Before MySQL 5.0.3, VARCHAR  columns with a length less than four are
ОП> changed to CHAR."

Угу. Если 4 и меньше, то всегда будет CHAR, иначе VARCHAR. А чтобый на
больших длинах полей был CHAR надо при создании таблицы писать FIXED .

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

ОП> Как автоматизировать тесты с удалением, ещё не придумал.
ОП> Пока написал автоматические тест скрипты, чтобы гонять без моего
ОП> участия и прогнал на больших базах.

Да очень просто: 90 записей вставил, 10 удалил. И так в цикле.

У MyISAM есть одна нехорошая особенность. Если в ней есть удалённые
записи, то она заметно медленнее работает.

У  InnoDB  такого  свойства  нет.  И кстати MemcacheDB было бы неплохо
сравнить с InnoDB.

ОП> В итоге MemcacheDB отлично выдержал возрастание числа ключей с 2млн до
ОП> 75+ млн (база вышла в 39+ гб), сохранив скорость записи на уровне
ОП> 13.500 / секунду, а чтения на уровне 17 000 записей / секунду.

ОП> Итого, почти линейное масштабирование... По MySQL пока тесты не
ОП> провёл, в ближайшее время будут.

А ты не смотрел, как MemcacheDB скалится на несколько корок?

>>
>> ОП> В  итоге разница получилась довольно большая (все цифры в "записей
>> ОП> / секунду"):
>>
>> ОП> тип        чтение    запись
>> ОП> MySQL  3200      10 000
>> ОП> MchDB  18000     14000
>>
>> ОП> MySQL был следующей конфы: дефалтный Центосовый my.cnf, тип engine --
>> ОП> MyISAM + char вместо varchar в таблице + индекс по ключевому полю.
>> ОП> MemcacheDB: /memcachedb -p7777 -d -r -N -H $PATH/db -u root >
>> $PATH/debug.log 2>>&1
>>
>> ОП> Вполне мог накосячить в тестах, это мой первый опыт подобного
>> ОП> тестирования, так что жду критики :)
>>
>> Дефолтный  конфиг  мускула  не  имеет  смысла.  Конфиг каждого мускула
>> должен  писаться  под  его  конкретную задачу. В твоём случае нужно во
>> время  и  после  теста посмотреть на накопленную мускулом статистику и
>> потюнить конфиг. Уверен, цифры могут сильно измениться...
>>
>>
>> --
>>
>> С уважением,
>> Михаил Монашёв, SoftSearch.ru
>> mailto:postmaster на softsearch.ru
>> ICQ# 166233339
>> http://michael.mindmix.ru/
>> Без бэкапа по жизни.
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>





  

--

С уважением,
Михаил Монашёв, SoftSearch.ru
mailto:postmaster на softsearch.ru
ICQ# 166233339
http://michael.mindmix.ru/
Без бэкапа по жизни.