Вэб-парсеры ~= вэб-серверы, у которых всё параллелится автоматически последние "тридцать лет".

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

Вэб-кодеры и те кто пишут вэб-парсеры — это совсем разные люди.

ну выше озвучили что просто запускают парсерный скрипт в 1000 потоков

это тот же самый уровень мышления и реализации что у веб кодеров

ничего плохого не имею ибо сам такой

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

ну дак парсеру даже балансировка не нужна - еще тупее

хм а что в вебе сложно параллелится

все что имеет стейт и требует синхронизации.

все что имеет стейт и требует синхронизации.

конкретнее

Кстати, у потоков есть своя фигня, под названием "переключение контекста потока", и оно занимает вполне реальное (и иногда дофига большое) время. И если в вебе 1000 потоков это не очень страшно, ибо большая часть времени — ожидание ответа от сервера, то в "нормальных" приложениях обычно используется кол-во потоков равное (количеству ядер - 1), одно оставляется системе на всякие нужды. Воркеры в nginx'е (который расчитан на высокую нагрузку и минимум переключений контекста) — прямое тому подтверждение, например.

всю жизнь работаю со стейтам и синхронизацией в вебе

и?

нет проблем с параллелизомо

Окей. как скажешь_) все легко паралелится. проблемы не существует

проблему решили системные разработчики БД и веб сервера

веб кодер просто говнякает 🙂

проблему решили системные разработчики БД и веб сервера

распределенная транзакция_)

всю жизнь работаю со стейтам и синхронизацией в вебе

Во, кстати, вот тебе забавная задачка, распараллелить компьютерную игрушку. Какую-нибудь бегалку-прыгалку : )

игруху да сложно

мутексы итд

а в вебе не помню чтобы хоть раз мутекс видел

Ты их и не мог увидеть, ибо они под капотом глубоко закопаны. Ни один веб-сервер не даст тебе доступ к своим мутексам, ибо запорешь всё нафиг дедлоками.

а что ты назваешь вебом? для сайта визитки не нужно.

Ты их и не мог увидеть, ибо они под капотом глубоко закопаны. Ни один веб-сервер не даст тебе доступ к своим мутексам, ибо запорешь всё нафиг дедлоками.

о чем и речь

все проблемы решили за нас умные дядьки

игруху да сложно

На самом деле, есть простой вариант, но будет один сильно нагруженный поток (обсчёт/рендер), и несколько вспомогательных под звук/сеть/сбор данных типа нажатых кнопок. Простой путь слегка увеличить фпс. А так — игрухи обычно очень плотно связаны и всегда должны выдавать однозначный результат, поэтому плохо параллелятся. Ну там, один объект в этом кадре уже подвинули, и он чего-то коснулся. А в следующем уже другой порядок обсчёта и другой результат. Разница в пару пикселей, но уже жёпка в предсказабельности и в точности действий. И такие различия накапливаются. С учётом того что один кадр в играх — это довольно много времени, получается страшно.

конечно. потому что изобретены очереди, шины данных, транзакции, саги, кеши, и множество других инструментов

1) любая ресурсоемкая стейтфул задача трудно паралелится. всевозможные обсчеты. нейронки. ИТД. 2) задачи с использованием файлов - к пример загрузил файл на одну тачку а следующий запрос пришел на другую тачку. 3) работа с несколлькими АПИ при запросе.

та госпади - любые задачи использующие шардирование как решение.

1) любая ресурсоемкая стейтфул задача трудно паралелится. всевозможные обсчеты. нейронки. ИТД. 2) задачи с использованием файлов - к пример загрузил файл на одну тачку а следующий запрос пришел на другую тачку. 3) работа с несколлькими АПИ при запросе.

Многослойные нейронки, кстати, норм параллелятся по долям слоёв. Там у каждого нейрона свой стейт, который зависит только от результата предыдущего слоя, который можно получить на предыдущем шаге.

Многослойные нейронки, кстати, норм параллелятся по долям слоёв. Там у каждого нейрона свой стейт, который зависит только от результата предыдущего слоя, который можно получить на предыдущем шаге.

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

просто в одном случае ты прямо сидишь и придумываешь схемы и стратегии

а в другом - форк, и понеслась

у кого-то есть опыт работы с nanomsg? не понимаю как работает в req/rep в асинхронном режиме

с zmq я делал так: socket:send_all({address, mp.pack(data)})

то есть явно указывал кому отвечать

Ух какая прелесть. Пойду копать.

У меня небольшие проблемы с луасокетом: он всем хорош и стандартен, но во-первых, маленький и нерегулируемый буфер для udp, а во-вторых не самая высокая скорость приёма-передачи данных, даже если оптимизировать со всех сторон. Я типа хочу занять весь гигабитный канал, а не получается окупировать и двадцати процентов :<

Сделай форк с своим размепом буффера)

Лень

А насчет скорости приема передачи я не знаю , причем здесь луасокет

Как он может влиять?

Чисто технически

Условно, на питоне получается в бешеную скорость передачи.

Пиздец тогда, а не либа

Сокетный апи же он прозрачен

Да не, для бытовых целей — более чем норм. Для извращений которые иногда нужны — не очень.

Там ничего не надо городить в либе

Ну ок

Ро сокеты есть для луа?

Их попробуй

Ну в каком-то виде да. Правда, городить свой TCP с блекджеком у меня мозгов не хватит, но мб есть какие-то надстройки протокольные типа гуглового quic.

Опять же, очень прозрачный апи

Не, свой тцп не надо

Аа кстати

Как вариант можешь взять хттп2 в качестве траспорта

Он не сильно медленнее тсп

Только патчить обе стороны придется

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

Так это нормальная практика

Отде:ьный поток под рид райт сенд ремив

И у меня на работе упираемся в производительность lua 5.1 без jit. Медленно. Всего 20-40к коротких сообщенек в секунду (30-50мбит/с). Luajit примерно в тридцать раз быстрее. Тут разве что балансить между несколькими машинами, или открывать несколько потоков с несколькими приёмниками и балансить уже на клиентских сторонах а ля "шлём в рандомный сокет из списка".

Так что совсем в идеале, нужен сишный бекенд который будет за определённое время всё предельно быстро выгребать и нормально буферизировать (несколько десятков мегабайт) и высылать в луа-стейт в отдельном потоке. Эх.

Ну да, сетевое ядро на си это хорошее решение в таком случае

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

Префорк/претред/коротины

Я луа я просто не знаю как там

Оно под вендой, поэтому селект ))

Иоцп

Проактор

На винде идеально работает

Загугли проактор паттерн

Оки, надо трындеть с теми кто мутит ядро бд, для которой я клепаю скрипты.

ладно, понял, продолжу мучать исходники))

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

А на чем наномсг построен?

Походу интересная тема раз на него с змку переходят

Красота какая - ОпенРести обновился и подтянул свежий джит с кучей нововведений

Ура!

подтянул только memory limit, table.* — их личный вклад

в свой форк