Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
Всегда было интересно. Вот в Японии люди работают почти 24/7/365… даже умирают от усталости на работе…
Наверняка в Японии есть софтверные конторы…
Но почему известно так мало программных продуктов, сделанных японцами?
Это из-за повернутости на внутренний рынок? Или из-за традиционной закрытости, когда каждая корпорация сама пишет софт для себя и ни с кем не делится… почему?
Или это просто так получилось, что я знаю кучу всемирно известных проектов из России, США, Австралии, Канады, Германии, Польши, и других стран а из Японии не знаю ни одного.
Наверняка в Японии есть софтверные конторы…
Но почему известно так мало программных продуктов, сделанных японцами?
Это из-за повернутости на внутренний рынок? Или из-за традиционной закрытости, когда каждая корпорация сама пишет софт для себя и ни с кем не делится… почему?
Или это просто так получилось, что я знаю кучу всемирно известных проектов из России, США, Австралии, Канады, Германии, Польши, и других стран а из Японии не знаю ни одного.
Мммм, Ruby?
Еще был архиватор ice :)
Японцы построили «зеленый» суперкомпьютер
Вот еще в копилочку, уже из нынешнего :)
Вот еще в копилочку, уже из нынешнего :)
Видимо дело в их закрытости. Основные направления разработки ПО заняли Штаты и японцы видимо сосредоточились на прикладном программировании для нужд своих корпораций. А то, что в Японии специалисты в области программирования есть и не слабые — можно судить по косвенным признакам.
Программа «компьютеры пятого поколения». была разработана в начале 80х японцами. Очень амбициозная программа была. По софтверной части упор делался на системах искусственного интеллекта. Японская корпорация NEC до недавнего времени была одним из лидеров суперкомпьютерного фронта. Просто мы действительно очень мало знаем об этой стране.
Программа «компьютеры пятого поколения». была разработана в начале 80х японцами. Очень амбициозная программа была. По софтверной части упор делался на системах искусственного интеллекта. Японская корпорация NEC до недавнего времени была одним из лидеров суперкомпьютерного фронта. Просто мы действительно очень мало знаем об этой стране.
Как минимум один японец в разработке PostgreSQL активно участвует. В других проектах тоже часто видел японские имена. Припоминаю, что для Emacs очень много библиотек и программ (например, почтовые клиенты mew и wunderlust) написаны японцами.
У Hudson/Jenkins CI разработчик японец.
Достаточно, но можно использовать софт, не зная о нём. Пример: самая используемая ОС в мире (2003 год).
Есть еще библиотека регулярных выражений Oniguruma и ставшая легендарной indie-игра Cave Story.
Вот в Японии люди работают почти 24/7/365… даже умирают от усталости на работе…Стереотип из разряда «в России по улицам медведи в ушанках и валенках с балалайками ходят пьяные».
Но почему известно так мало программных продуктов, сделанных японцами?Потому что большая их часть существует только на японском языке. Как пример — достаточно известный и популярный в определённых кругах графический редактор SAI. До 2008 существовал исключительно на японском, а переводом озаботились только потому, что фанаты не вытерпели и сделали сами.
У вас в тестрировании есть 2 особенности, одна нейтральная, а 2я — довольно сильно влияющая на результат.
1) При объёме памяти сервера 8гб и датасете 2гб — у вас идёт тестирование только эффективности распределения памяти внутри кэша, и совершенно нет нагрзуки на hdd. Всё, что только можно, будет браться из файлового кэша. Это вполне распространённый вариант нагрузки, но он только из многих — неплохо бы это указать. Как только объём данных превысит размен оперативной памяти — могут появиться совершенно неожиданные эффекты.
2) По размеру памяти под «прямой» кэш — вы даёте tyrant 2GB, оставляюю memcached дефолтные 64MB. И, получается, что для 1го вы тестируете прямую отдачу из внутренних буфферов, а для 2го — эффективность перекачки данных буфферы<->кэш ОС. Ай-ай-ай-ай.
1) При объёме памяти сервера 8гб и датасете 2гб — у вас идёт тестирование только эффективности распределения памяти внутри кэша, и совершенно нет нагрзуки на hdd. Всё, что только можно, будет браться из файлового кэша. Это вполне распространённый вариант нагрузки, но он только из многих — неплохо бы это указать. Как только объём данных превысит размен оперативной памяти — могут появиться совершенно неожиданные эффекты.
2) По размеру памяти под «прямой» кэш — вы даёте tyrant 2GB, оставляюю memcached дефолтные 64MB. И, получается, что для 1го вы тестируете прямую отдачу из внутренних буфферов, а для 2го — эффективность перекачки данных буфферы<->кэш ОС. Ай-ай-ай-ай.
В процессе работы Kyoto Tycoon постоянно сбрасывает обновления на диск. По окончании записи я рестартовал сервер и выполнял контрольное чтение — потерь данных не было. Если вы просмотрели все результаты тестов, я запускал и вариант с дефолтными настройками, которые достаточно скромны, говорить там о кэше памяти нельзя, и всеравно результат ухудшился не сильно и был заметно лучше, чем у MemcacheDB.
Я не про тест записи. Там они в одинаковых условиях. Я про тест чтения. Размер внутреннего кэша вы уменьшали только до 500MB, у memcachedb же:
-m in-memmory cache size of BerkeleyDB in megabytes, default is 64MB
-m in-memmory cache size of BerkeleyDB in megabytes, default is 64MB
А tokio по умолчанию съел у вас 400 мб — это, кстати, может оказать влияние на выбор, когда свободной памяти мало — vds и т.п.
Запустил с кэшем 64 мега — посмотрим :)
У меня не стоит задача расхвалить Kyoto Tycoon. Подвернулся случай пощупать этот софт, результаты показались интересными, решил поделиться. Если бы он проиграл MemcacheDB, я бы об этом тоже написал. Честное пионерское!
У меня не стоит задача расхвалить Kyoto Tycoon. Подвернулся случай пощупать этот софт, результаты показались интересными, решил поделиться. Если бы он проиграл MemcacheDB, я бы об этом тоже написал. Честное пионерское!
Сделал тест с msiz=64m — уравнял размеры кэша с дефолтным MemcacheDB
Результат:
— запись — 25 мин 43 сек
— чтение — 12 мин 26 сек
Т.е. всеравно скорости выше. Но оперативки он сожрал 400 Mb — в два раза больше.
Поэтому по оперативке — проигрыш, по скорости и размеру БД на диске — выигрыш.
Наверняка выигрыш по скорости и из-за более компактного хранилища — меньше дисковых операций.
Результат:
— запись — 25 мин 43 сек
— чтение — 12 мин 26 сек
Т.е. всеравно скорости выше. Но оперативки он сожрал 400 Mb — в два раза больше.
Поэтому по оперативке — проигрыш, по скорости и размеру БД на диске — выигрыш.
Наверняка выигрыш по скорости и из-за более компактного хранилища — меньше дисковых операций.
Во время теста, когда я рестартовал сервер с новыми параметрами и сразу начал слать ему данные — было потеряно порядка 16 тысяч первых записей.
Это без сообщения об ошибке что ли? Он принимал данные и тихо терял их? Если так, то вряд ли такую систему стоит использовать. Мало ли что она где затеряет…
Сообщения были. Функция сохранения данных возвращала код ошибки. Просто когда я запустил несколько тестов пакетом — отправил свой лог в /dev/null, чтобы диск не засорять. На последнем тесте чтения увидел ошибку, что считано меньше записей, чем сохранено. Прогнал еще пару тестов, уже с сохранением логов, и обнаружил причину.
Что то не понял я результатов :-\
сами по себе:
— Kyoto Tycoon — 18 мин 52 сек.
— MemcacheDB — 32 мин 39 сек
«Наперегонки»
— Kyoto Tycoon — 1час.
— MemcacheDB — 1 час 38 мин.
То есть Kyoto Tycoon отработал час, а потом MemcacheDB еще 38 минут дорабатывал?
Как же так, если он в одиночку делает импорт за 32 минуты?
сами по себе:
— Kyoto Tycoon — 18 мин 52 сек.
— MemcacheDB — 32 мин 39 сек
«Наперегонки»
— Kyoto Tycoon — 1час.
— MemcacheDB — 1 час 38 мин.
То есть Kyoto Tycoon отработал час, а потом MemcacheDB еще 38 минут дорабатывал?
Как же так, если он в одиночку делает импорт за 32 минуты?
В столь большом времени общего «забега» судя по всему была виновата возросшая дневная нагрузка на сервер. К сожалению абсолютно чистого сервера у меня не было.
В утренние часы я получал лучшие по времени результаты, ближе к вечеру — худшие.
Поэтому самые первые тесты я повторил несколько раз, в разной очередности и в разное время суток. А парный забег повторять не стал, поскольку тут они работали в одинаковых условиях.
кстати ни сколько не удивительно
memcacheDb базируется на berkeleyDB в качестве хранилища, ну и технология немного устарела
+ memcache в качестве буферного кеша.
Kyoto Tycoon — разработана современная компактная комбинированная hash/b-tree таблица. Скорость быстрее и время доступа меньше. Сам собираюсь использовать Kyoto Кабинет (чисто одно хранилище) в поисковых целях.
memcacheDb базируется на berkeleyDB в качестве хранилища, ну и технология немного устарела
+ memcache в качестве буферного кеша.
Kyoto Tycoon — разработана современная компактная комбинированная hash/b-tree таблица. Скорость быстрее и время доступа меньше. Сам собираюсь использовать Kyoto Кабинет (чисто одно хранилище) в поисковых целях.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MemcacheDB против Kyoto Tycoon — экспресс тестирование