Вероятно, да, я не знаю. Я употребил слово не задумываясь именно в таком значении, и мне казалось это значение естественным для русского языка. Возможно, это неправильно.
Проверки проводились с параметрами: NR=10, IR=20'000, ND=5, ID=10. Общее количество проверок для одного участника SUM=10'000'000
Меня смущает IR=20'000. Скажем, если в библиотеке реализовано кэширование на каком-либо уровне, она получит значительное преимущество.
Под кэшированием я понимаю что угодно, что ускоряет повторные прогоны: можно запоминать N последних результатов, можно кэшировать результат преобразования регулярного выражения из строки в более подходящую структуру данных, можно регулярное выражение представить в виде конечного автомата и запомнить его, можно скомпилировать регулярное выражение и сохранить результат компиляции.
Я не считаю такие оптимизации "нечестным преимуществом", кэширование и компиляция - отличные подходы. Но методология тестирования не учитывает, что скорость сопоставления строк с регулярными выражениями может драматически меняться в зависимости от того, повторяются ли регулярные выражения в процессе выполнения теста.
Независимо от конфигурации колес и их количества к каждому колесу подводится привод, все приводы вращаются с одинаковой угловой скоростью. По сути - жесткая связь с двигателем через редуктор.
Каждое колесо приводится во вращение через обгонную муфту. Быстрее привода вращаться можно, медленнее - нельзя.
Тогда на бездорожье грести будут все, и никакое вывешивание не снизит момент на колесах с зацепом. А на хорошем покрытии в поворотах толкать механизм будут внутренние колеса, остальные будут свободно вращаться быстрее приводов.
Из плюсов - предельная простота конструкции и ноль дифференциалов.
Проверил - к Меркурию лететь не имеет смысла. Для полета к Меркурию нужно погасить 7.5 км/с, а гравитационный маневр вернёт только 3 км/с максимум. Но к Венере лететь выгодно, нужно погасить 2.5 км/с, а разогнаться можно на 7.3 км/с.
Кстати, для полета к Юпитеру нужно 8.8 км/с, на Меркурий попасть все же проще. А вот чтобы на Солнце упасть, нужно 30 км/с погасить, в таком случае выгоднее лететь к Юпитеру и гасить скорость в афелии.
В исходном комментарии речь шла про то, как полететь как можно быстрее и как можно дальше. Думаю, как минимум быстрее и дальше Вояджера. А для этого нужно хорошо разогнаться, и просто разгоняться по прямой - не самое оптимальное решение. У химических двигателей сравнительно малое значение удельного импульса для этого (большой расход рабочего тела), у ионных двигателей - высокий расход энергии, которую негде брать, а еще куда-то тепло девать нужно, в космосе это не так просто.
И в итоге получается, что маршрут важен в том смысле, что должен максимально эффективно использовать гравитационные маневры, то есть, по сути, пролететь рядом с максимальным количеством планет. Статья на Википедии: https://ru.wikipedia.org/wiki/Гравитационный_манёвр
Вполне может оказаться, что энергетически выгоднее сначала полететь к Солнцу, посетить Меркурий, Венеру, Землю и остальные планеты, чем просто разгоняться двигателями. А это - не быстро, нужно учитывать огромные расстояния и взаимное расположение планет.
Очередь есть, без нее никак. Просто вместо отдельного сервиса это таблица в базе. Соответственно, из этой таблицы берут, там же обновляют статус и так далее. Пока что это отлично работает.
Что касается того, почему это не отдельный сервис:
У обработчика в памяти должна быть предпосчитанная вспомогательная структура, в случае с большими каталогами - несколько гигабайт. Поэтому взять задачу может не любой обработчик.
Обработчиков несколько, и каждый работает со своим каталогом, данные в оперативной памяти не дублируются.
В случае отключения или зависания обработчика его задачи по его каталогам должны перераспределиться на другие обработчики. Перед этим там считаются данные для каталога.
Задач относительно немного, и с таким набором требований оказалось проще самим написать логику очереди, чем использовать готовое решение. Когда эта часть станет узким местом, будем внедрять готовый MQ.
Соглашусь с вами. Велосипед не бесплатный, и его поддержка тоже не бесплатная. И лучше платить позже, чем раньше. Если честно, у меня тоже нет данных, чтобы сказать, что хуже, а что лучше даже применительно к нашему проекту. Просто поделился опытом, что такой подход тоже работает, а в небольших командах - хорошо работает, и не является источником каких-либо проблем.
Что касается отказа от очередей, решение не принципиальное - не нужны нам очереди, и все тут. Скорее ситуативное - пока нет необходимости, не усложняем. Увидим, что приплыли, пора - будем внедрять.
Просто в контексте стартапа это "приплыли" может и не наступить, и скорее всего - по причинам, которые никак не связаны ни с очередями, ни с микросервисами, ни с фреймворком для SPA.
Возможно, я не до конца корректно донес свою мысль. Кафка или условный MQ всем хороши, и на больших масштабах выиграют у велосипеда, я не сомневаюсь. Но пока у вас небольшая команда и нагрузка, с которой справляется велосипед - лучше простой велосипед для конкретной задачи в конкретных условиях. Но об ограничениях велосипеда нужно знать и помнить, безусловно.
А можете раскрыть чуть подробнее, в чем состоит заблуждение? Можете ссылкой, или сориентируйте, что гуглить. Без сарказма, я хочу лучше разобраться в этом.
Если что, под "предсказуемой памятью" я подразумевал следующее: нам нужно в памяти иметь дерево на, скажем, 100 миллионов узлов. Тогда мы точно знаем, сколько оно займет памяти, сколько из нее будет потрачено на ссылки, сколько - на непосредственно данные.
Что касается нагрузочного тестирования, то формально, с соблюдением процесса, мы его не проводили. А фактически - я знаю примерно, сколько запросов в секунду сервер может обработать, и узким местом является база. При тестировании производительности алгоритмов, которые работают в памяти, все хорошо.
Про пентесты - не понял, если честно. Речь про DOS с возможным повреждением памяти и выполнением произвольного кода? Но .NET - виртуальная машина, её задача - такого не допускать, и про такие атаки я не слышал. Мы же не на плюсах пишем.
Что касается джавы, то соглашусь отчасти. Все-таки .NET для веба лучше подходит по моему субъективному мнению, а C# как язык приятнее. Что касается тайпскрипта и пайтона, то у них преимуществ для решения наших задач я не вижу. Я реально много времени провел в DotTrace, и, боюсь, что в случае с пайтоном и тайпскриптом приемлемой скорости я бы не добился. В общем, сделайте скидку на то, что C# - мой основной язык, а с перечисленными вами у меня гораздо меньше опыта.
Добро пожаловать в мир WorldWide или корпоративных проектов, где 1000 одновременно работающих клиентов - просто ничто. Нет, не спорю, можно вертикально масштабировать систему и покупать всё более дорогое железо, чтобы поддерживать растущую нагрузку. А когда вы упретесь в пределы возможностей монолитных решений, то, надеюсь сообразите, что все эти брокеры сообщений и микросервисы придуманы вовсе не для того чтобы затруднить вам отладку.
Я думал, что вся статья об этом и есть. Что сначала нужно найти бизнес-модель, а потом - масштабироваться. Не наоборот. И что с поиском бизнес-модели и места на рынке микросервисы никак не помогают, а сложность вносят и ресурсы тратят.
Сначала клиенты и продажи, потом микросервисы и шины данных.
Хотел оставить подробный рассказ об этом для второй части. Если кратко, то бекапы делаются с самого первого дня в два разных места у разных провайдеров, и доступ к ним имеют разные люди.
Для миграций сами пишем скрипты по накатыванию. Потом, при обновлении версии, они накатываются на все базы клиентов. Код для этого мы тоже написали сами. Скрипты должны приводить схему к точно такому же виду, как у новой созданной через Entity Framework базы.
Задачи мы делим на небольшие автономные подзадачи, если это возможно. Продакшен обновляется несколько раз в день, поэтому все скрипты в большинстве своем - простые, и до этого протестированные разработчиком и на демо-сервере.
Когда что-то идет не так, пишем скрипт по откату. К счастью, такого опыта пока реально мало, ни одной базы мы пока что не убили. К несчастью, на этот случай нет четкого плана. Что-то типа "Откатим, если что. Если совсем все плохо будет, будем поднимать бекап".
Вероятно, да, я не знаю. Я употребил слово не задумываясь именно в таком значении, и мне казалось это значение естественным для русского языка. Возможно, это неправильно.
Меня смущает IR=20'000. Скажем, если в библиотеке реализовано кэширование на каком-либо уровне, она получит значительное преимущество.
Под кэшированием я понимаю что угодно, что ускоряет повторные прогоны: можно запоминать N последних результатов, можно кэшировать результат преобразования регулярного выражения из строки в более подходящую структуру данных, можно регулярное выражение представить в виде конечного автомата и запомнить его, можно скомпилировать регулярное выражение и сохранить результат компиляции.
Я не считаю такие оптимизации "нечестным преимуществом", кэширование и компиляция - отличные подходы. Но методология тестирования не учитывает, что скорость сопоставления строк с регулярными выражениями может драматически меняться в зависимости от того, повторяются ли регулярные выражения в процессе выполнения теста.
Мы комментируем статью про «бессмысленный и беспощадный» дифференциал.
Машина получится еще веселее и беспощаднее, это да.
А если так:
Независимо от конфигурации колес и их количества к каждому колесу подводится привод, все приводы вращаются с одинаковой угловой скоростью. По сути - жесткая связь с двигателем через редуктор.
Каждое колесо приводится во вращение через обгонную муфту. Быстрее привода вращаться можно, медленнее - нельзя.
Тогда на бездорожье грести будут все, и никакое вывешивание не снизит момент на колесах с зацепом. А на хорошем покрытии в поворотах толкать механизм будут внутренние колеса, остальные будут свободно вращаться быстрее приводов.
Из плюсов - предельная простота конструкции и ноль дифференциалов.
Проверил - к Меркурию лететь не имеет смысла. Для полета к Меркурию нужно погасить 7.5 км/с, а гравитационный маневр вернёт только 3 км/с максимум. Но к Венере лететь выгодно, нужно погасить 2.5 км/с, а разогнаться можно на 7.3 км/с.
Кстати, для полета к Юпитеру нужно 8.8 км/с, на Меркурий попасть все же проще. А вот чтобы на Солнце упасть, нужно 30 км/с погасить, в таком случае выгоднее лететь к Юпитеру и гасить скорость в афелии.
В исходном комментарии речь шла про то, как полететь как можно быстрее и как можно дальше. Думаю, как минимум быстрее и дальше Вояджера. А для этого нужно хорошо разогнаться, и просто разгоняться по прямой - не самое оптимальное решение. У химических двигателей сравнительно малое значение удельного импульса для этого (большой расход рабочего тела), у ионных двигателей - высокий расход энергии, которую негде брать, а еще куда-то тепло девать нужно, в космосе это не так просто.
И в итоге получается, что маршрут важен в том смысле, что должен максимально эффективно использовать гравитационные маневры, то есть, по сути, пролететь рядом с максимальным количеством планет. Статья на Википедии: https://ru.wikipedia.org/wiki/Гравитационный_манёвр
Вполне может оказаться, что энергетически выгоднее сначала полететь к Солнцу, посетить Меркурий, Венеру, Землю и остальные планеты, чем просто разгоняться двигателями. А это - не быстро, нужно учитывать огромные расстояния и взаимное расположение планет.
Мало кто знает, что Маяковский работал именно за таким монитором.
Очередь есть, без нее никак. Просто вместо отдельного сервиса это таблица в базе. Соответственно, из этой таблицы берут, там же обновляют статус и так далее. Пока что это отлично работает.
Что касается того, почему это не отдельный сервис:
У обработчика в памяти должна быть предпосчитанная вспомогательная структура, в случае с большими каталогами - несколько гигабайт. Поэтому взять задачу может не любой обработчик.
Обработчиков несколько, и каждый работает со своим каталогом, данные в оперативной памяти не дублируются.
В случае отключения или зависания обработчика его задачи по его каталогам должны перераспределиться на другие обработчики. Перед этим там считаются данные для каталога.
Задач относительно немного, и с таким набором требований оказалось проще самим написать логику очереди, чем использовать готовое решение. Когда эта часть станет узким местом, будем внедрять готовый MQ.
Спасибо, устраняем проблемы. Часть уже исправили, часть еще в процессе.
Спасибо. Я знал про эту возможность, но почему-то не пользовался. Попробуем на практике.
Спасибо за замечания, будем исправлять.
Вопрос с хостингом закрывает человек в ЕС.
Логи хранятся в sql базе данных, поскольку работа с ними производится через Entity Framework, СУБД может быть любой.
С этой подводной лодки я никуда не денусь, это мой проект, и все риски на мне, если что.
Думаю, в этом и заключается моя роль в проекте - понимать, когда и что пора делать по-человечески, чтобы не было слишком поздно.
Ой, Razor конечно. Не знаю, как прочитал прошлый ваш комметнарий, и почему Razor не увидел.
Ничего из перечисленного, олд скул: сервер генерирует html, на клиенте - jquery, пара плагинов, самописные скрипты.
Соглашусь с вами. Велосипед не бесплатный, и его поддержка тоже не бесплатная. И лучше платить позже, чем раньше. Если честно, у меня тоже нет данных, чтобы сказать, что хуже, а что лучше даже применительно к нашему проекту. Просто поделился опытом, что такой подход тоже работает, а в небольших командах - хорошо работает, и не является источником каких-либо проблем.
Что касается отказа от очередей, решение не принципиальное - не нужны нам очереди, и все тут. Скорее ситуативное - пока нет необходимости, не усложняем. Увидим, что приплыли, пора - будем внедрять.
Просто в контексте стартапа это "приплыли" может и не наступить, и скорее всего - по причинам, которые никак не связаны ни с очередями, ни с микросервисами, ни с фреймворком для SPA.
Возможно, я не до конца корректно донес свою мысль. Кафка или условный MQ всем хороши, и на больших масштабах выиграют у велосипеда, я не сомневаюсь. Но пока у вас небольшая команда и нагрузка, с которой справляется велосипед - лучше простой велосипед для конкретной задачи в конкретных условиях. Но об ограничениях велосипеда нужно знать и помнить, безусловно.
А можете раскрыть чуть подробнее, в чем состоит заблуждение? Можете ссылкой, или сориентируйте, что гуглить. Без сарказма, я хочу лучше разобраться в этом.
Если что, под "предсказуемой памятью" я подразумевал следующее: нам нужно в памяти иметь дерево на, скажем, 100 миллионов узлов. Тогда мы точно знаем, сколько оно займет памяти, сколько из нее будет потрачено на ссылки, сколько - на непосредственно данные.
Что касается нагрузочного тестирования, то формально, с соблюдением процесса, мы его не проводили. А фактически - я знаю примерно, сколько запросов в секунду сервер может обработать, и узким местом является база. При тестировании производительности алгоритмов, которые работают в памяти, все хорошо.
Про пентесты - не понял, если честно. Речь про DOS с возможным повреждением памяти и выполнением произвольного кода? Но .NET - виртуальная машина, её задача - такого не допускать, и про такие атаки я не слышал. Мы же не на плюсах пишем.
Что касается джавы, то соглашусь отчасти. Все-таки .NET для веба лучше подходит по моему субъективному мнению, а C# как язык приятнее. Что касается тайпскрипта и пайтона, то у них преимуществ для решения наших задач я не вижу. Я реально много времени провел в DotTrace, и, боюсь, что в случае с пайтоном и тайпскриптом приемлемой скорости я бы не добился. В общем, сделайте скидку на то, что C# - мой основной язык, а с перечисленными вами у меня гораздо меньше опыта.
Я думал, что вся статья об этом и есть. Что сначала нужно найти бизнес-модель, а потом - масштабироваться. Не наоборот. И что с поиском бизнес-модели и места на рынке микросервисы никак не помогают, а сложность вносят и ресурсы тратят.
Сначала клиенты и продажи, потом микросервисы и шины данных.
Хотел оставить подробный рассказ об этом для второй части. Если кратко, то бекапы делаются с самого первого дня в два разных места у разных провайдеров, и доступ к ним имеют разные люди.
Для миграций сами пишем скрипты по накатыванию. Потом, при обновлении версии, они накатываются на все базы клиентов. Код для этого мы тоже написали сами. Скрипты должны приводить схему к точно такому же виду, как у новой созданной через Entity Framework базы.
Задачи мы делим на небольшие автономные подзадачи, если это возможно. Продакшен обновляется несколько раз в день, поэтому все скрипты в большинстве своем - простые, и до этого протестированные разработчиком и на демо-сервере.
Когда что-то идет не так, пишем скрипт по откату. К счастью, такого опыта пока реально мало, ни одной базы мы пока что не убили. К несчастью, на этот случай нет четкого плана. Что-то типа "Откатим, если что. Если совсем все плохо будет, будем поднимать бекап".