Nginx модуль в интерфейсе для клиента получается привязанным к модели JSON RPC сервера.
Это означает, что даже для простого получения данных необходимо формировать вызов метода.
В данный момент популярно/молодёжно/втренде REST API.
Было бы неплохо реализовать такую модель работы: имя метода в пути URI или зашит в конфиге nginx, а параметры берутся из URI.
Еще неплохо было бы где-то встроить поддержку oauth2.
Это техническая реализация. Я про идею, вместо списка слов емейлы. Хотел узнать, идейно так или еще сами логи реорганизуются чтобы юзер не был разбросан везде?
>> Ведь нельзя объединить «потом» уникальных посетителей и ряд других уникализируемых за разные периоды данных.
Почему нельзя? Слияние с логическим объединением информации: что-то суммируется, что-то выбирается по приоритету,…
Если все взвесить, это не такой простой вопрос.
Поток, который что-то считает в структуре по этому указателю, делает маленькие кратковременные вычисления очень часто (несколько тысяч в секунду). Каждый раз захватывать мютекс, конечно же, можно (можно и на несколько порядков больше), но все это дается не бесплатно. Поэтому, собственно, возникает желание написать wait-free алгоритм работы.
Задача сериализующего потока потока — забрать текущий указатель, и подменить другим. Атомарность замены одного на другое не решает проблему дальнейшего использования указателей. Тут можно решить тремя путями (спасибо Александреску): подсчет ссылок, подождать достаточное время (выбор автора статьи), и hazard pointers. Для подсчета ссылок понадобится DCAS (чего нет у x86), или же CAS2 (использовать старшие 16 бит указателя для счетчика). А для реализации hazard pointers нужно уметь проверять что в пользовании у других потоков, это тоже не тривиально в плане синхронизации.
Тут можно было бы предложить сделать отсечки timestamp между подсчетами в одном потоке, и проверять их сериализующем: сериализующий поток подменяет указатель, и делает свою отсечку, делаем смещение на безопасный интервал (в разных ядрах может не clocks), и ждем когда у другого потока timestamp станет больше нашего. Это будет нам говорить, что при последнем обращение к указателю в хештаблице другой поток «увидел» новое значение. После этого можно сериализовать данные и освобождать память.
С точки зрения событий — возможно, но к каждому соединению как приложение, так и операционная система выделяет некоторым объем памяти.
Так же механизмы хранения коннекшенов, сокетов и отнесение пакета к определенному соединению становится затратнее с ростом числа соединений. Стандартная сборка ядра линукса начинает себя вести плохо начиная с определенного числа соединений, по причине линейного перебора списка в хештаблице.
А что вы можете сказать по теме поста, могли бы быть полезны новые фичи для вас?
Что бы вы хотели увидеть нового в Рейтинге, или почитать интересное про то как это делается?
Спасибо, добавлю в копилку слухов про mail.ru, вы сделали мой день)
На самом деле, мы давно предоставляем код без логотипа, и никаких приложений на компьютеры не ставим.
Это означает, что даже для простого получения данных необходимо формировать вызов метода.
В данный момент популярно/молодёжно/втренде REST API.
Было бы неплохо реализовать такую модель работы: имя метода в пути URI или зашит в конфиге nginx, а параметры берутся из URI.
Еще неплохо было бы где-то встроить поддержку oauth2.
хвост ниже от следующего A
Почему нельзя? Слияние с логическим объединением информации: что-то суммируется, что-то выбирается по приоритету,…
Поток, который что-то считает в структуре по этому указателю, делает маленькие кратковременные вычисления очень часто (несколько тысяч в секунду). Каждый раз захватывать мютекс, конечно же, можно (можно и на несколько порядков больше), но все это дается не бесплатно. Поэтому, собственно, возникает желание написать wait-free алгоритм работы.
Задача сериализующего потока потока — забрать текущий указатель, и подменить другим. Атомарность замены одного на другое не решает проблему дальнейшего использования указателей. Тут можно решить тремя путями (спасибо Александреску): подсчет ссылок, подождать достаточное время (выбор автора статьи), и hazard pointers. Для подсчета ссылок понадобится DCAS (чего нет у x86), или же CAS2 (использовать старшие 16 бит указателя для счетчика). А для реализации hazard pointers нужно уметь проверять что в пользовании у других потоков, это тоже не тривиально в плане синхронизации.
Тут можно было бы предложить сделать отсечки timestamp между подсчетами в одном потоке, и проверять их сериализующем: сериализующий поток подменяет указатель, и делает свою отсечку, делаем смещение на безопасный интервал (в разных ядрах может не clocks), и ждем когда у другого потока timestamp станет больше нашего. Это будет нам говорить, что при последнем обращение к указателю в хештаблице другой поток «увидел» новое значение. После этого можно сериализовать данные и освобождать память.
Так же механизмы хранения коннекшенов, сокетов и отнесение пакета к определенному соединению становится затратнее с ростом числа соединений. Стандартная сборка ядра линукса начинает себя вести плохо начиная с определенного числа соединений, по причине линейного перебора списка в хештаблице.
Что бы вы хотели увидеть нового в Рейтинге, или почитать интересное про то как это делается?
На самом деле, мы давно предоставляем код без логотипа, и никаких приложений на компьютеры не ставим.