-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
новый тест по mysql+php+linux
- Автор темы fisher
- Дата начала
fisher
накатила суть
эээ а где я это обещал такое?fisher
а движок тестирования уйдет в опенсоурс?)
не обещал, я ж почему и спросил, собираешься ты это открывать или нет?
ничего. причем тут это?
fisher
И добавьте однозначность (радио бутом и чекбоксу) и время, по регулярным выражениям, там где маска подсети - это вообще ужас какой-то, мало того, что есть явная строка REMOTE_IPADDR (это ж не тест на внимательность), есть явные ошибки, которые вызовут compilation fail, регулярки вообще нужно переработать, про XSS я бы вообще выпилил, если уж интересно, то можно спросить вообще про XSS, SQL Injection, а в глубокое вставить Header Injection и e-mail injection/
И необходимо структурировать, допустим
- Базовые знания MySQL
- MySQL DBA
- Базовые знания PHP
- Глубокие знания PHP
- Пользователь Linux
- Опытный пользователь Linux
- Сис. админ.
Вопрос по типу протокола (Какой протокол можно использовать для передачи данных статистических данных между серверами) - вызвал недоумение, есть несколько уровней протоколов, HTTP, SMTP - протоколы передачи данных, TCP, UDP - сетевые протоколы передачи данных - какой там правильный ответ, и если можно, повторите вопрос точно. Хочу отметить, что netflow протокол использует udp протокол, а http - tcp протокол, вообще, понятие в компьютерных системах протокола - обширно - это вообще стандарт, но есть аппаратный протокол, а есть программный протокол, хотя тот же программный протокол можно организовать и на аппаратном уровне и использовать его для передачи других данных (например - протокол передачи данных Cluster Load, разработанный компанией X, который использует протокол передачи данных HTTP, который в свою очередь использует сетевой протокол передачи данных TCP), есть случай, когда протоколы DNS используют и TCP и UDP.
И добавьте однозначность (радио бутом и чекбоксу) и время, по регулярным выражениям, там где маска подсети - это вообще ужас какой-то, мало того, что есть явная строка REMOTE_IPADDR (это ж не тест на внимательность), есть явные ошибки, которые вызовут compilation fail, регулярки вообще нужно переработать, про XSS я бы вообще выпилил, если уж интересно, то можно спросить вообще про XSS, SQL Injection, а в глубокое вставить Header Injection и e-mail injection/
И необходимо структурировать, допустим
- Базовые знания MySQL
- MySQL DBA
- Базовые знания PHP
- Глубокие знания PHP
- Пользователь Linux
- Опытный пользователь Linux
- Сис. админ.
Вопрос по типу протокола (Какой протокол можно использовать для передачи данных статистических данных между серверами) - вызвал недоумение, есть несколько уровней протоколов, HTTP, SMTP - протоколы передачи данных, TCP, UDP - сетевые протоколы передачи данных - какой там правильный ответ, и если можно, повторите вопрос точно. Хочу отметить, что netflow протокол использует udp протокол, а http - tcp протокол, вообще, понятие в компьютерных системах протокола - обширно - это вообще стандарт, но есть аппаратный протокол, а есть программный протокол, хотя тот же программный протокол можно организовать и на аппаратном уровне и использовать его для передачи других данных (например - протокол передачи данных Cluster Load, разработанный компанией X, который использует протокол передачи данных HTTP, который в свою очередь использует сетевой протокол передачи данных TCP), есть случай, когда протоколы DNS используют и TCP и UDP.
MiksIr
miksir@home:~$
Почему это центральный сервер статистики не нужно грузить статистикой? С учетом того, что эта статистика, вернее ее отклонения от нормы, анализируемые на сервере, могут оперативно сообщить о проблемах дежурному инженеру?
Далее, протоколы прикладного уровня не очень подходят в виду оверхеда передаваемых данных. Плюс, все перечисленные - используют tcp. А если посмотреть отличия tcp от udp и прикинуть к задаче - становится, имхо, очевидно, что плюсы udp выгодны, а с недостатками, основоной из которых - не гарантированная доставка, вполне можно мириться.
Далее, протоколы прикладного уровня не очень подходят в виду оверхеда передаваемых данных. Плюс, все перечисленные - используют tcp. А если посмотреть отличия tcp от udp и прикинуть к задаче - становится, имхо, очевидно, что плюсы udp выгодны, а с недостатками, основоной из которых - не гарантированная доставка, вполне можно мириться.
fisher
накатила суть
не собиралсяне обещал, я ж почему и спросил, собираешься ты это открывать или нет?
MiksIr
miksir@home:~$
Ну тут задача четкая - онлайн статистика в кластере. Как правило тут и с каналами все ок, и выпадение или перепутывание отдельных пакетов не принципиально - доля таких минимальна, на картину не повлияет. В чем-то, конечно, tz и прав - можно построить схему и с агрегацией на нодах, ибо при очень большом масштабе кластера "онлайн" плевание может вполне упереться в сервер статистики/сеть. Если не ошибаюсь, роутеры, которые netflow вывплевывают, имееют возможности такой агрегации. При частичной агрегации на нодах потеря данных более опасна и использование tcp может быть обоснованно, хотя прикладные протоколы все-равно вряд ли тут будут уместны. Хотя, опять же, если локальная сеть с L2 свичом - ну тут не должно быть никаких потерь на совести сети, иначе нужно чинить сеть... - только потери на совести сервера статистики.
В общем, тут конечно практик нужен, или сесть с умом и ТЗ и посчитать - какой поток родит статистика и в какой момент эти потоки могуть быть проблемой, что бы переходить к агрегации.
В общем, тут конечно практик нужен, или сесть с умом и ТЗ и посчитать - какой поток родит статистика и в какой момент эти потоки могуть быть проблемой, что бы переходить к агрегации.
fisher
накатила суть
Вопросы: за деньги, за "внимание" или за доступ к базе кандидатов
http://raa.livejournal.com/198380.html
http://raa.livejournal.com/198380.html
fisher
накатила суть
"какать в одном поле не сяду!" (с)
спасибо большое, поправлю
Реально ужоос, что вы пишите...
> выпадение или перепутывание отдельных пакетов не принципиально - доля таких минимальна, на картину не повлияет.
> а с недостатками, основоной из которых - не гарантированная доставка, вполне можно мириться.
Итак, представим, в сети стали теряться UDP пакеты. Почему? Потому, что сеть где-то начала тормозить и часть пакетов пропало. Т.е. ВНЕЗАПНО сеть тормозит. Это мгновенно выдаст лавинообразное распространение на всю сеть тормоза, т.к. все веб-скрипты зависнут, ожидая гарантии доставки своих TCP пакетов.
С чем вы там мириться собрались? Вопрос только в том - сдохнет ваш проект, если сеть чуток подтормозит или вырубится автоматически самая не нужная система - статистика, но проект устоит.
Я борюсь с лавинообразными нагрузками еще более радикальными методами - вплоть до автоматического убивания SQL запросов с тормозных юзеров (флудер) или тормозных таблиц (диск не справляется). Да, можно этот метод еще более сильно обкакать, только у меня свой аргумент - проект выживает, когда нагрузка внезапно превышает возможности железа.
> выпадение или перепутывание отдельных пакетов не принципиально - доля таких минимальна, на картину не повлияет.
> а с недостатками, основоной из которых - не гарантированная доставка, вполне можно мириться.
Итак, представим, в сети стали теряться UDP пакеты. Почему? Потому, что сеть где-то начала тормозить и часть пакетов пропало. Т.е. ВНЕЗАПНО сеть тормозит. Это мгновенно выдаст лавинообразное распространение на всю сеть тормоза, т.к. все веб-скрипты зависнут, ожидая гарантии доставки своих TCP пакетов.
С чем вы там мириться собрались? Вопрос только в том - сдохнет ваш проект, если сеть чуток подтормозит или вырубится автоматически самая не нужная система - статистика, но проект устоит.
Я борюсь с лавинообразными нагрузками еще более радикальными методами - вплоть до автоматического убивания SQL запросов с тормозных юзеров (флудер) или тормозных таблиц (диск не справляется). Да, можно этот метод еще более сильно обкакать, только у меня свой аргумент - проект выживает, когда нагрузка внезапно превышает возможности железа.