Насчет сноса крыши спидтеста: причин может быть множество самых разных, от нестабильности канала до особенностей работы шейпера, так что если у вас канал официально 10Мбит (как я понял из поста), то надеяться на чудо не стоит. Судя по размерам буферов, у вас UDP. Нормально, что вы получаете около 9Мбит на 10Мбит'ном канале, 10% - нормальный результат.
Добавлю еще, что сжатие может вам помочь, если процессор не загружен. В теории оно должно увеличить скорость, но не думаю, что значительно. Но зато скорость сильно просядет при нехватке ресурсов.
Валентин: действительно, как-то я броадкаст воспринимал сразу и на l2 и на l3, но вы правы, какая разница, что в dst ip. Ждем топикстартера, когда он продебажит, что приходит ему в dhcp discover.
Но если принять, что вы правы, с какой целью устройства шлют на мультикастовый адрес запросы, ведь если это не flip, то для чего? Это ведь не очень красивое поведение для поведения по умолчанию, приводит к подобным сетевым багам.
Валентин: а откуда информация про адрес ip назначения в пакете dhcp discover? В rfc по flip'у ничего не сказано про это, а, согласно стандарту dhcp, discover-пакеты должен быть броадкастом. То есть если вы правы, то тут должен быть еще какой-то rfc типа "dhcp with flip", иначе это нарушение стандарта. Да и с какой стати dhcp relay будет обрабатывать не broadcast dicsover запрос?
А если предположить, что flip включен на некоторых девайсах для определения "есть ли линк" путем поиска соседей по мультикасту, то он должен работать внутри влана что до фильтрации, что после, то есть фильтрация ничего бы не сломала.
Расскажите поподробнее, как это работает в вашем понимании. :)
Павел Вастеров: На всякий случай я даже заглянул в rfc, потому как в жизни с этим "свистоперделочным" протоколом (llmnr) не сталкивался, и-таки у меня к вам ряд вопросов. Какой броадкаст? Даже в аббревиатуре есть буковка M. Он юзает мультикаст, причем только по link local (то есть в связке с zeroconf), нужен как альтернатива DNS в одном сегменте сети, причем протокол преимущественно виндовых девайсов. Так что, во-первых, никакого отношения llmnr к dhcp нет, а во-вторых, работает он уже после того, как заработал zeroconf (apipa), то есть отношения к проблеме у автора топика никакой не имеется. Вы столько всего написали, но только вводите людей в заблуждение и уточняете какие-то ненужные детали.
realgord88: все это к wtforms, которые использует Flask для реализации форм. Проверка данных из формы должна выполняться с помощью валидаторов, коих полно встроенных (в т.ч. для ограничения длины, для проверки email), также их можно и расширять. Прописывается это в полях вашей RegisterForm.
ShamblerR: я забыл про размер, иначе-то sort не отсортирует. Изменил ответ, оно должно работать. Насчет скорости не знаю, как это будет. Кстати, можете сравнить с ls :)
Из всякого такого (таблички, красивости) добавлю еще:
htop: по процессам/памяти/процу/загрузке очень красив и удобен.
iptraf: хорош, чтобы наглядно оценить трафик + умеет логировать.
mtr: трейсроут и пинг.
Станислав Гордиенко: если не забудете, напишите потом в комментарии, что у вас получилось. Я сам собираюсь относительно скоро плотно покопать MVA для своих задач, вдруг вы успеете реализовать раньше меня это, было бы интересно. Может, найдете камни какие подводные, а то мой опыт с MVA был тривиален: использовал их для фильтрации и все, но не использовал, как вам предложил :)
Вячеслав Лебедев: мне кажется, что правильный вариант - это иметь дизайн, который разрешает +- туда сюда по строкам (чтобы длинные слова были ОК и так далее) и иметь специальный недлинный текст в такие места (отдельный атрибут в БД). Троеточия в тексте, где много строк, на стороне css/html - это само по себе уже некрасиво. Даже выполнив все условия, может оказаться так, что он ну вот некрасиво обрежется и все :)
p.s. Я проверял этот вариант сам, у него есть минусы/сложности, когда, например, речь идет про смену фона на hover, но они легко решаются, если есть less или подобное.
Модификатор "=" там не нужен, так как он задает точное совпадение, т.е. реврайты вложенные не сработают. Тут нужен обычный префиксный location.
Советую изучить доки по location и rewrite. В вашем случае, например, вместо ^/admin/(.*)$ должен быть ^/admin/.*$ (не нужна группировка), а также возможны косяки со слэшами.
Кроме того, с группировкой, вероятно, можно все короче переписать:
polkabana: dict - это хэш-таблица, т.е. ассоциативный массив. List - это вектор (массив с динамической длиной, реализуется в виде маленькой структуры в CPython). List ближе к "классическому" массиву.
uvelichitel: Если речь дойдет до веб-приложений, например, портировать win-приложение в браузер, адская визуализация данных, сложный интерфейс (много плюшек) или просто не совсем тривиальный каталог (много разношерстных данных, нужны удобные фильтры, поиск, классификация, все кастомное), то будет такая же ситуация.
Ну а лендинги направо/налево - это печально. Однажды мне предлагали лендинг сделать, таймер там навесить, я отказался, а клиент обещал больше никогда со мной не работать, потому что "тебе чо, деньги не нужны что ли, за 2 срубишь". На самом деле если действительно серьезно подойти к лендингу однотипному и по-настоящему его разработать, то какие-то его части могут стать интересной задачкой. Допустим, тривиальная внешне анимация может заставить погрузиться плотно в школьную геометрию на целый день, а то и на 2, можно поддержать опенсорс, оформить плагин, тогда это будет действительно веб-разработка. Проблема в том, что это никому не нужно, абстрактные проблемы шерифа не волнуют. Я бы не относил это к разработке. Это как есть гаражный умелец, а есть читающий умные книжки моторист. Они могут делать одно и то же, но качество работы кардинально отличается.
Добавлю еще, что сжатие может вам помочь, если процессор не загружен. В теории оно должно увеличить скорость, но не думаю, что значительно. Но зато скорость сильно просядет при нехватке ресурсов.