Ты, прежде чем делать систему, берёшь и читаешь спеки того что тебе шлют. И если там что-то малопарсибельное — орёшь на ночальника/вендора: "Ты что мне принёс? Сладкий хлеб?! Как я вилкой парсить буду?"

Кстати, 25к логов/сек это довольно много. При гигабитной сети, каждое сообщение (включая заголовки TCP) должны укладываться в 5.24288 бита, иначе не пролезут в сетевуху ))
В 10-гигабитной, соответственно, 52.4288 бита.
Или принимать это счастье должно несколько машин, целый кластер для приёма логов с балансировкой на клиентской стороне (ибо одна тачка не справится).
Так что если 25к это пик, то ещё ничо так (tcp выровняет приём), но в среднем должно быть около 1-5к логов/сек, туда уже средне-длинные логи влезают.

Это, увы, не прокатит, когда обе части пирога внедрять начали до тебя, а ты нужен на поддержку таких связок)

Речь о 40г сети и таких же адаптерах. Но чтобы минимизировать нагрузку при пересылке, логи бы желательно на первом же хопе парсить и ужимать. Чтобы можно было отправить "сообщение А, количество 300 штук", а не пересылать все 300 в чистом виде.

Это возвращает нас к автоматическому парсингу и хлебушку от разрабов, которые решили, что по tcp можно передавать сообщения без разбивки.

Но изначальная фигня вопроса была в том, что в норме, все tcp-rfc-сообщенькоориентированные — написаны с учётом длин сообщенек, дабы машина могла в точности определить длину и предельно быстро распарсить, в идеале — прямым распилом:
local len, data = data:sub(1, 4), data:sub(5)
local msg, data = data:sub(1, len), data:sub(len + 1)

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

Ну, то есть если у нас фиксированная длина текста длины сообщения — мы просто отпиливаем N символов, числофицируем, и отпиливаем от остатка то что у нас получилось. Если не фиксированная — нужен разделитель и регулярки, что хреново. Или фиксированная длина длины сообщения ))

В сишном варианте — можно смело упаковать 32-битное число в четыре октета, но на луях это не очень удобно (плюс при попытке дебага странно выглядит), поэтому именно в моём протоколе — 10 ascii-циферок. Оверхед, ну что поделать.

Я бы с удовольствием такой оверхед обрабатывал - если бы его кто добавил))

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

Ну тут оверхед ровно 6 символов. 4 символа 32-битного числа против 10 символов ascii.

Думаю, фиксированный длины для систем, работающих с полные URL путями, не вполне применимы.

Sub работает на порядок быстрее match, так что допустимо)

(On вместо n * log(n)^2 или чего-то такого)

Это экспериментально получено, или где-то записано?

Это примерно прикинуто

Ну сам прикинь. В регулярке почти точно есть n, она как правило проходит по всем символам строки.
Но ещё у неё есть обработка собственно регулярной фигни, это курсор который бегает по символам и набивает в магазин то что в него подходит, сбрасывает если напоролся на неподходящую фигню и так далее. По прикидке, это где-то log(n)^2: на log(n) не тянет ибо слишком просто, но и на n^2 тоже не тянет ибо жирновато.

How is everything?

Добрый день, помогите!

М?