YK
1) да, альтернатива еще один колбэк - приложение/middleware вызывает чтото типа:
$env->{psgix.input.read_cb}->(sub ($body_chunk) {...})Size: a a a
2021 February 16
OP
Это лучше)
OP
В сервере который я прикручиваю это решено так:
В простейшем случае можно зарегать реквест ивент и он вызывается только когда весь реквест включая бади уже получен. Защититься от перегруза можно через макс бади сайз.
$server->request_event->add(sub {
my $req = shift;
say $req->body;
...
}
А если нужен полный контроль то можно поставить предварительный колбек который вызывается как только заголовки done, и там можно решить как себя вести для конкретного урла
$server->route_event->add(\&dispatcher);
sub dispatcher {
my $req = shift;
if ($req->uri->path eq ...) {
$req->enable_partial;
$req->max_body_size(1M);
$req->receive_event->add(sub {
my $req = shift;
# вызывается много раз, req body постоянно дополняется
});
}
else {
$req->receive_event->add(sub {
my $req = shift;
# для остальных урлов колбек сработает только по полному получению один раз
});
}
}
В простейшем случае можно зарегать реквест ивент и он вызывается только когда весь реквест включая бади уже получен. Защититься от перегруза можно через макс бади сайз.
$server->request_event->add(sub {
my $req = shift;
say $req->body;
...
}
А если нужен полный контроль то можно поставить предварительный колбек который вызывается как только заголовки done, и там можно решить как себя вести для конкретного урла
$server->route_event->add(\&dispatcher);
sub dispatcher {
my $req = shift;
if ($req->uri->path eq ...) {
$req->enable_partial;
$req->max_body_size(1M);
$req->receive_event->add(sub {
my $req = shift;
# вызывается много раз, req body постоянно дополняется
});
}
else {
$req->receive_event->add(sub {
my $req = shift;
# для остальных урлов колбек сработает только по полному получению один раз
});
}
}
AK
Насчёт Twiggy::Prefork - взлетело, но я чуть головой не поехал, устанавливая зависимости (у нас никакой cpanm не работает, приходится руками ставить, корпоративненько)
AK
Я и не знал, что Ruby сделал такой огромный скачок в развитии
AK
Похоже, Perl остался самым "консервативным" из старых интерпретируемых языков
AP
это хорошо или плохо?
VG
судя по тексту по ссылке, скорее хорошо
SF
это хорошо или плохо?
То, что перл сохраняет верность традициям? сложно сказать, насколько это хорошо или плохо.
Например, говна написанные лет 10 назад до сих пор работают, то есть берём perl-5.32.1 и берём скрипт 2010-го года (под какой-нить perl-5.12) и в общем случае он даже без модификаций запустится. То есть с точки зрения системного программирования и утилитарных вещей (админства) - это прям очень хорошо.
А вот например, что у перла нету пакетных менеджеров, которые умеют не только в metacpan.org, но и в github, прям в ревизии, причём как в tip ветки, так и в ревизию или tag - это не алё и очень плохо.
Например, говна написанные лет 10 назад до сих пор работают, то есть берём perl-5.32.1 и берём скрипт 2010-го года (под какой-нить perl-5.12) и в общем случае он даже без модификаций запустится. То есть с точки зрения системного программирования и утилитарных вещей (админства) - это прям очень хорошо.
А вот например, что у перла нету пакетных менеджеров, которые умеют не только в metacpan.org, но и в github, прям в ревизии, причём как в tip ветки, так и в ревизию или tag - это не алё и очень плохо.
SF
Нет, я конечно не говорю про мэйловый вариант CPM - https://github.com/my-mail-ru/cpm/tree/master_0.993
он-то умеет, но он не имеет статуса "официальной" утилиты в отличие от cpanm, или оригинального cpm (который весьма сомнителен по внутренней механике).
он-то умеет, но он не имеет статуса "официальной" утилиты в отличие от cpanm, или оригинального cpm (который весьма сомнителен по внутренней механике).
SZ
В сервере который я прикручиваю это решено так:
В простейшем случае можно зарегать реквест ивент и он вызывается только когда весь реквест включая бади уже получен. Защититься от перегруза можно через макс бади сайз.
$server->request_event->add(sub {
my $req = shift;
say $req->body;
...
}
А если нужен полный контроль то можно поставить предварительный колбек который вызывается как только заголовки done, и там можно решить как себя вести для конкретного урла
$server->route_event->add(\&dispatcher);
sub dispatcher {
my $req = shift;
if ($req->uri->path eq ...) {
$req->enable_partial;
$req->max_body_size(1M);
$req->receive_event->add(sub {
my $req = shift;
# вызывается много раз, req body постоянно дополняется
});
}
else {
$req->receive_event->add(sub {
my $req = shift;
# для остальных урлов колбек сработает только по полному получению один раз
});
}
}
В простейшем случае можно зарегать реквест ивент и он вызывается только когда весь реквест включая бади уже получен. Защититься от перегруза можно через макс бади сайз.
$server->request_event->add(sub {
my $req = shift;
say $req->body;
...
}
А если нужен полный контроль то можно поставить предварительный колбек который вызывается как только заголовки done, и там можно решить как себя вести для конкретного урла
$server->route_event->add(\&dispatcher);
sub dispatcher {
my $req = shift;
if ($req->uri->path eq ...) {
$req->enable_partial;
$req->max_body_size(1M);
$req->receive_event->add(sub {
my $req = shift;
# вызывается много раз, req body постоянно дополняется
});
}
else {
$req->receive_event->add(sub {
my $req = shift;
# для остальных урлов колбек сработает только по полному получению один раз
});
}
}
А что, архитектура вашей замечательной игры предполагает отправку на сервер за раз более чем 4к данных?
R
В веб? Почему бы и нет.
W
А что, архитектура вашей замечательной игры предполагает отправку на сервер за раз более чем 4к данных?
Вконтакте. Их API предоставляет друзей только через клиента игры. Серверного запроса нету. Приходится на авторизации присылать список друзей. А теперь вспомнили 5.000чников (или сколько там у ВК ограничение) завернутых в JSON. Шах?
SZ
Вконтакте. Их API предоставляет друзей только через клиента игры. Серверного запроса нету. Приходится на авторизации присылать список друзей. А теперь вспомнили 5.000чников (или сколько там у ВК ограничение) завернутых в JSON. Шах?
Это настолько частое действие, что тред с коннекцией клиента не может подождать? Или ты намекаешь на то, что серверы/каналы вк медленнее ваших?
W
Перезагрузка серверов с отключением всех пользователей и вход их обратно (причины не важны) - у вас ку-уча больших POST запросов в десятки килобайт, летящие от клиентов... По мобильной связи в том числе. Мат?
SL
а кто-то решал проблему - когда cpanm при установке из cpanfile пытается по зависимостям ставить последнюю версию модуля, хотя в самом cpanfile есть явно заданная версия для него?
SZ
Перезагрузка серверов с отключением всех пользователей и вход их обратно (причины не важны) - у вас ку-уча больших POST запросов в десятки килобайт, летящие от клиентов... По мобильной связи в том числе. Мат?
Я не понял, это клиент шлет на ваш сервер кучи данных о своих друзьях? И потом вдруг ваши серверы все одновременно перегружаются и клиенты досят данными?
SZ
а кто-то решал проблему - когда cpanm при установке из cpanfile пытается по зависимостям ставить последнюю версию модуля, хотя в самом cpanfile есть явно заданная версия для него?
Как она задана?
YK
В сервере который я прикручиваю это решено так:
В простейшем случае можно зарегать реквест ивент и он вызывается только когда весь реквест включая бади уже получен. Защититься от перегруза можно через макс бади сайз.
$server->request_event->add(sub {
my $req = shift;
say $req->body;
...
}
А если нужен полный контроль то можно поставить предварительный колбек который вызывается как только заголовки done, и там можно решить как себя вести для конкретного урла
$server->route_event->add(\&dispatcher);
sub dispatcher {
my $req = shift;
if ($req->uri->path eq ...) {
$req->enable_partial;
$req->max_body_size(1M);
$req->receive_event->add(sub {
my $req = shift;
# вызывается много раз, req body постоянно дополняется
});
}
else {
$req->receive_event->add(sub {
my $req = shift;
# для остальных урлов колбек сработает только по полному получению один раз
});
}
}
В простейшем случае можно зарегать реквест ивент и он вызывается только когда весь реквест включая бади уже получен. Защититься от перегруза можно через макс бади сайз.
$server->request_event->add(sub {
my $req = shift;
say $req->body;
...
}
А если нужен полный контроль то можно поставить предварительный колбек который вызывается как только заголовки done, и там можно решить как себя вести для конкретного урла
$server->route_event->add(\&dispatcher);
sub dispatcher {
my $req = shift;
if ($req->uri->path eq ...) {
$req->enable_partial;
$req->max_body_size(1M);
$req->receive_event->add(sub {
my $req = shift;
# вызывается много раз, req body постоянно дополняется
});
}
else {
$req->receive_event->add(sub {
my $req = shift;
# для остальных урлов колбек сработает только по полному получению один раз
});
}
}
как вариант для psgi-интерфейса: методы max_body_size, enable_partial может предоставлять объект в psgi.input