ну я, собственно, недогоняю что озночают слова @onokonem об отсутсвии поддержки перловой машиной многоядерности

чтобы утилизировать несколько ядер с помощью перла - надо играть в разные процессы и тот или иной вид IPC. треды в перле говно, считай, их нет.

там наверное что-то изменилось

ни-хе-ра

как было - так и осталось

в питоне, впрочем, тоже

ну значит разработчикам перла это дело неинтересно. Значит, не надо на перле писать такое :) Я вообще думаю, что перл -- это когда на awk получается уж очень сложно :))

Чтобы утилизировать несколько ядер на соседних машинах — тоже надо играть. Порой переход на кластер случается раньше, чем внезапный рост ввысь до потолка количества ядер — т.е. в вебе либо проект спокойно живёт на одном ядре с копейками, либо выстреливает и хочет сразу много рядом стоящих железок. В такой дихотомии спроить про треды не так интересно :)

Я б в этот момент крепко задумался, что такое "1 month" во всяких пограничных случаях типа високосных годов и проч. "1 число один месяц назад" издалека выглядит менее граблеопасно :)

Да более менее, я попробовал месяц вперед, от 31 января мне насчитало 28 февраля, так что в целом более менее корректно

Чтобы утилизировать несколько ядер на соседних машинах — тоже надо играть. Порой переход на кластер случается раньше, чем внезапный рост ввысь до потолка количества ядер — т.е. в вебе либо проект спокойно живёт на одном ядре с копейками, либо выстреливает и хочет сразу много рядом стоящих железок. В такой дихотомии спроить про треды не так интересно :)

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

ну значит разработчикам перла это дело неинтересно. Значит, не надо на перле писать такое :) Я вообще думаю, что перл -- это когда на awk получается уж очень сложно :))

ну я perl использую когда нужно много вычислений или сложная вложенность массивов, и в bash'е это начинает походить на ад...

Вычисления в bash'е -- это да :)

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

да ну. а rtb?

Вычисления в bash'е -- это да :)

https://en.wikipedia.org/wiki/Bc_(programming_language)

так это не bash

это bc

чтобы утилизировать несколько ядер с помощью перла - надо играть в разные процессы и тот или иной вид IPC. треды в перле говно, считай, их нет.

на самом деле ipc - это не больно. более того, если у вас хайлоад и большие rps - лучше процессами плодиться.

и я люблю dc для этих целей. У меня RPN-мозг :)

и я люблю dc для этих целей. У меня RPN-мозг :)

согласен

RPN - рулит

и я люблю dc для этих целей. У меня RPN-мозг :)

ну мы обсуждали уже. ты поставил себе galculator? :)

а realcalc?

на самом деле ipc - это не больно. более того, если у вас хайлоад и большие rps - лучше процессами плодиться.

на самом деле - конечно, больно, по сравнению с общей памятью и мутексами.

да ну. а rtb?

У rtb, кажется, входящий поток тоже зависит от суточных циклов людей, которые смотрят интернеты. Мне тут придумывается скорее телеметрия, где нагрузка от сенсоров, а люди так — иногда штырят в графики. Но кто-то скажет, что это не про веб :-)

у меня grpn есть :) Я по-моему до сих пор числюсь его мейнтейнером

У rtb, кажется, входящий поток тоже зависит от суточных циклов людей, которые смотрят интернеты. Мне тут придумывается скорее телеметрия, где нагрузка от сенсоров, а люди так — иногда штырят в графики. Но кто-то скажет, что это не про веб :-)

сенсоры тоже можно on-demand включать/выключать.

на самом деле - конечно, больно, по сравнению с общей памятью и мутексами.

вообще, pthreads умеют мьютексы в shared memory :)

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

в общем, коллеги, любой язык, vm/runtime которого не умеет в утилизацию более одного ядра штатно, я лично считаю мертвым и ненужным

и перл - первый среди них

А я считаю, что любому языку, как и любому другому инструменту -- свое место

В зависимости от задачи

(если это не Java, ггг)

кэп, перелогинтесь

Предлагаю начать закапывать python с того угла, где tensorflow похоронен :-)

не-не-не

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

например? не флейма ради, просто интересно. когда запросов сыпется сильно больше числа ядер в этом нет смысла.

то есть, я думаю, то, что это все сделано на питоне - это ошибка, надо было делать на чем-то вроде хаскеля. но уж как вышло

т.е. на рейте в 10krps это всё уже не имеет смысла.

т.е. на рейте в 10krps это всё уже не имеет смысла.

сильно зависит от времени обработки одного запроса

сильно зависит от времени обработки одного запроса

мм... а какое это имеет значение, когда их сыпется 10к?

ну даже 4к

да, так вот

Парни, у меня практический вопрос. А в Питере есть живые Debian developer'ы? Их в Москве куча, но я по-моему с ними тут никогда не встречусь, млять, один в одной жопе мира живет, другой в другой, а машины у меня тут нет

мне почему-то постоянно нужно принять запрос сделать несколько запросов к другим сервисам используя разной степени запутанности логику, учитывающую, к примеру, таймауты на подзапросах, сформировать ответ отдать ответ

или несколько ядер, или гринтреды, или асинхронщина

лучше всех гринтреды, наверное, особенно как они сделаны в гошечке

а, еще акторы

ну если запросов 4к на машинку, на машине 16 честных ядер, то cpu time на запрос 4ms на всё про всё — между ядрами данные уже дороговато гонять :)

или несколько ядер, или гринтреды, или асинхронщина

очевидно, что гринтреды или асинхронщина

ну если запросов 4к на машинку, на машине 16 честных ядер, то cpu time на запрос 4ms на всё про всё — между ядрами данные уже дороговато гонять :)

интересный заход. 4мс на 3ГГц - это вечность

мне почему-то постоянно нужно принять запрос сделать несколько запросов к другим сервисам используя разной степени запутанности логику, учитывающую, к примеру, таймауты на подзапросах, сформировать ответ отдать ответ

у меня всегда чуть иной заход: а как происходит апгрейд рабочего сервиса? если запросы короткие - да, всё просто. а если клиенты сутками висят?

и с чайками, да

http://money.get.away.get.a.good.job.with.more.pay.and.you.are.okay.money.it.is.a.gas.grab.that.cash.with.both.hands.and.make.a.stash.new.car.caviar.four.star.daydream.think.i.ll.buy.me.a.football.team.money.get.back.i.am.alright.jack.ilovevitaly.com/

охренеть

интересный заход. 4мс на 3ГГц - это вечность

Ну как вечность. Если gzip ещё ответ предстоит жать, то это довольно мало. 250 килобайт сжать примерно успеем и всё. :-)

http://www.opennet.ru/opennews/art.shtml?num=45956

https://en.wikipedia.org/wiki/Bc_(programming_language)

Да я не про это, вот реализуй просто ручками двоичный посик на bash'е и на том же perl, python(не юзай bisect). И ты увидишь что на тысячи массивах в тыщёнку другую элементов ты получишь разницу в поиске в разы.

А на кой хрен это на bash делать? :)

мне почему-то постоянно нужно принять запрос сделать несколько запросов к другим сервисам используя разной степени запутанности логику, учитывающую, к примеру, таймауты на подзапросах, сформировать ответ отдать ответ

здесь нужен асинхронный апи. или можно закапывать такое приложение.

здесь нужен асинхронный апи. или можно закапывать такое приложение.

зачем мне асинхронный апи? чтобы что? мне нужны горутины и синхронный апи

зачем мне асинхронный апи? чтобы что? мне нужны горутины и синхронный апи

чтобы не висеть с запросом, пока кто-то синхронно куда-то ходит. попросил. ушел. пришел. получил ответ. ушел. можно просто поднять вебсокет и ждать в нем ответа. но тогда это уже не про классический веб с rps по http

зачем мне асинхронный апи? чтобы что? мне нужны горутины и синхронный апи

Почему не аппликативные функторы и синхронный апи?

А на кой хрен это на bash делать? :)

ну люблю я bash... И это же не всё что надо было сделать. это так посерединке было

чтобы не висеть с запросом, пока кто-то синхронно куда-то ходит. попросил. ушел. пришел. получил ответ. ушел. можно просто поднять вебсокет и ждать в нем ответа. но тогда это уже не про классический веб с rps по http

Речь про апи, а не что там внутри

Почему не аппликативные функторы и синхронный апи?

потому, что все cовременные фп языки - говно

Речь про апи, а не что там внутри

именно. мне тоже насрано что там внутри. поэтому если у тебя 40к rps и 4 ядра, тебе глубоко насрать на размазывание одного запроса по ядрам

у меня всегда чуть иной заход: а как происходит апгрейд рабочего сервиса? если запросы короткие - да, всё просто. а если клиенты сутками висят?

легко. можно передавать открытые соединения через сокет между приложениями. Для go написан чуть ли не десяток пакетов, это делающих

ERROR: S client not available

потому, что все cовременные фп языки - говно

Да все языки говно, че там

не все настолько

легко. можно передавать открытые соединения через сокет между приложениями. Для go написан чуть ли не десяток пакетов, это делающих

вот уже лучше. только ещё контекст надо таскать

в чём проблема перетащить?

легко. можно передавать открытые соединения через сокет между приложениями. Для go написан чуть ли не десяток пакетов, это делающих

Или можно просто взять Erlang.

и стать луддитом

в чём проблема перетащить?

формально - ни в чём. но если есть жирная структура в памяти которая постоянно меняется - это больно.

таким образом нерешаемая проблема превратилась в простую инженерную

таким образом нерешаемая проблема превратилась в простую инженерную

ну она и была инженерной изначально.

можно велосипедить свои снапшоты, а можно как редис - fork() и дитя бэкапится.

это не поможет апгрейду

это не поможет апгрейду

я к тому, что аккуратно используя механизмы ОС можно избавиться от головной боли и своих велосипедов.

весь технический прогресс в IT — это велосипеды поверх железа, ОС, юзерспейса, рантайма, сети, фреймворка, который после кристаллизуется в форме нового слоя

НА двух последних ITGM руби островка просто не было, хотя группа по интересам существует. Дело в том, что последдний раз, когда они были, там было пять человеки 2 доклада и то не особо про Руби.

они просто не участвуют. руби тусовка довольно плотная в питере насколько мне известно. плюс оооочень много разработчиков эмигрировало.

https://www.youtube.com/watch?v=nc0hPGerSd4

https://www.icinga.com/2017/01/17/moving-to-github/

И вышла Icinga 2.6.1

> We're limited by the disk speed of a non-production machine. Как-то сурово у них 6 мегабайт в секунду с диска читается...

Вот вот

И так 310гб

Приветствую всех!

Ок

"Идущие на смерть приветствуют тебя, о Великий Чатик!"

что там с гитлабом, все данные восстановлены?

https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/

https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/

Постгрес под high io такой няша... Ну и сетап в два сервака без возможности прокрутить oplog от последнего бэкапа... Ну... Зато бесплатно.

Всем привет. Кажется готовят массовый зонд

Россиянам хотят предоставить всеобщий и безлимитный доступ в интернет https://rublacklist.net/25454/ Члены Экспертного совета при Правительстве России считают, что для граждан нашей страны необходимо обеспечить всеобщий и безлимитный доступ в интернет - в рамках развития цифровой инфраструктуры. В качестве приоритетных направлений цифровизации экономики Экспертный совет также предлагает выделить работу с большими объемами данных (big data), обеспечение защиты информации, создание сервисов на основе искусственного интеллекта, а также идентификацию пользователей и технических устройств

https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/

никто не пробовал gogs?

Россиянам хотят предоставить всеобщий и безлимитный доступ в интернет https://rublacklist.net/25454/ Члены Экспертного совета при Правительстве России считают, что для граждан нашей страны необходимо обеспечить всеобщий и безлимитный доступ в интернет - в рамках развития цифровой инфраструктуры. В качестве приоритетных направлений цифровизации экономики Экспертный совет также предлагает выделить работу с большими объемами данных (big data), обеспечение защиты информации, создание сервисов на основе искусственного интеллекта, а также идентификацию пользователей и технических устройств

всеобщий, но с блокировками. да :)

всеобщий, но с блокировками. да :)

часть заблокируют, а часть где мессенджеры обяжут массово все сливать, не будут... Такой тотальный надзор.

и впн запретить. да