Отичное сравнение!
Одна заметка — в аналитике обычно принято учитывать не «Самый длительный запрос», а скорее «95% запросов выполнено в пределах ххх сек.»
Да, что-то последнее время часто замечаю, что многие ими пренеборегают. Вот недавно наблюдал, как люди чуть не угробили проект из-за того, что посреди рабочего процесса у них SVN-сервер умер… Ну да, действительно, зачем делать бэкапы СВНа, когда его текущее состояние есть у каждого работника?
>я решил, что доход до 500$=1; от 500 до 1000 — 2; от 1000 и выше = 3
это уже классификация
>Возможно для решения каких-то моих практических задач будет правильнее
>выбрать величин, характеризующих доход не числа 1,2,3, а к примеру 1,2,4.
Вообще, я например все значения нормализую. Например, представим рельсы у них длина много больше ширины, поэтому рельсы отличающиеся на 5% по длине и на 1200% по ширине окажутся в одном кластере. Поэтому я значения всех измерений нормализую (если это возможно, то есть данные не потоковые) и самой короткой длине выдаю значение 0, самой длинной, например, 100, все остальные длины будут в промежутке от 0 до 100, так же поступаю с остальными измерениями. Все значения после этого становятся нормализованными.
>А как вычисляются расстояния при кластеризации по не числовым признакам?
Когда измерение дискретно и возможно заранее получить все возможные значения измерения (как например пол), то конечно можно заменять значения заранее просчитанными нормализованными значениями, дабы прибавить производительности алгоритму. Но стандартной практикой является использование Расстояния Левенштейна
200к пакетов в секунду вам уже не backlog, а interrupt queue забьют, там уже не важно какие это будут пакеты, против таких DDoS'ов отбиться простым софтварным способом практически нереально
Однако есть ряд недостатков:
* Отсутствие тюнинга самой ОС, чтобы сервер начал обслуживать адекватное кол-во коннектов(а ведь для этого обычно nginx и ставится) нужно подгонять sysctl'и aka «тюнинг по-Сысоеву» (как минимум kern.ipc.somaxconn, net.inet.ip.portrange.first итд)
* ОС и nginx не использует httpready фильтр (kldload accf_http, accept_filter=httpready)
* Отсудствие тюнинга самого nginx (worker_processes по кол-ву процессоров, sendfile on, tcp_nodelay on, reset_timedout_connection on; итд итп)
* PHP на порту, а не сокете (юзаем путь к сокету php-fpm в переменной fastcgi_pass)
* PHP-cgi необходимо передовать побольше параметров чем указано, например, не помешало бы добавить как минимум fastcgi_param REMOTE_ADDR $remote_addr;
Как-то не сложилось у меня с K-Means ибо:
* Зачастую долго сходится
* При каждом запуске выдаёт разные результаты. Спасает только испоьзование K-Means++
* Но самой большой проблемой всё равно остаётся то, что далеко не всегда знаешь нужное колво кластеров на которое нужно разделить объекты, по хорошему она на то и кластеризация, что на входе ты поучаешь просто набор векторов в N-мерном пространстве, не зная на сколько групп их делить.
Именно поэтому, в основном использую Minimal Spaning Tree, Single-/Averenge-/Complete- Link или Генетические алгоритмы. Последние люблю за то, что они прекрасно паралелятся, хоть и тоже долго сходятся. У "-Link" семейства алгоритмов бонус в простоте расчётов (особенно у Single-Link) и возможности следить за RMSE на каждом шаге алгоритма, выбирая оптимальное количество кластеров.
Одна заметка — в аналитике обычно принято учитывать не «Самый длительный запрос», а скорее «95% запросов выполнено в пределах ххх сек.»
«ПФР обслуживает более 38 млн. пенсионеров,....»
теперь я понял почему 3.8 млн за сайт =))
«cat file | xxxx | grep blablabla» != «grep balblabla file | xxxx»
Вместо xxxx попробуйте представить sed/awk/tr, впрочем в некоторых случаях и strings
ПС. Поправил, спасибо
Ммм… а это как? VNC на java с http интерфейсом чтоль?
это уже классификация
>Возможно для решения каких-то моих практических задач будет правильнее
>выбрать величин, характеризующих доход не числа 1,2,3, а к примеру 1,2,4.
Вообще, я например все значения нормализую. Например, представим рельсы у них длина много больше ширины, поэтому рельсы отличающиеся на 5% по длине и на 1200% по ширине окажутся в одном кластере. Поэтому я значения всех измерений нормализую (если это возможно, то есть данные не потоковые) и самой короткой длине выдаю значение 0, самой длинной, например, 100, все остальные длины будут в промежутке от 0 до 100, так же поступаю с остальными измерениями. Все значения после этого становятся нормализованными.
>А как вычисляются расстояния при кластеризации по не числовым признакам?
Когда измерение дискретно и возможно заранее получить все возможные значения измерения (как например пол), то конечно можно заменять значения заранее просчитанными нормализованными значениями, дабы прибавить производительности алгоритму. Но стандартной практикой является использование Расстояния Левенштейна
Пересобирать из исходников каждый раз при обнаружении remote buffer overflow / DoS PoC не вариант.
Однако есть ряд недостатков:
* Отсутствие тюнинга самой ОС, чтобы сервер начал обслуживать адекватное кол-во коннектов(а ведь для этого обычно nginx и ставится) нужно подгонять sysctl'и aka «тюнинг по-Сысоеву» (как минимум kern.ipc.somaxconn, net.inet.ip.portrange.first итд)
* ОС и nginx не использует httpready фильтр (kldload accf_http, accept_filter=httpready)
* Отсудствие тюнинга самого nginx (worker_processes по кол-ву процессоров, sendfile on, tcp_nodelay on, reset_timedout_connection on; итд итп)
* PHP на порту, а не сокете (юзаем путь к сокету php-fpm в переменной fastcgi_pass)
* PHP-cgi необходимо передовать побольше параметров чем указано, например, не помешало бы добавить как минимум fastcgi_param REMOTE_ADDR $remote_addr;
* Зачастую долго сходится
* При каждом запуске выдаёт разные результаты. Спасает только испоьзование K-Means++
* Но самой большой проблемой всё равно остаётся то, что далеко не всегда знаешь нужное колво кластеров на которое нужно разделить объекты, по хорошему она на то и кластеризация, что на входе ты поучаешь просто набор векторов в N-мерном пространстве, не зная на сколько групп их делить.
Именно поэтому, в основном использую Minimal Spaning Tree, Single-/Averenge-/Complete- Link или Генетические алгоритмы. Последние люблю за то, что они прекрасно паралелятся, хоть и тоже долго сходятся. У "-Link" семейства алгоритмов бонус в простоте расчётов (особенно у Single-Link) и возможности следить за RMSE на каждом шаге алгоритма, выбирая оптимальное количество кластеров.