Pull to refresh
73
0
Андрей Нехайчик @gnomeby

Пользователь

Send message

ни то, ни то. Связать от начала до конца в одну деталь.

Можно ли сшить свитер в "одну нитку"? Без швов вообще? Хотя бы теоритически?

я правильно понимаю, что это альтернатива embox?

Очень хорошо, такими темпами лет через 5 моя технарская ЗП взлетит до небес, потому как окажется, что добрые эмпатичные люди в связке с ИИ не способны производить конкуретноспособный продукт в некоторых областях.

Пойду составлю список дорогих покупок на будущее.

40% потери - это в первый сезон. Уже ко второму может еле хватать на день. Впрочем, если можно самому разобрать и поменять аккум, то норм.

Gradle вроде рандомно выбирает тесты, самому ничего разбивать по папкам не надо.

У нас было сложнее. Тесты разбиты на TestSuite`ы и только он может поднять нужную игровую ситуацию. А соответственно есть очень жирные TestSuite, которые дробить нежелательно.

Сейчас уже точно не вспомню, 8 лет назад то было. Но одна из причин, что тесты были в группах по функционалу и была жирная группа, которая тормозила больше остальных. А разбивать её тесты нельзя было, нарушалась удобная навигация по проекту.

А вот ещё. Как-то мы тогда сделали, что разработчики бы заметили, что тесты запустятся параллельно. Проект местами был тяжёлый, использовался PostGIS, и бывали случаи падения по ресурсам от излишней параллельности. 8 лет назад ресурсы ещё были не бесконечны. Сегодня даже на ноутах я думаю мы бы справились.

Можно человеку не в теме? Какой смысл использовать GPT-3.5 Turbo, если есть 4 Turbo?

Пробовали так делать в Wargaming. Тесты в PostgreSQL. В результате пришли к выводу, что усложнение слишком существенно, а прирост скорости в ~ 2-3 раза, а когда у тебя 9 минут все тесты, то игра не стоит свеч. Гораздо проще ускорить запуск тестов, что и было сделано:

  1. Запрофилировали все тесты, нашли самые долгие, ускорили.

  2. Ускорили всю работу с БД, для этого на локальных тачках отключили fsync, а потом и вовсе научились создавать БД под тесты, используя отдельный in-memory template, который клал БД в отдельное место, которое было в tmpfs. Вторую оптимизацию применили и на сервере, который тестировал PR.

    На выходе: Получили тоже ускорение в 2-3 раза, но всё поведение БД было как в реальном проде. И без необходимости подкладывать костыли при изменении тестов.

Докручиваем графу «Опыт» в резюме

Привет Антон.

Следующая крупная проблема не 2038 год, а May 18 2033. Потому что в этот день unixtimestamp будет равен 2000000000 и все кто валидировал timestamp по регулярке 1\d{9} соснут.

Хм, это странно. Может у вас железистая вода? Или у вас частный дом и добываете грунтовую?

на проде не испытывали, не прошел R&D.

MyISAM. В InnoDB есть примерный подсчёт, иногда точный не нужен.

Есть ещё ksqldb https://ksqldb.io/. Однако опыт использования показал 3 вещи:

  1. Иногда ты упираешься в тупик и дальше никак

  2. Непонятно как это работает и будет ли работать быстро всегда. Вернее лично ты можешь разобраться, но если ты уволишься не факт, что твоя работа будет легко подтянута.

  3. Некоторые вещи лучше сделать на атомарных счётчиках в Redis. А некоторые специальными движками в ClickHouse.

Зависит от движка DB, в некоторые метрики изначально встроены.

Давайте я попробую.

  1. Если вы очень хорошо умеете готовить межсервисное взаимодействие на REST, то gRPC по перформансу ничего вам дополнительно не даст. Ровно как и никакая другая технология.

  2. gRPC сложнее, если вы в целом не готовы в нём глубоко разобраться, а может даже проверить производительность, то не стоит его брать.

  3. Существуют ли преимущества при использовании gRPC? Конечно. Сжатие трафика, разные режимы работы, изменение АПИ без необходимости менять запущенных клиентов. Некоторая обязательная валидация сообщений. Это всё уже есть в коробке. Но при наличии пункта 1 выше, это всё можно написать ручками и поверх REST.

Конечно могу сильно ошибаться, я со своей стороны вижу проблему
применения gRPC в Python не в том, что он интерпретируемый. А в том, что gRPC прямо подразумевает многопоточный процесс с легковесными потоками, управлением памятью, ресурсами -- и это должна быть чистая и
естественная среда обитания для платформы, а не приделанная на костылях и подпорках. Вот тогда можно выжимать из протокола максимум. А это постоянный двунаправленный канал, мультиплексирование, почти полное отсутствие сериализации (данные берутся AS IS, по максимуму memcopy). Экономия трафика тут не целевая задача, а скорее побочная.

Вы ошибаетесь. Ничего gRPC не подразумевает, прекрасно работает и в других конфигурациях. Кстати в современном мире принято масштабироваться не многопоточностью, а репликами в кубике, оно тогда легко горизонтально масштабируется и блокировками друг другу не мешает.

Вообще, gRPC это про экстремальные нагрузки и производительность. Когда
это действительно становится уместным, тут уже узким местом будет
Python. Вот поэтому и странно, когда низкоуровневый протокол вкорячивают
туда, где ему совершенно не место.

Расскажите это компании Wargaming, у которой игровые сервера на python, а в каких-нибудь World of warplanes каждая пуля проходит через сервер.

Python - это клей между высокопроизводительными библиотеками, вручную считать разряды числа Пи на нём не стоит.

Всё верно.

  1. В sys.path надо дописать папку

  2. Не проверять файлы линтерами, это не ваши файлы и они не делаются вручную

И в обоих пунктах нет никаких проблем, это я вам как перфекционист говорю. Перфекционизм он только для своей работы, а не для чужой.

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity