Вчера обнаружил что в ВТБ теперь можно переводить и по номеру карты (с рублевого счета, комиссия 0.5%, ну и курс ниже биржевого, например сейчас 5.53, а говорит что будет 5.29), и по iban: комиссия 1% но не меньше 3000KZT. Отправил перевод, жду вот когда дойдёт... Но вроде бы как и раньше всё должно быть -- до трёх дней.
Всё в виртуалках, поверх Silver 4216 (8CPU+8RAM), без лимитирования. Ко всему прочему, скрипты лежат на NFS-сторадже, а не в каком-нибудь локальном NVMe.
Вдобавок, мои цифры указаны с расчётом клиентского запроса Так вы меряете скорость своего роутера, своего впна, коммутаторов провайдера, днс серверов и ещё черт знает каких железок. С такой экспертизой можно скатиться до бенчмарков в браузерах.
И выше верно замечено было, что надо тестировать не хэлловорлд, а хоть какую-то реальную логику, а всё потому что, если при 10ms и при 100ms на запрос картина может оказаться совершенно не такой, как могло бы показаться.
Ну и при бенчмаркингах принято увеличивать конкурентность, а не время теста. Время теста вообще ни о чем не говорит. Особенно если оно живёт при c=10, но сдыхает при c=20...
Выглядит так, будто бы включен opcache.revalidate_path, или же вообще отсутствует opcache. Натравил вот ab -n1000 -c16 на свой прод, полноценный проц, в котором и БД, и кэши, и рендеринг, а не хэлловорлд-стаб. В связке nginx+nginx+php-fpm (8.3), и вот что-то как-то не верится в то, что php-fpm может давать вот так вот сходу +200ms латенси.
Connection Times (ms)
min mean[+/-sd] median max
Connect: 5 9 3.7 8 34
Processing: 40 63 8.5 63 119
Waiting: 30 40 5.6 41 64
Total: 46 72 10.7 71 152
Кстати да, бесит что на фоточках порой спиннер повисает на середине и всё (desktop, win). Отменяй, запускай заново -- пофиг, всё так же зависает в каком-то положении. Помогает либо подождать некоторое время, либо перезапустить. Чую я что что-то там накосячили в диспетчере соединений/загрузок...
Так эта проблема вообще надуманная, как по мне. Номера всегда освобождались при неоплате/неактивности, и не знать о такой особенности это очень и очень странно. Если у тебя есть необходимость не пользоваться номером (выезд за границу, например) -- для этого у провайдеров есть различные услуги наподобии "номер в сейфе". В крайнем случае, ничего не мешает раз в месяц отправить SMS куда-нибудь (даже в роуминге это не так уж дорого). Но это опять же, это если тебе номер нужен, и его утрата критична. А если плевать на него -- то и проблем никаких особо нету.
А "нехватку" номеров вполне себе можно объяснить неравномерным распределением. Они ж не просто так выдаются, из одного большого пула, а разделены по различным операторам и регионам, согласно плану нумерации. Ну и зачастую пулы номеров там не маленьких размеров. Например, на некий город с 100к населения у одного провайдера может быть выделен пул из 100к номеров, и конечно же он не будет весь использован, ведь есть люди которые пользуются другими провайдерами, а там тоже выделено 100к номеров, и так по всей большой четверке. Вот и получаем что в городе 100к, а выделено 400к. Но это опять же, очень и очень образно.
Также не стоит забывать про то, что симки не только у людей. Всякие автосигнализации, умные штуки, всякие датчики на трубах у какого-нибудь газпрома... Там я думаю тоже не маленький расход. Но в целом, я предполагаю что тут ситуация чуть схожа с IPv4. Кто-то купил себе, к примеру, /22, а в реальности заюзал всего /24, вот и остаются ещё 3 x /24 занятыми, хотя фактически не используются.
Тоже пришлось автоматизировать учёт облигаций для себя. Всё началось с того, что я хотел знать сколько же мне будет выпадать купонов за месяц чтобы наблюдать прибыль в абсолютных суммах. Ну а ещё была идея набить портфель так, чтобы купоны падали каждый день (не спрашивайте зачем, мои хотелки это мои хотелки :) ). В итоге написал небольшую утилиту для "визуализации" портфеля.
Отображение календаря со списком всех выплат и их общая сумма
Простое обновление портфеля (никаких дат, просто "список" в формате "ISIN колво" и всё)
Можно жмякнуть на дату и посмотреть что можно прикупить с выплатами в этот день были успешно решены. Рассчёт доходности бондов, дюрации, полноценное движение средств я делать не собирался (и не собираюсь), т.к. для этого, в целом, можно воспользоваться календариком в том же смарт-лабе.
Ну и главные проблемы которые возникли при реализации:
По флоатерам купоны не определены, поэтому наперёд можно посчитать на основании предыдущего периода (ну или самому где-то искать какая же будет ставка и забивать)
По структурным бондам то же самое, но там хотя бы известен процент заранее.
По некоторым бондам, я так и не понял почему (да и особо не заморачивался) последняя амортизация идёт именно как амортизация, а не погашение.
Дело не только в доставке. Часто в еде ценник выше чем если заказывать напрямую. Ну, надо же вкатунов на галерах кормить, они дерут с заведений под 30%, а заведения не хотят терять прибыль, поэтому у них в еде ценники выше на те самые 30% (а то и больше).
Вот ещё бы выкатили в прод удаление локальных файлов, и было бы прям вообще супер! Сам относительно недавно поменял гуглофото на иммич (вместе с переносом всего имеющегося барахла), и если не считать пару мелких, но бесячих багов, и немного отсутствующих фич -- прекрасно работает. Обратно менять не хочется :)
Ну так кодовая база то едина, что для веба, что для мобильных приложений. Так что на фронтенде доступен код мобильщиков! :)
Вчера обнаружил что в ВТБ теперь можно переводить и по номеру карты (с рублевого счета, комиссия 0.5%, ну и курс ниже биржевого, например сейчас 5.53, а говорит что будет 5.29), и по iban: комиссия 1% но не меньше 3000KZT. Отправил перевод, жду вот когда дойдёт... Но вроде бы как и раньше всё должно быть -- до трёх дней.
Всё в виртуалках, поверх Silver 4216 (8CPU+8RAM), без лимитирования. Ко всему прочему, скрипты лежат на NFS-сторадже, а не в каком-нибудь локальном NVMe.
И выше верно замечено было, что надо тестировать не хэлловорлд, а хоть какую-то реальную логику, а всё потому что, если при 10ms и при 100ms на запрос картина может оказаться совершенно не такой, как могло бы показаться.
Ну и при бенчмаркингах принято увеличивать конкурентность, а не время теста. Время теста вообще ни о чем не говорит. Особенно если оно живёт при c=10, но сдыхает при c=20...
Выглядит так, будто бы включен
opcache.revalidate_path, или же вообще отсутствует opcache.Натравил вот
ab -n1000 -c16на свой прод, полноценный проц, в котором и БД, и кэши, и рендеринг, а не хэлловорлд-стаб. В связке nginx+nginx+php-fpm (8.3), и вот что-то как-то не верится в то, что php-fpm может давать вот так вот сходу +200ms латенси.Так этот раздел можно же запинить, если так сильно нужен.
Вы про эту?
А ещё лучше отвечать текстом в гифках.
Кстати да, бесит что на фоточках порой спиннер повисает на середине и всё (desktop, win). Отменяй, запускай заново -- пофиг, всё так же зависает в каком-то положении. Помогает либо подождать некоторое время, либо перезапустить.
Чую я что что-то там накосячили в диспетчере соединений/загрузок...
Так эта проблема вообще надуманная, как по мне. Номера всегда освобождались при неоплате/неактивности, и не знать о такой особенности это очень и очень странно.
Если у тебя есть необходимость не пользоваться номером (выезд за границу, например) -- для этого у провайдеров есть различные услуги наподобии "номер в сейфе". В крайнем случае, ничего не мешает раз в месяц отправить SMS куда-нибудь (даже в роуминге это не так уж дорого). Но это опять же, это если тебе номер нужен, и его утрата критична. А если плевать на него -- то и проблем никаких особо нету.
А "нехватку" номеров вполне себе можно объяснить неравномерным распределением. Они ж не просто так выдаются, из одного большого пула, а разделены по различным операторам и регионам, согласно плану нумерации. Ну и зачастую пулы номеров там не маленьких размеров. Например, на некий город с 100к населения у одного провайдера может быть выделен пул из 100к номеров, и конечно же он не будет весь использован, ведь есть люди которые пользуются другими провайдерами, а там тоже выделено 100к номеров, и так по всей большой четверке. Вот и получаем что в городе 100к, а выделено 400к. Но это опять же, очень и очень образно.
Также не стоит забывать про то, что симки не только у людей. Всякие автосигнализации, умные штуки, всякие датчики на трубах у какого-нибудь газпрома... Там я думаю тоже не маленький расход. Но в целом, я предполагаю что тут ситуация чуть схожа с IPv4. Кто-то купил себе, к примеру, /22, а в реальности заюзал всего /24, вот и остаются ещё 3 x /24 занятыми, хотя фактически не используются.
А умная розетка сама нажмёт кнопочку на чайнике?
Хм, и правда есть. Спасибо!
А это где можно посмотреть такую информацию?
Упс, как-то криво спойлеры в маркдауне работают. Пропустил :)
Тоже пришлось автоматизировать учёт облигаций для себя. Всё началось с того, что я хотел знать сколько же мне будет выпадать купонов за месяц чтобы наблюдать прибыль в абсолютных суммах. Ну а ещё была идея набить портфель так, чтобы купоны падали каждый день (не спрашивайте зачем, мои хотелки это мои хотелки :) ).
В итоге написал небольшую утилиту для "визуализации" портфеля.
Тыц
Мои задачи, а именно:
Отображение календаря со списком всех выплат и их общая сумма
Простое обновление портфеля (никаких дат, просто "список" в формате "ISIN колво" и всё)
Можно жмякнуть на дату и посмотреть что можно прикупить с выплатами в этот день были успешно решены. Рассчёт доходности бондов, дюрации, полноценное движение средств я делать не собирался (и не собираюсь), т.к. для этого, в целом, можно воспользоваться календариком в том же смарт-лабе.
Ну и главные проблемы которые возникли при реализации:
По флоатерам купоны не определены, поэтому наперёд можно посчитать на основании предыдущего периода (ну или самому где-то искать какая же будет ставка и забивать)
По структурным бондам то же самое, но там хотя бы известен процент заранее.
По некоторым бондам, я так и не понял почему (да и особо не заморачивался) последняя амортизация идёт именно как амортизация, а не погашение.
Так можно же загрузить из google takeout
Дело не только в доставке. Часто в еде ценник выше чем если заказывать напрямую. Ну, надо же вкатунов на галерах кормить, они дерут с заведений под 30%, а заведения не хотят терять прибыль, поэтому у них в еде ценники выше на те самые 30% (а то и больше).
Вот ещё бы выкатили в прод удаление локальных файлов, и было бы прям вообще супер!
Сам относительно недавно поменял гуглофото на иммич (вместе с переносом всего имеющегося барахла), и если не считать пару мелких, но бесячих багов, и немного отсутствующих фич -- прекрасно работает. Обратно менять не хочется :)
Вы не одиноки!
Что-то мне это напомнило картиночку про то, зачем знать английский... :)