Видимо у лент фатальный недостаток — их придумали не в фейсбуке. Зачем городить и поддерживать потом очередную самоделку. Не верится что будет особая экономия по сравнению с общепринятыми ленточными аппаратами.
Немного замечаний… У Вас в презентации заявлена неудачня цель — «мы ищем VC, но если что согласны и на акселератор» — это звучит как будто вы не определились чего хотите, да и из презентации непонятно самое главное для инвестора — сколько и зачем. Не очень понятна стадия продукта. Презентация как будто для живого пичта, где можно указывать на что обращать внимание, только с абзацами текста — на будущее имеет смысл переработать. На видео речь сливается с музычкой в фоне, не надо так )))
В целом у Вас имхо очень интересное направление с массой маркетинговых возможностей. Но без хотя бы очень приблизительных заявлений о том что геймификация даёт продавцу это всё пустая болтовня. Нужны хлёсткие факты — 20% юзеров переплачивают 20% при заказе, виральность и социальная активность в Х раз круче стандартной, трекшн повышается в разы, средняя «переплата» по больнице 15%! Рекламная активность увеличивает оборот продавца ой ой ой как… Продажная цена однодолларовых китайских товаров за счёт геймификации достигает 2-3-5 баксов… Если вы делаете мегакампании по привлечению юзеров и за счёт геймификации льёте существенный трафик на товары (в смысле если геймификация сильно повышает этот параметр по сравнению со стандартным маркетплейсом) — это аргумент Ну как сейчас модно говорить продукт должен быть секси. Иначе кроме того что юзеру прикольно княпать по кнопочкам (от чего продавцу ни холодно ни жарко) продавец не улавливает зачем ему становиться ещё в один маркетплейс, который не даёт заказов. А если даёт так об этом надо орать в презентации ))))
Если нет выгод для продавцов (т.е. нет причин полагать что вы сможете привлечь много клёвых продавцов экономическим потенциалом) — тогда инвестору надо показать что вы сможете привлечь/удержать стопицот пользователей дешевле чем в обычных шопах (что автоматически косвенно выгодно продавцам) — тогда интересно рассказать о повышенном трекшене, о длине сессий, о количестве кликов, о количестве социальных публикаций-лайков-итд.
Т.е. главная тема вопроса (как вам уже писали рецензенты) — что даёт геймификация кроме фана. Если она не повышает ни трекшн, ни цену, ни процент заказов, не улучшает воронку — то зачем оно? Если главная фишка снизить стоимость привлечения покупателя и вы будете придумывать классные акции провоцирующие социальную активность и брендинг (а маркетплейс лишь инструмент) — то акцент нужно делать на этом.
Надеюсь у вас сложится с акселератором и на выходе получим тот самый вкусный-вкусный продукт, удачи Вам!
Поиск соучредителя, который в будущем будет строить и оперировать бизнесом в целевой стране, куда у вас ещё нет права въезда — очень смело. Расскажите пожалуйста как именно искали и как собственно оценивали «профпригодность»
Датчик дыхания нужен только при частоте менее 60 остановок дыхания в час. Таким людям и с CPAP по большей части хорошо живётся. А вот от 200+ уже и датчик не нужен — остановки дыхания постоянно появляются соответственно можно постоянно стимулировать нерв. Время покажет как эта технология приживётся, но в нынешнем виде не слишком убедительно выглядит
Да, я неудачно выразился по поводу метаданных. Имелось в виду что для некой неизвестной базы с ODBC (проприетарная generic odbc ) драйвером можно получить базовый набор таблиц-видов-полей-типов не имея доступа к системным таблицам за счёт повсеместно поддерживаемого подмножества ANSI 92. Не скажу точно какие используются вызовы, если инетерсно гляньте кверилог от Database.NET у них «ОДБЦ кони в вакууме» хорошо реализованы.
И ещё совет — если Вы уже поддерживаете ODBC то лучше вместо выпадающего меню с выбором драйвера оставить текстовое поле для ConnectionString. Для большинства баз всё равно выбора драйвера недостаточно для корректной работы, и люди всё равно используют либо заранее созданные в системе профили типа «DSN=profile_db1_test_root», которые уже содержат выбор драйвера, либо более сложные строки с выбором драйвера, с дополнительными параметрами подключения. Даже если вы спрашиваете например логин и пароль в форме, то для ODBC подключения часто недостаточно передать эти данные параметром login/password, для некоторых баз их надо передавать параметром UID, для многих баз нужно передавать ещё выбор бинарного протокола и кодировок итд. Та же ДБ2 поддерживаемая в зависимости от CLOL/DBLOC настройки не заведётся по одбц одним выбором драйвера. В общем имхо упростите себе и пользователям жизнь если вместо выпадающего меню драйвера будет просто ConnectionString (ну или дополнительно к выбору драйвера, всё равно внутренне вы скорее всего превращаете выбор драйвера в стринг)
Ну это в общем так, слёзы задолбавшегося кодера легаси баз )))) Я догадываюсь что ОДБЦ не приоритетное направление развития, но надеюсь будут полезны замечания
Про ODBC имелось в виду работа с не перечисленными у вас базами, т.е. без обращения к специфичным служебным таблицам, а только за счёт стандартного подмножества ODBC комманд и ANSI SQL. Для экзотичных систем
Я глубоко не копал, но мне кажется если обращаться к информиксу через DB2 драйвер (для этого сервер баз должен быть настроен на поддержку соответствующего протокола), то он и метаданные отдаёт в идентичном DB2 формате. Если именно через информиксовский, то наверное Вы правы, придётся пилить.
Ещё имхо если возьмёте курс на расширения списка поддерживаемых баз имеет смысл добавить ODBC (для которого тоже есть ADO.NET поддержка). Тут конечно уже все-все метаданные не зная типа базы не получить, но хотя бы список полей таблиц, view и тому подобные базовые вещи работают на всём зоопарке баз.
Вообще инструмент получения структуры базы стабильно работающий с минимальными возможностями на широком спектре баз имхо весьма востребован. Мы в своё время покупали очень сырую и нестабильную Database.NET чтобы получить просто инструмент «быстрого взгляда» на произвольную базу. А если Вы планируете развивать продукт не только в сторону поиска связей но и в сторону скажем генератора отчётов по структуре базы или визуализации базы — тут вообще огромное поле, к примеру годами пользователи Nhibernate просят адекватный инструмент автогенерации биндингов по существующей базе
ЦРФИН и КРОУФР это просто сервис обсуждения спорных ситуаций. Никакой реальной власти не имеют, никакими регуляторами не являются, полностью подконтрольны своим организаторам. Приносят конечно определенную пользу трейдерам, но вообще их единственная задача создать видимость регуляции рынка, чтобы новичкам было не так стрёмно вливаться.
Чёт не припомню чтобы запретили бартерные операции и прямой обмен. Предлагаю запретить золото, алмазы, нефть как денежные суррогаты! Также люто запретим расписки и фразу «отвечаю, в понедельник верну»!
Логика железная — есть некая сущность, которую может производить или приобретать обменом любой анонимный персонаж. Во избежание «атата!» ни в коем случае не обменивайте эту сущность на деньги и не принимайте в оплату за свои товары и услуги! Ещё и упомянули курсовые риски и неподтверждённость цены ничьими обязательствами
Даёшь прессрелиз о недопустимости приёма картошки, сосновой стружки и физраствора в качестве платёжного средства!
1) Ещё была бы интересная фича искать в квери логе. У нас например легаси система в базе не прописано ни PK-FK ни ещё чего, 90% инфы о связях получаем из квери лога из запросов с джоинами.
Для реализации фичи нужно единожды для поддерживаемой базы узнать из какойсистемной таблицы можно селектом забрать квери лог и прицепить это дополнительным источником данных
2) Я бы в список поддерживаемых ещё добавил IBM Informix, она работает с уже поддерживаевым Вами драйвером DB2 и со своим собственным от IBM, оба ADO.NET compatible и в теории ничего пилить не нужно
Прям дежавю. Лет пять назад были аналогичные вопли «OMG вот это нежданка». Мол сижу я такой в зале с направленным на экран смартфоном, никого не трогаю. А тут кровавая гебня говорит что я наверное пират. Как они могли такое подумать? Ведь у телефона столько разных клёвых функций абсолютно необходимых мне кинотеатре, а эти козлы решили я экранку снимаю
Я, признаться, ничего не смыслю в ПРИ, но чем обусловлен выбор такого количества практически не имеющего потенциала переиспользования решений? Микроконтроллеры+обвязка это довольно сложная в освоении штука, создаваемые на их основе «девайсы» практически невозможно использовать вторично, а значит конечная стоимость будет весьма высока (даже если самое трудоёмкое — проектирование и софт — сделают энтузиасты за спасибо)
Разве не логичнее было бы основываясь на широко используемых технологиях или BYOD строить? Сейчас телефон со всеми необходимыми возможностями есть у большинства, сами телефоны полностью переиспользуемые и могут и выдаваться под залог и переиспользоваться на каждом следующем ивенте. Железо для организации WiFi покрытия стандартизовано, т.е. тоже может центрально переиспользоваться.
Таким образом имея некий стандартизованный софт (с широкими возможностями скриптинга возможно) я могу «залогиниться» в сеть ивента, получить сервисы позиционирования гпс/вайфай/нфц, полцчить централизованное хранение профиля/здоровья/ачивок, средство коммуникации, средство интеракции с другими игроками и неписями, ну и рай для мастеров и техов — всё как на ладони.
Вполне антуражно встретившись с противником пройти ритуал коннекта телефонами (удар). Сложновизуализируемые действия типа наложения спеллов без использования специнвентаря — реализуется на тачскрине. А при наличии инвентаря на помощь приходит Блутус — и посох в руке запросто может слать на телефон сигнал «кастую спелл номер 1», а уже телефон разрулит с оппонентом и центральным сервером какие будут эффекты, сколько здоровья и маны снимется итд итп. Позволит делать устройства весьма примитивными, а логику даже близкую к самому девайсу переносить в среду, где разработка значительно проще.
Ну а энтузиастов закодить на языке высокого уровня логику взаимодействий (которая на 80% реюзабельна благодаря параметризуемости настроек).
Насколько это далеко от реалий, почему никто не занимается такого рода платформами, на западе то ролевики уже много лет жаждют?
Насколько я знаю в Киеве в кол-центрах никто больше 400 долларов не получает даже с мегаусердной работой. Если меньше 800 жизни нет, то не очень понятно как они выживают
Ваш цикл статей изобилует полезной и интересной информацией о торговле валютами, но зачем подавать её в столь поляризованном виде я не понимаю. Вы освещаете абсолютно разные разделы сложной и глубокой темы, и действительно указываете на грани этих разделов, но равняете продукты по одной шкале, показывая как продукт категории X совершенно не оправдывает ожиданий категории Y или тех ожиданий, которые (как Вам кажется на него возлагает) потенциальный клиент.
Я совершенно с Вами согласен что текущий рынок «около Форекса» это «тоска-пичаль», но излишняя эмоциональность имхо скорее выставляет вас хейтером в глазах читателя и только мешает усвоению как материала так и критики.
Очень интересно слушать рассказ увлечённого любимым делом шеф-повара, знакомиться с тонкостями ресторанного бизнеса и вникать в нюансы общепита, а сколько там забавных историй из жизни… Но если эти рассказы обильно пересыпать охами и ахами о том как невозможно терпеть разруху, творящуюся в сфере фастфуда, «как мы тут с трюфелями мучимся а они там кошек подзаборных свежуют», то интерес к повествованию быстро угасает. Есть Мишлен, а есть шаурма, eсть BigMac, а есть FleurBurger.
Расскажите о рынке, о его структуре, почему ритейл форекс такой как есть. Хотите пройтись по кухням — расскажите откуда взялся MetaTrader, какие есть плагины для отлова стоплоссов, как именно кухни надувают трейдеров, как трейдеры обюманывают инвесторов, откуда деньги, как работает ритейл форекс в Европе, масса интересных тем и есть что песочить, и совсем не обязательно опускаться до «я Дартаньян»
Лично я буду рад прочитать следующую часть цикла и надеюсь в ней будет больше интересного и меньше бурления
Имхо нет особого смысла гнаться за «неявностью» предикатов. Ведь очень сложно (если вообще возможно) объеденить неявность и непросчитываемость условия.
А что мешает пересыпать код большим количеством явных но не просчитываемых условий, сформулированным таким образом чтобы мусор был то then, то в else ветке? Деобфускатор будет понимать что весь код обфусцирован/инструментирован и для каждого конкретного ветвления не сможет определить тру там или фолс. В мусоре будете генерировать дальнейшие ветвления которые будутт похожи на настоящие в абсолютной степени (так как нет требований по просчитываемости).
Если мусор будет не очевидно рандомным, а слегка модифицированным оригинальным кодом + оригинальный код также будет разбавлен мусорными включениями (нейтральными с точки зрения выполнения конечной функции), то деобфусцировать такой код, не будучи уверенным какие части графа достижимы а какие нет, будет весьма сложно
Уважаемый WapGraf,
вы проделали полезную и полагаю непростую работу, учитывая что железо не ваше. Но замеры проводились в не совсем корректных по сути условиях для подобного тестирования, что вносит значительную и совершенно непрогнозируемую погрешность в результаты. Очень сложно определить где заслуга/вина дисков, а где контроллера, где отработали буфера, а где железо. Где производительность достигнута грамотной буферизацией или полным write-back а где контроллер загнобил диски на random access, хотя потенциал был значительно выше, т.д. и т.п.
Основная проблема оценки производительности дисковой подсистемы в большом количестве слоев, где на каждом слое своя специфика — кеши, буфера, узкие места. Тестировать производительность сквозь все слои абстракции наобум можно конечно, но и результат вы получаете не претендующий на какую-либо точность — по сути лишь общее впечатление так сказать от практического использования.
Тестировать низкоуровневые вещи, работая с блочными девайсами и direcio можно, и получить высокой точностьи и репродуцируемости результаты легко. Но тут станет вопрос применимости этих показателей на практике. Ваш workload, реальная нагрузка ложащаяся на систему, как правило не соответствует тестовой и результаты снова не очень.
Поэтому для класса задач сравнения производительности (а не просто тестирования на посмотреть) принято или тестировать оба подхода, или использовать репродуцируемые тесты aka benchmark'и. Кроме того проф. сообщество обычно плохо относится к тестированию неспециализированным софтом, самопальными SQL запросами итд итп. Не столько потому что они априори плохие, а потому что эти тесты выхватывают лишь малую долю возможных ворклоадов и таком образом бесполезны для понимаия всей картины. Здорово знать что массив из дисков имеет XXX MByte/s на линейной перезаписи блоками по 4К и XX MByte/s на рандом чтении. Но не сказать чтобы это было хорошим параметром для сравнения. Кроме того много стандартных ворклоадов вываливается в массивный random access и критично важно знать что на 5k IOPS этот массив вообще вывалится в latency=5s и утянет за собой в iowait всю операционку. С базой приятно знать что как быстро делается выборка по ключу или синтетической нагрузке, но не зная какие будут результаты на 4, 8, 16 и 32 паралельных потоках эта информация не слишком полезна.
Если мерять перфоманс «в жизни» — из-под файловой системы, кеша в оперативке, дебиановского io шедулера, рейд-контроллера с неуказанымы настройками кешей, на диски с неуказанным объёмом кеша итд итп — то лучше использовать софт типа iozone и bonnie++. Он позволяет и быстро увидеть разницу производительности на cache-hit / cache-miss / buffer etc и стандартными замерами покрыть запись чтение перезапись перечтение рандомы итд итп
Если мерять низкоуровневую производительность с массой разных ворклоадов «из жизни» то пожалуй самой популярной утилитой будет IOmeter, на него есть масса готовых конфигураций на любой вкус.
Если интересуют результаты на разных обывательских ворклоадах (а-ля файлсервер, вебсервер, СХД итд итп) — тут полезен может быть Phoronix Test Suite — это фреймворк тестирования производительность с большим числом встроенных тестов. В том числе есть парочка неплохих для дисковой нагрузки
Если вы уже тестируете базу данных, то рекомендую использовать стандартные тесты индустрии — и замерять проще, и сравнивать легче, и результаты по разным ворклоадам достоверные и сравнимваемые. Есть тесты и в вышеупомянутом Phoronix Suite, есть очень уважаемые в индустрии TPC-H, TPC-D, TPC-*
В общем я бы вам рекомендовал в будущем оптимизировать подход к тестирвоанию — получите за то же время намного большерезультатов для аналитики и репродуцируемость для сравнения ну и полагаю хабру более достоверные данные прийдутся по вкусу.
P.S. тестируя диски в массивах всегда очень хочется видеть и тест одиночного диска, «на глазок» оценить прирост-потерю на контроллере
Это не сцен трекеры, раньше такого рода проекты называли «элитными трекерами», автор имеет в виду одобренные сценой трекеры исключительно для сценеров со всем вытекающим (инвайты через группу, секурность итд). Регулярно сайтопы разного калибра открывают свои трекеры с автоматикой добавления релизов и прочим блекджеком — для друзей, на продажу и ко — такие трекеры сцена тоже всячески «неодобрямс»
В целом у Вас имхо очень интересное направление с массой маркетинговых возможностей. Но без хотя бы очень приблизительных заявлений о том что геймификация даёт продавцу это всё пустая болтовня. Нужны хлёсткие факты — 20% юзеров переплачивают 20% при заказе, виральность и социальная активность в Х раз круче стандартной, трекшн повышается в разы, средняя «переплата» по больнице 15%! Рекламная активность увеличивает оборот продавца ой ой ой как… Продажная цена однодолларовых китайских товаров за счёт геймификации достигает 2-3-5 баксов… Если вы делаете мегакампании по привлечению юзеров и за счёт геймификации льёте существенный трафик на товары (в смысле если геймификация сильно повышает этот параметр по сравнению со стандартным маркетплейсом) — это аргумент Ну как сейчас модно говорить продукт должен быть секси. Иначе кроме того что юзеру прикольно княпать по кнопочкам (от чего продавцу ни холодно ни жарко) продавец не улавливает зачем ему становиться ещё в один маркетплейс, который не даёт заказов. А если даёт так об этом надо орать в презентации ))))
Если нет выгод для продавцов (т.е. нет причин полагать что вы сможете привлечь много клёвых продавцов экономическим потенциалом) — тогда инвестору надо показать что вы сможете привлечь/удержать стопицот пользователей дешевле чем в обычных шопах (что автоматически косвенно выгодно продавцам) — тогда интересно рассказать о повышенном трекшене, о длине сессий, о количестве кликов, о количестве социальных публикаций-лайков-итд.
Т.е. главная тема вопроса (как вам уже писали рецензенты) — что даёт геймификация кроме фана. Если она не повышает ни трекшн, ни цену, ни процент заказов, не улучшает воронку — то зачем оно? Если главная фишка снизить стоимость привлечения покупателя и вы будете придумывать классные акции провоцирующие социальную активность и брендинг (а маркетплейс лишь инструмент) — то акцент нужно делать на этом.
Надеюсь у вас сложится с акселератором и на выходе получим тот самый вкусный-вкусный продукт, удачи Вам!
И ещё совет — если Вы уже поддерживаете ODBC то лучше вместо выпадающего меню с выбором драйвера оставить текстовое поле для ConnectionString. Для большинства баз всё равно выбора драйвера недостаточно для корректной работы, и люди всё равно используют либо заранее созданные в системе профили типа «DSN=profile_db1_test_root», которые уже содержат выбор драйвера, либо более сложные строки с выбором драйвера, с дополнительными параметрами подключения. Даже если вы спрашиваете например логин и пароль в форме, то для ODBC подключения часто недостаточно передать эти данные параметром login/password, для некоторых баз их надо передавать параметром UID, для многих баз нужно передавать ещё выбор бинарного протокола и кодировок итд. Та же ДБ2 поддерживаемая в зависимости от CLOL/DBLOC настройки не заведётся по одбц одним выбором драйвера. В общем имхо упростите себе и пользователям жизнь если вместо выпадающего меню драйвера будет просто ConnectionString (ну или дополнительно к выбору драйвера, всё равно внутренне вы скорее всего превращаете выбор драйвера в стринг)
Ну это в общем так, слёзы задолбавшегося кодера легаси баз )))) Я догадываюсь что ОДБЦ не приоритетное направление развития, но надеюсь будут полезны замечания
Ещё имхо если возьмёте курс на расширения списка поддерживаемых баз имеет смысл добавить ODBC (для которого тоже есть ADO.NET поддержка). Тут конечно уже все-все метаданные не зная типа базы не получить, но хотя бы список полей таблиц, view и тому подобные базовые вещи работают на всём зоопарке баз.
Вообще инструмент получения структуры базы стабильно работающий с минимальными возможностями на широком спектре баз имхо весьма востребован. Мы в своё время покупали очень сырую и нестабильную Database.NET чтобы получить просто инструмент «быстрого взгляда» на произвольную базу. А если Вы планируете развивать продукт не только в сторону поиска связей но и в сторону скажем генератора отчётов по структуре базы или визуализации базы — тут вообще огромное поле, к примеру годами пользователи Nhibernate просят адекватный инструмент автогенерации биндингов по существующей базе
Даёшь прессрелиз о недопустимости приёма картошки, сосновой стружки и физраствора в качестве платёжного средства!
Для реализации фичи нужно единожды для поддерживаемой базы узнать из какойсистемной таблицы можно селектом забрать квери лог и прицепить это дополнительным источником данных
2) Я бы в список поддерживаемых ещё добавил IBM Informix, она работает с уже поддерживаевым Вами драйвером DB2 и со своим собственным от IBM, оба ADO.NET compatible и в теории ничего пилить не нужно
Разве не логичнее было бы основываясь на широко используемых технологиях или BYOD строить? Сейчас телефон со всеми необходимыми возможностями есть у большинства, сами телефоны полностью переиспользуемые и могут и выдаваться под залог и переиспользоваться на каждом следующем ивенте. Железо для организации WiFi покрытия стандартизовано, т.е. тоже может центрально переиспользоваться.
Таким образом имея некий стандартизованный софт (с широкими возможностями скриптинга возможно) я могу «залогиниться» в сеть ивента, получить сервисы позиционирования гпс/вайфай/нфц, полцчить централизованное хранение профиля/здоровья/ачивок, средство коммуникации, средство интеракции с другими игроками и неписями, ну и рай для мастеров и техов — всё как на ладони.
Вполне антуражно встретившись с противником пройти ритуал коннекта телефонами (удар). Сложновизуализируемые действия типа наложения спеллов без использования специнвентаря — реализуется на тачскрине. А при наличии инвентаря на помощь приходит Блутус — и посох в руке запросто может слать на телефон сигнал «кастую спелл номер 1», а уже телефон разрулит с оппонентом и центральным сервером какие будут эффекты, сколько здоровья и маны снимется итд итп. Позволит делать устройства весьма примитивными, а логику даже близкую к самому девайсу переносить в среду, где разработка значительно проще.
Ну а энтузиастов закодить на языке высокого уровня логику взаимодействий (которая на 80% реюзабельна благодаря параметризуемости настроек).
Насколько это далеко от реалий, почему никто не занимается такого рода платформами, на западе то ролевики уже много лет жаждют?
Я совершенно с Вами согласен что текущий рынок «около Форекса» это «тоска-пичаль», но излишняя эмоциональность имхо скорее выставляет вас хейтером в глазах читателя и только мешает усвоению как материала так и критики.
Очень интересно слушать рассказ увлечённого любимым делом шеф-повара, знакомиться с тонкостями ресторанного бизнеса и вникать в нюансы общепита, а сколько там забавных историй из жизни… Но если эти рассказы обильно пересыпать охами и ахами о том как невозможно терпеть разруху, творящуюся в сфере фастфуда, «как мы тут с трюфелями мучимся а они там кошек подзаборных свежуют», то интерес к повествованию быстро угасает. Есть Мишлен, а есть шаурма, eсть BigMac, а есть FleurBurger.
Расскажите о рынке, о его структуре, почему ритейл форекс такой как есть. Хотите пройтись по кухням — расскажите откуда взялся MetaTrader, какие есть плагины для отлова стоплоссов, как именно кухни надувают трейдеров, как трейдеры обюманывают инвесторов, откуда деньги, как работает ритейл форекс в Европе, масса интересных тем и есть что песочить, и совсем не обязательно опускаться до «я Дартаньян»
Лично я буду рад прочитать следующую часть цикла и надеюсь в ней будет больше интересного и меньше бурления
А что мешает пересыпать код большим количеством явных но не просчитываемых условий, сформулированным таким образом чтобы мусор был то then, то в else ветке? Деобфускатор будет понимать что весь код обфусцирован/инструментирован и для каждого конкретного ветвления не сможет определить тру там или фолс. В мусоре будете генерировать дальнейшие ветвления которые будутт похожи на настоящие в абсолютной степени (так как нет требований по просчитываемости).
Если мусор будет не очевидно рандомным, а слегка модифицированным оригинальным кодом + оригинальный код также будет разбавлен мусорными включениями (нейтральными с точки зрения выполнения конечной функции), то деобфусцировать такой код, не будучи уверенным какие части графа достижимы а какие нет, будет весьма сложно
вы проделали полезную и полагаю непростую работу, учитывая что железо не ваше. Но замеры проводились в не совсем корректных по сути условиях для подобного тестирования, что вносит значительную и совершенно непрогнозируемую погрешность в результаты. Очень сложно определить где заслуга/вина дисков, а где контроллера, где отработали буфера, а где железо. Где производительность достигнута грамотной буферизацией или полным write-back а где контроллер загнобил диски на random access, хотя потенциал был значительно выше, т.д. и т.п.
Основная проблема оценки производительности дисковой подсистемы в большом количестве слоев, где на каждом слое своя специфика — кеши, буфера, узкие места. Тестировать производительность сквозь все слои абстракции наобум можно конечно, но и результат вы получаете не претендующий на какую-либо точность — по сути лишь общее впечатление так сказать от практического использования.
Тестировать низкоуровневые вещи, работая с блочными девайсами и direcio можно, и получить высокой точностьи и репродуцируемости результаты легко. Но тут станет вопрос применимости этих показателей на практике. Ваш workload, реальная нагрузка ложащаяся на систему, как правило не соответствует тестовой и результаты снова не очень.
Поэтому для класса задач сравнения производительности (а не просто тестирования на посмотреть) принято или тестировать оба подхода, или использовать репродуцируемые тесты aka benchmark'и. Кроме того проф. сообщество обычно плохо относится к тестированию неспециализированным софтом, самопальными SQL запросами итд итп. Не столько потому что они априори плохие, а потому что эти тесты выхватывают лишь малую долю возможных ворклоадов и таком образом бесполезны для понимаия всей картины. Здорово знать что массив из дисков имеет XXX MByte/s на линейной перезаписи блоками по 4К и XX MByte/s на рандом чтении. Но не сказать чтобы это было хорошим параметром для сравнения. Кроме того много стандартных ворклоадов вываливается в массивный random access и критично важно знать что на 5k IOPS этот массив вообще вывалится в latency=5s и утянет за собой в iowait всю операционку. С базой приятно знать что как быстро делается выборка по ключу или синтетической нагрузке, но не зная какие будут результаты на 4, 8, 16 и 32 паралельных потоках эта информация не слишком полезна.
Если мерять перфоманс «в жизни» — из-под файловой системы, кеша в оперативке, дебиановского io шедулера, рейд-контроллера с неуказанымы настройками кешей, на диски с неуказанным объёмом кеша итд итп — то лучше использовать софт типа iozone и bonnie++. Он позволяет и быстро увидеть разницу производительности на cache-hit / cache-miss / buffer etc и стандартными замерами покрыть запись чтение перезапись перечтение рандомы итд итп
Если мерять низкоуровневую производительность с массой разных ворклоадов «из жизни» то пожалуй самой популярной утилитой будет IOmeter, на него есть масса готовых конфигураций на любой вкус.
Если интересуют результаты на разных обывательских ворклоадах (а-ля файлсервер, вебсервер, СХД итд итп) — тут полезен может быть Phoronix Test Suite — это фреймворк тестирования производительность с большим числом встроенных тестов. В том числе есть парочка неплохих для дисковой нагрузки
Если вы уже тестируете базу данных, то рекомендую использовать стандартные тесты индустрии — и замерять проще, и сравнивать легче, и результаты по разным ворклоадам достоверные и сравнимваемые. Есть тесты и в вышеупомянутом Phoronix Suite, есть очень уважаемые в индустрии TPC-H, TPC-D, TPC-*
В общем я бы вам рекомендовал в будущем оптимизировать подход к тестирвоанию — получите за то же время намного большерезультатов для аналитики и репродуцируемость для сравнения ну и полагаю хабру более достоверные данные прийдутся по вкусу.
P.S. тестируя диски в массивах всегда очень хочется видеть и тест одиночного диска, «на глазок» оценить прирост-потерю на контроллере