Проверил - к Меркурию лететь не имеет смысла. Для полета к Меркурию нужно погасить 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 базы.
Задачи мы делим на небольшие автономные подзадачи, если это возможно. Продакшен обновляется несколько раз в день, поэтому все скрипты в большинстве своем - простые, и до этого протестированные разработчиком и на демо-сервере.
Когда что-то идет не так, пишем скрипт по откату. К счастью, такого опыта пока реально мало, ни одной базы мы пока что не убили. К несчастью, на этот случай нет четкого плана. Что-то типа "Откатим, если что. Если совсем все плохо будет, будем поднимать бекап".
Сайт (и мобильную версию, и десктопную) делал я, так что вопрос по адресу. Я купил готовый шаблон в соответствии со своими представлениями о его функциях и удобстве, и немного адаптировал его для нашего содержания. Я же тестировал его на доступных мне телефонах. Плашка и размер текста тоже немного смутили, но критичной проблемы не увидел, поэтому оставил. Все-таки, профессиональные дизайнеры делали. В общем, спасибо за отзыв, подумаю, как это можно исправить и сделать лучше.
Для этого есть интеграции с другими системами. Остатки мы можем забирать из API маркетплейсов, выгружать из 1С, забирать из произвольных файлов в соответствии с тем, как это настроил пользователь. Например, типичный случай: продавец не весь ассортимент держит у себя на складе, часть - берет у поставщиков или партнеров. Те регулярно присылают ему на почту файл с информацией, что у них есть, в каком количестве, по какой цене. Наша система автоматически проверяет почту, разбирает новые файлы и обновляет информацию о ценах и наличии товаров. Я бы не сказал, что это именно складской учет, он сложнее. Скорее - единое окно для работы с максимумом доступной информации.
Проверил - к Меркурию лететь не имеет смысла. Для полета к Меркурию нужно погасить 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 базы.
Задачи мы делим на небольшие автономные подзадачи, если это возможно. Продакшен обновляется несколько раз в день, поэтому все скрипты в большинстве своем - простые, и до этого протестированные разработчиком и на демо-сервере.
Когда что-то идет не так, пишем скрипт по откату. К счастью, такого опыта пока реально мало, ни одной базы мы пока что не убили. К несчастью, на этот случай нет четкого плана. Что-то типа "Откатим, если что. Если совсем все плохо будет, будем поднимать бекап".
Сайт (и мобильную версию, и десктопную) делал я, так что вопрос по адресу. Я купил готовый шаблон в соответствии со своими представлениями о его функциях и удобстве, и немного адаптировал его для нашего содержания. Я же тестировал его на доступных мне телефонах. Плашка и размер текста тоже немного смутили, но критичной проблемы не увидел, поэтому оставил. Все-таки, профессиональные дизайнеры делали. В общем, спасибо за отзыв, подумаю, как это можно исправить и сделать лучше.
Для этого есть интеграции с другими системами. Остатки мы можем забирать из API маркетплейсов, выгружать из 1С, забирать из произвольных файлов в соответствии с тем, как это настроил пользователь. Например, типичный случай: продавец не весь ассортимент держит у себя на складе, часть - берет у поставщиков или партнеров. Те регулярно присылают ему на почту файл с информацией, что у них есть, в каком количестве, по какой цене. Наша система автоматически проверяет почту, разбирает новые файлы и обновляет информацию о ценах и наличии товаров. Я бы не сказал, что это именно складской учет, он сложнее. Скорее - единое окно для работы с максимумом доступной информации.
А ссылки на фиктивные судебные решения - это разве не оно?
Ну как минимум на неуважение к суду тянет, если не на что-то большее.
namespace Microsoft;
public lang C# {}