Как мне кажется, с таким доменом, лучше (больше пользы) бы переадресацию сделали на реальные центры/больницы для диагностики, а не плодили бесполезные одинаковые бенч сайты.
Как раз Scylla разрабатывалась чуть ли не дроп ин заменой Cassandra, она же не просто так поддерживает CQL (Cassandra Query Language). В пять раз быстрее по бенчам (ну и как авторы говорят, что на одну и туже нагрузку нужно в десять раз меньше нод)
Есть примеры компаний, которые осилили затюнить Cassandra под их нагрузки... Мне интересны конкретные примеры. Обычно такой тюнинг заканчивается компромиссами. Стоит ли оно того и надолго ли это?
Из нулевых? Истории вроде перехода с Cassandra на ScyllaDB из-за GC (зависание ноды до 4-5 секунд на топовом железе во время сборки мусора) от Discord еще достаточно свежие. GC при всем его развитии не перестает быть GC, со всеми его вытекающими минусами.
Будет спрос на Zig - будет и предложение (программисты).
Извините, если звучит грубо (нивкоем не не имею умысла нагрубить). Написание своего велосипеда - это ли не избыточность (оно оказалось, или Вам все же показалось)? Легковесные решения для трансформации логов есть - а куда вы их на вывод отправлять будете (тг, слак или в базу складировать) - это же не такая уж и проблема.
Просто судя по репозиторию, покрытие тестами абсолютно нулевое... Инструмент совершенно новый, и доверия особого нет. Почему не брать вполне производительные и легкие решения за основу (а главное проверенные)? Какие-то моменты вс-же не устраивали или целью было написать свое?
Ух, аутсорсинг и dependency на фрилансеров ой как плохо, а вот на студии/компании — хорошо? Имхо, любое внешнее dependency — уже большой риск в долгосрочной перспективе. Будут они поддерживать твой продукт или нет — не известно. Нужно учитывать время жизни продукта (ожидаемое), аудиторию, нужно ли будет расширять продукт и т.д. Возможно тогда поймете, какие же dependency вам нужны. Конечно хорошо, если в проекте в будущем у Вас не будет проблем типа: "О, этот фреймворк не поддерживается уже два года, а эта библиотека тоже умерла… А тут что бы добавить фичу надо перелопатить весь проект, ведь 'они' уже не работают с нами". Если с этим нет проблем, я думаю, что возможно вы на правильном пути. Хотя, имхо, у мобильных приложений с тех dependency плохо (они постоянно меняются, в отличии от десктопов), не известно, будет ли ваш код viable на "новом поколении" (особенно, если у вас новомодные фичи с AR/VR или прочие причуды). Хорошо тогда, когда это не ваши заботы. Если бюджет позволяет, всегда можно сделать это чужими заботами :smirk:
А уж кто (студия или фрилансер), извините, высрет вам более-менее стабильный билд в нужные сроки — не играет роли. Вопрос в том, что вы будете делать с этим после.
Насколько грубая? 🤔
А если серьезно, не увидел emissary как вариант envoy. Ну и бенчей нет, там что-то вроде отлетающего на 50k rps nginx.
Хотелось бы увидеть производительность кастомных сценариев (или базовых) своего таргет мини прокси на Pingora. Стоит ли оно того? 🤔
Использую нишевый tcp-inspect (юзаю haproxy ради него)
И референса lua api для haproxy нет на оф сайте, приходится юзать arpalert 🫠
Как мне кажется, с таким доменом, лучше (больше пользы) бы переадресацию сделали на реальные центры/больницы для диагностики, а не плодили бесполезные одинаковые бенч сайты.
Нужно все email сервисы тоже заблочить, а то нигерийские принцы наследство не выдают 🤣 а уж фишинг так к нулю уйдет. Короче, одни плюсы.
В общем-то у опсосов сейчас и так мобильный интернет не работает от слова совсем.
Как раз Scylla разрабатывалась чуть ли не дроп ин заменой Cassandra, она же не просто так поддерживает CQL (Cassandra Query Language). В пять раз быстрее по бенчам (ну и как авторы говорят, что на одну и туже нагрузку нужно в десять раз меньше нод)
Есть примеры компаний, которые осилили затюнить Cassandra под их нагрузки... Мне интересны конкретные примеры. Обычно такой тюнинг заканчивается компромиссами. Стоит ли оно того и надолго ли это?
Из нулевых? Истории вроде перехода с Cassandra на ScyllaDB из-за GC (зависание ноды до 4-5 секунд на топовом железе во время сборки мусора) от Discord еще достаточно свежие. GC при всем его развитии не перестает быть GC, со всеми его вытекающими минусами.
Будет спрос на Zig - будет и предложение (программисты).
Спасибо за ответ!
Извините, если звучит грубо (нивкоем не не имею умысла нагрубить). Написание своего велосипеда - это ли не избыточность (оно оказалось, или Вам все же показалось)? Легковесные решения для трансформации логов есть - а куда вы их на вывод отправлять будете (тг, слак или в базу складировать) - это же не такая уж и проблема.
Просто судя по репозиторию, покрытие тестами абсолютно нулевое... Инструмент совершенно новый, и доверия особого нет. Почему не брать вполне производительные и легкие решения за основу (а главное проверенные)? Какие-то моменты вс-же не устраивали или целью было написать свое?
Здравствуйте, а можно узнать, почему, например, fluent bit не подошёл?
Ух, аутсорсинг и dependency на фрилансеров ой как плохо, а вот на студии/компании — хорошо? Имхо, любое внешнее dependency — уже большой риск в долгосрочной перспективе. Будут они поддерживать твой продукт или нет — не известно. Нужно учитывать время жизни продукта (ожидаемое), аудиторию, нужно ли будет расширять продукт и т.д. Возможно тогда поймете, какие же dependency вам нужны. Конечно хорошо, если в проекте в будущем у Вас не будет проблем типа: "О, этот фреймворк не поддерживается уже два года, а эта библиотека тоже умерла… А тут что бы добавить фичу надо перелопатить весь проект, ведь 'они' уже не работают с нами". Если с этим нет проблем, я думаю, что возможно вы на правильном пути. Хотя, имхо, у мобильных приложений с тех dependency плохо (они постоянно меняются, в отличии от десктопов), не известно, будет ли ваш код viable на "новом поколении" (особенно, если у вас новомодные фичи с AR/VR или прочие причуды). Хорошо тогда, когда это не ваши заботы. Если бюджет позволяет, всегда можно сделать это чужими заботами :smirk:
А уж кто (студия или фрилансер), извините, высрет вам более-менее стабильный билд в нужные сроки — не играет роли. Вопрос в том, что вы будете делать с этим после.