Hetzner:
https://myip.ms/browse/ip_ranges/1/ownerID/45081/ownerID_A/1
OVH:
https://myip.ms/browse/ip_ranges/1/ownerID/7593/ownerID_A/1
chesser плохого не посоветует, но нужно учесть момент, что картинка из css может быть давно в кэше браузера (в принципе, как и css).
Если без кук -
для отдельного location (например mini_style.css?random или 1x1.gif?random) - писать в memcache текущий ip.
А для секции html проверять значение memcache на встроенном в nginx: lua или perl---------- Добавлено 23.01.2017 в 19:22 ----------
может лучше найти список ip этих ДЦ?
Убрал кавычки для "$binary_remote_addr" и default изменил на ""
И default стоит прописать всем map---------- Добавлено 23.01.2017 в 00:22 ----------Кстати, юзер грузит несколько файлов стразу (html, картинки, стили, иконка) - нужно ограничивать все эти правила отдельной секцией для html (исключить все остальное)
Мне кажется, что нет куки - пустая строка
"0:HTTP/1.1:"
Dram, если писать не в куки, можно попробовать решение: при обращении к css писать в memcache (текущий ip).
Dram, но, им можно существенно урезать лимиты.
Поставить при запросе css и js - отдельную куку.
Обратите внимание, что css и js могут быть в кеше и не запрашиваться (у юзеров, которые были на сайте до введения этой куки). В этом случае: создать отдельный css и запрашивать его css?random_number
Осталось решить проблему первого просмотра: сначала грузитcя html, а потом css и js
Предложение: выводить подсказку "[Название текущей колонки]" при наведение мыши на одну из колонок в шапке таблицы.
Или хотябы:
Сейчас есть подсказка на каждой колонке "Редактировать условия фильтрации", добавить название текущей колонки, т.е.: "Редактировать условия фильтрации [Фраза]".
Из-за большого количества колонок, я уменьшил их ширину и не всегда помню какая и что означает.
Когда условий в фильтрации мало, нажимаю "Редактировать условия фильтрации" на колонке и смотрю какая добавлена (когда их много - новое условие НЕ добавляется и приходится просто увеличивать ширину колонки, чтобы вспомнить "что там").
Вообще да, Go быстр, в т.ч. и по времени компиляции.
Кстати, по этим тестам http://attractivechaos.github.io/plb/ на несложных регулярках вида
([a-zA-Z][a-zA-Z0-9]*)://([^ /]+)(/?[^ ]*)
Перл обходил все языки в списке. В т.ч. Си.
Сейчас изучаю GO. Крайне приятный и быстрый язык. Особенно радуют рутины.
Но, в защиту Perl - Перл побеждает Go в регулярках. Вообще Перл быстро работает с регулярками и хешами (мапы в го). И код для работы с регулярками - лаконичный. Т.е. он до сих пор идеально подходит для парсинга текста.
Написал простейший парсер файла с логами (десять строк: разбор регуляркой строки лога и запись в хеш) на GO и решил посмотреть насколько будет быстрее компилируемый язык, чем интерпретатор Перл.
Насколько же было велико мое разочарование, когда оказалось, что Перл заметно быстрее (примерно на 40%). Сравнивал в одном потоке, разумеется. В GO использовал MustCompile (и пробовал вариант с MustCompilePOSIX). В итоге, конечно, переписал код на GO без регулярок - и обошел по скорости Перл. Но, для быстрого решения некоторых задач - Перл еще рано списывать.
