Да, будет. Приводите своих клиентов. Пока программная механика в разработке — напишите мне на r00t@h3llo.cloud, отметим ваш аккаунт, а в конце месяца сделаем кешбек.
Увы, без «любых сервисов» нет механизма, который бы помешал одному пользователю создавать неограниченное число аккаунтов. И, как показывает практика у коллег, бесплатные ресурсы даже перепродают (это не шутка).
Мы хотим дать попробовать по настоящему мощные серваки и хороший сервис. Не «100 систем на одной задушенной ВМ», где всё трещит и падает, а полноценную инсталляцию в облаке — с надёжностью, резервированием и отказоустойчивостью.
До IPv6 банально еще руки не дошли. Но в целом ничто не мешает нам выделять даже целые подсети — это вполне реализуемо, просто нужно сделать )
Сейчас наша основная задача — отладить стабильную работу сервисов и систем под реальной пользовательской нагрузкой. А дальше мы быстро затащим новые фичи.
Если нужны ресурсы на тест больше, чем наши лимиты — постучитесь на r00t@h3llo.cloud, придумаем что-нибудь. Только сразу кейс опишите, который хотите проверить.
Во всех историях про кубер «зачем» всегда выходит на первое место. И там, где нет нагрузки / отказоустойчивости / автомасштабирования / частого деплоя / команды разработчиков /CI-CD-пайплайна и т. д., явной потребности в кубере нет. Тогда можно докер на виртуалке или тот же L1veStack.
Мы всё же обсуждаем ситуации, когда она есть, но тогда ручками вместо AutoProvisioning — это прям тяжело. Локальные PV — не лучший вариант для продакшена, даже маленького.
Мы запускаем и грохаем свои кластеры так часто, что это не имеет значения)))
А всё о чем вы говорите просится как продолжение статьи, ведь в этой мы говорим как раз о моменте до. До того, как кластер запущен. И после этого момента начинается совсем другая жизнь.
Вопреки мнению многих про низкое качество кода, полученного от LLM еще раз повторю три важных тезиса статьи:
Что попросил, то и получил, поэтому просить нужно правильно. Это вы указали, но поделюсь парой наблюдений:
помогает просить сначала архитектуру, потом пошаговую реализацию компонентов;
помогает просить сначала тесты (и их надо отревьювить самому), а потом имплементацию;
помогает после неудачного вывода подправить промпт с учетом особенностей, в которых нейронка лажает.
Необходимость ручного ревью никто не отменял, именно в понимании того, какое должно быть решение. В многократном ревью, чтобы код стал как будто своим, и лежит вопрос качества.
Владеть кодом (пусть и сгенерированным) — критически важно. Это буквально знать его и понимать, как он работает.
В целом, практика такая: если сеть не справилась с чем-то, можно либо уточнить задание по разработке компонента (тут все сильно пляшет по архитектуре) либо попросить с нуля, и, возможно — другую сеть.
Это примеры масштабных и зрелых проектов с качественной кодовой базой. А откуда конкретно нейросеть взяла веса для CRUD на Go одному Тьюрингу известно.
Еще не успели покодить, но на вопросы отвечает бодро. 1м токенов выглядит как заявка на победу, а судя по цене, очень похоже, что Anthropic, Google и OpenAI вступили в ценовую войну.
Новые модели сейчас выходят каждую неделю, но знаково, что они научились нормально кодить.
Почти на все ваши вопросы ответ есть в тексте статьи. Итераций — 108. Среднее — это среднее арифметическое, но на графиках можно и разброс увидеть. Время отклика считает сам pgbench.
Почему мы уверены, что таких таблиц хватит для теста? База с выбранным нами сайзингом занимала порядка 2ГБ. Мы специально выбрали такой размер, чтобы он не был ограничением.
Что понимать под производительностью — очевидно, основной продукт СУБД — количество выполненных транзакций за период времени (секунда). Это, по сути, сколько запросов сможет переваривать приложение.
Latancy — второй фактор, играющий значение для веб-приложений, сайтов и различных бэкендов. Это задержка, которая добавляется ко времени ответа приложения клиенту.
Конечно, можно представить и другие сценарии использования СУБД (например, аналитика). Тут — тяжелые джоины и сложные операции, а также скорость записи (если мы собираем данные в ту же базу, где и анализируем).
Но нам для теста вполне достаточно сценария веб-сервера.
Да, будет. Приводите своих клиентов. Пока программная механика в разработке — напишите мне на r00t@h3llo.cloud, отметим ваш аккаунт, а в конце месяца сделаем кешбек.
Увы, без «любых сервисов» нет механизма, который бы помешал одному пользователю создавать неограниченное число аккаунтов. И, как показывает практика у коллег, бесплатные ресурсы даже перепродают (это не шутка).
Мы хотим дать попробовать по настоящему мощные серваки и хороший сервис. Не «100 систем на одной задушенной ВМ», где всё трещит и падает, а полноценную инсталляцию в облаке — с надёжностью, резервированием и отказоустойчивостью.
До IPv6 банально еще руки не дошли. Но в целом ничто не мешает нам выделять даже целые подсети — это вполне реализуемо, просто нужно сделать )
Сейчас наша основная задача — отладить стабильную работу сервисов и систем под реальной пользовательской нагрузкой. А дальше мы быстро затащим новые фичи.
Ну не совсем. Вы из уравнения выкинули LoadBalancer, Managed Postgres (2 vCPU, 4GB) и Object Storage.
Деньги со счета можно будет потратить на любые сервисы.
IPv6 — в ближайших планах.
Получится, если настраивать кластер вручную.
Если нужны ресурсы на тест больше, чем наши лимиты — постучитесь на r00t@h3llo.cloud, придумаем что-нибудь. Только сразу кейс опишите, который хотите проверить.
А что вы собираетесь делать, чтобы вас заблокировали?
Во всех историях про кубер «зачем» всегда выходит на первое место. И там, где нет нагрузки / отказоустойчивости / автомасштабирования / частого деплоя / команды разработчиков /CI-CD-пайплайна и т. д., явной потребности в кубере нет. Тогда можно докер на виртуалке или тот же L1veStack.
Мы всё же обсуждаем ситуации, когда она есть, но тогда ручками вместо AutoProvisioning — это прям тяжело. Локальные PV — не лучший вариант для продакшена, даже маленького.
Все от кейса зависит. Часто CA делается на год.
Вообще ротация сертификатов это отдельная тема. Как и любой пункт статьи — можно прям копать вглубь на целую книгу.
Мы запускаем и грохаем свои кластеры так часто, что это не имеет значения)))
А всё о чем вы говорите просится как продолжение статьи, ведь в этой мы говорим как раз о моменте до. До того, как кластер запущен. И после этого момента начинается совсем другая жизнь.
Вопреки мнению многих про низкое качество кода, полученного от LLM еще раз повторю три важных тезиса статьи:
Что попросил, то и получил, поэтому просить нужно правильно. Это вы указали, но поделюсь парой наблюдений:
помогает просить сначала архитектуру, потом пошаговую реализацию компонентов;
помогает просить сначала тесты (и их надо отревьювить самому), а потом имплементацию;
помогает после неудачного вывода подправить промпт с учетом особенностей, в которых нейронка лажает.
Необходимость ручного ревью никто не отменял, именно в понимании того, какое должно быть решение. В многократном ревью, чтобы код стал как будто своим, и лежит вопрос качества.
Владеть кодом (пусть и сгенерированным) — критически важно. Это буквально знать его и понимать, как он работает.
В целом, практика такая: если сеть не справилась с чем-то, можно либо уточнить задание по разработке компонента (тут все сильно пляшет по архитектуре) либо попросить с нуля, и, возможно — другую сеть.
С задачей написать агента, читающего топик kafka и взаимодействующего с libvirt на уровне сокетов они тоже справляются.
Это примеры масштабных и зрелых проектов с качественной кодовой базой. А откуда конкретно нейросеть взяла веса для CRUD на Go одному Тьюрингу известно.
Еще не успели покодить, но на вопросы отвечает бодро. 1м токенов выглядит как заявка на победу, а судя по цене, очень похоже, что Anthropic, Google и OpenAI вступили в ценовую войну.
Новые модели сейчас выходят каждую неделю, но знаково, что они научились нормально кодить.
Да, дефолтный пользователь имеет лимит в 50 подключений.
Совершенно зря.
Вот такой диск взяли у VK.
pgbench даже простой селект считает транзакцией (тут под транзакцией имеется в виду любой запрос к БД).
Поэтому мы и предлагаем каждому тестировать БД под свои нагрузки, а наш тест — это скорее ориентир.
Да, сейчас перепроверили, у Яндекса это спрятано очень глубоко (привет дарк-паттернам).
Спасибо, поправил.
Почти на все ваши вопросы ответ есть в тексте статьи. Итераций — 108. Среднее — это среднее арифметическое, но на графиках можно и разброс увидеть. Время отклика считает сам pgbench.
Почему мы уверены, что таких таблиц хватит для теста? База с выбранным нами сайзингом занимала порядка 2ГБ. Мы специально выбрали такой размер, чтобы он не был ограничением.
Что понимать под производительностью — очевидно, основной продукт СУБД — количество выполненных транзакций за период времени (секунда). Это, по сути, сколько запросов сможет переваривать приложение.
Latancy — второй фактор, играющий значение для веб-приложений, сайтов и различных бэкендов. Это задержка, которая добавляется ко времени ответа приложения клиенту.
Конечно, можно представить и другие сценарии использования СУБД (например, аналитика). Тут — тяжелые джоины и сложные операции, а также скорость записи (если мы собираем данные в ту же базу, где и анализируем).
Но нам для теста вполне достаточно сценария веб-сервера.