shaos>> Для минимизации количества запросов можно все эхи разом опросить - для этого придётся городить новый вызов и новый формат ответа
hugeping> Не вижу смысла минимизировать число запросов. До сих пор считаю это ложной целью.

Два чаю этому джентельмену.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Ну вон я же вчера приводил замеры - каждый HTTPS запрос добавляет 3.5КБ к полезной нагрузке - будет 1000 запросов, будет лишних 3.5 мега...

Еще tcp фреймы, хендшейк и прочее. Если бы всё было так просто, все бы жили на /m и /e и были бы счастливы

Мне интересно почему срезы у нас трафик не уменьшили? До них было 2 мб в сутки, щас то 4.5 то 2.7. У тебя трафик в обе стороны считается или только входящий?

shaos> Ну вон я же вчера приводил замеры - каждый HTTPS запрос добавляет 3.5КБ к полезной нагрузке - будет 1000 запросов, будет лишних 3.5 мега...

Бесплатного HTTPS не бывает. Если хочется HTTPS, всё равно будут накладные расходы.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

Вроде сделал по времени сохранения - тормозов не заметил даже на больших эхах

Ща ещё немного погоняю и выложу

Я считаю тупо по апачи-логам - сколько там байт написано в ответе, столько и приплюсовываю

Сегодня кстати у меня появится /u/e/lim/N/... ;)

Тока он наоборот, lim/n/u/e

ahamai> то есть, тебя собирается атаковать собственный аплинк.

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

Какой пойнт, если мы говорим про чистоту бандла u/e. С пойнта ты ничего не получишь по u/e

Да и пойнт тебе с u/e ничё не сделает. Он может легально с u/point спаму нагнать

Или мы про фильтрацию эх уже говорим. Не важно, я в ответе к shaos всё расписал

> Тока он наоборот, lim/n/u/e

Не - так не получится :)

Тогда оно просто дублирует слайсы, смысл именно в том что оно впереди парохода

По идее можно попробовать и /lim/N/u/e/ поддержать, но через хак - оно будет смотреть если это /lim/N/u/e/ то само будет переупорядочивать в /u/e/lim/N/

Сделал

> curl -XGET https://sprinternet.io/iii/lim/3/u/e/retro.talks/english.talks

retro.talks
yceDK3BmBJnfAZQlktjd
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
english.talks
Nw9ofK5x70iFMTrHzjHp
HOYW7nXXHb3HPKAFLz1w

ahamai> Да и пойнт тебе с u/e ничё не сделает.

Без фильтрации айдишников — ой как сделает.

ну конечно оно в каком-то смысле дублирует слайсы :)

короче с хаком теперь работает, но только применительно к /u/e т.е. например /lim/3/list.txt у меня не пройдёт ;)

Хак:

elseif (($opts[0] == 'u' and $opts[1] == 'e') ||
        ($opts[0] == 'lim' and $opts[2] == 'u' and $opts[3] == 'e')) {
	$work_options=array_slice($opts, 2);
	// lim/N/u/e hack
	if($opts[0] == 'lim') {
		$work_options[0] = 'lim';
		$work_options[1] = $opts[1];
	}

shaos> Ну вон я же вчера приводил замеры - каждый HTTPS запрос добавляет 3.5КБ к полезной нагрузке - будет 1000 запросов, будет лишних 3.5 мега...

Если в каждой эхе у нас новых сообщений от 128 до 256 штук, то для 1000 запросов, с учётом того, что запрашиваем по одной эхе, нужно запросить 125 эх. Это раз

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

Бандлы по 40 сообщений... Если мы возьмём те самые 125 эх, в которых у нас по 256 новых сообщений и начнём их выкачивать такими вот бандлами, у нас всё равно будет 800 запросов, что меньше заявленного тобой ужасного числа на 20%.

В реальности такой оверхед будет только для новых узлов и разово. Дальше, при фетчинге хотя бы пару раз в день, количество запросов будет от силы несколько десятков на сессию, что меньше 10% от заявленного.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

> Без фильтрации айдишников — ой как сделает.

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

1. у нас есть файл с такой эхой - отдаём этот файл
2. у нас нет файла с этой эхой, отдаём пустую эху

третьего не дано