Да… авторестарт при краше это зло ) Мы по началу когда только переходили на starman получили как-то удовольствие от «кривого» кода и 64 worker'ов… которые на авто-рестарте убивали нафиг процессор )
Круто… раньше хабр раз в пол года почитывал на предмет новых статей по perl и вгонялся в состояния уныния. Пол года назад переключились на Plack, но даже мысли не было написать статьи на русском об этом ибо было полное ощущение Perl is dead и это тупо никому не нужно будет )
> Т.е. написав web приложение вам не надо сосредотачиваться на особенностях FCGI интерфейса или mod_perl и т.д… Интерфейс получения запроса от сервера и отдачи данных один — PSGI.
Именно. У нас есть REST API и прошлым летом мы поняли что mod_perl совсем достал. Стали думать на что переписывать… А потом просто переписали под Plack и получили возможность запускать наш код и на FCGI и на Starman и на mod_perl и на всех остальных серверах. Причем переключение делается элементарно.
PSGI and Plack are inspired by Python's WSGI and Ruby's Rack
А потом я находил бенчмарки Plack и WSGI. Там выходило что perl web app на Plack работает медленнее чем на WSGI реализации. Но это из-за того что Plack/Starman писаны на Perl'е, а в Python'е эти задачи уже оптимизированы и на писаны частично на C. Хотя на perl'е уже тоже есть XS сервера, так что совсем новых тестов я не видел.
Я обнаружил что Wireshark не дампит пакеты который я посылаю, только то что получаю :-(((
Увы, с Линуксом все вымерли ) Хотя сам сидел под ним с 2002г до 2007 безвылазно ) А под виндой AC не найти )
На самом деле сейчас что iPerf, что SMB(NAS) на прием оба показывают фиговые цифры. Зато вот тот же iPerf на отсыл в 1 tcp-поток сразу раза в полтора больше показывает цифры…
Если на вход поступает — «01 12 31 32», а на выходе «12 32 31», то это будет считаться правильным ответом? У меня просто костяшки на развернуты для удобства чтения человеком.
Споткнулся о слово «бойкотирость» и подумал что какой я отсталый и не знаю такого слова… Полез в гугл и понял что все со мной ок, зато вот копи-паста процветает )
Другого AC клиента (не Apple) не найти, а вот другую AP пробовал. У друга дома Ubiquiti UniFi® AP-AC. Поведение на ней похожее было. И кстати, эта UniFI вообще хреновая… через стенку еле работает, максимальная пропускная способность тоже плохонькая судя по тестам iperf'а, а ценник космос.
Статью почитал… печалька, но статья старая, вполне возможно сейчас Apple уже исправило все…
Wireshark поставил и даже в «monitor» режиме смог запустить. Пакетов разумеется много. Как мне проще всего определить количество ss и прочие интересные факты? К примеру сейчас задампил пакеты при iperf в 1 поток и судя по фильтрам radiotap.vht.nss.0 == 3 — тут основной трафик, == 1 чуть-чуть пакетов, == 2 почти нету. Это значит что использовался всего 1 ss? или я вообще не то смотрю? )))
да, все 3ss
В 1 поток медленно… если в 32 потока iperf запустить, то получается 115MB/s (930Mbps). Это как мне кажется много… цель как раз именно с 1 tcp потока взять с Wi-Fi побольше )
SMB живет на NAS который подключен по 1000MB Ethernet к роутеру. Если качать по проводам то, там в пиках легко до 100Mb/s доходит. А когда начинаю качать по Wi-FI то упираюсь в такую же цифру примерно, как и при iperf в 1 поток.
iPerf я запускал на rMBP (wi-fi) и на MacBook (1000MB Eth).
А можно у вас про AC спросить?
У меня AC-1900 (Asus RT-AC86U) и я ну ни как не могу понять почему если я шлю 1 tcp поток (iperf) rMBP -> LAN у меня под 80MB/s, а если наоборот то всего 40MB/s. Выглядит так что если шлю с rMBP у меня 2 ss используется, а если наоборот то только 1ss?
В принципе основная проблема в том что когда я качаю что-то по SMB по Wi-Fi не используется весь доступный канал, а только часть… Хотелось бы разумеется использовать весь :(((
Конфиг — 802.11AC, 36 Channel, 80Mhz
iperf в 32 потока выжимает максимум, под 115MB/s… а вот в 1 поток работает уже не так грандиозно.
Просто интересно как тогда США оценивается :-)
А «малацы» в мировой политике никогда не было и не будет, у всех свои цели и они не такие ангельские как можно подумать.
countperl выдает на это 7, хотя должно быть 8.
Скорее созданный таймер выйдет из области видимости и будет отменен
Хотелось бы конечно еще и куски кода из Twiggy в примере увидеть, что бы лучше понимать как он обрабатывает callback'и и «склеивает» все вместе.
Именно. У нас есть REST API и прошлым летом мы поняли что mod_perl совсем достал. Стали думать на что переписывать… А потом просто переписали под Plack и получили возможность запускать наш код и на FCGI и на Starman и на mod_perl и на всех остальных серверах. Причем переключение делается элементарно.
А потом я находил бенчмарки Plack и WSGI. Там выходило что perl web app на Plack работает медленнее чем на WSGI реализации. Но это из-за того что Plack/Starman писаны на Perl'е, а в Python'е эти задачи уже оптимизированы и на писаны частично на C. Хотя на perl'е уже тоже есть XS сервера, так что совсем новых тестов я не видел.
Увы, с Линуксом все вымерли ) Хотя сам сидел под ним с 2002г до 2007 безвылазно ) А под виндой AC не найти )
На самом деле сейчас что iPerf, что SMB(NAS) на прием оба показывают фиговые цифры. Зато вот тот же iPerf на отсыл в 1 tcp-поток сразу раза в полтора больше показывает цифры…
Статью почитал… печалька, но статья старая, вполне возможно сейчас Apple уже исправило все…
Wireshark поставил и даже в «monitor» режиме смог запустить. Пакетов разумеется много. Как мне проще всего определить количество ss и прочие интересные факты? К примеру сейчас задампил пакеты при iperf в 1 поток и судя по фильтрам radiotap.vht.nss.0 == 3 — тут основной трафик, == 1 чуть-чуть пакетов, == 2 почти нету. Это значит что использовался всего 1 ss? или я вообще не то смотрю? )))
В 1 поток медленно… если в 32 потока iperf запустить, то получается 115MB/s (930Mbps). Это как мне кажется много… цель как раз именно с 1 tcp потока взять с Wi-Fi побольше )
SMB живет на NAS который подключен по 1000MB Ethernet к роутеру. Если качать по проводам то, там в пиках легко до 100Mb/s доходит. А когда начинаю качать по Wi-FI то упираюсь в такую же цифру примерно, как и при iperf в 1 поток.
iPerf я запускал на rMBP (wi-fi) и на MacBook (1000MB Eth).
У меня AC-1900 (Asus RT-AC86U) и я ну ни как не могу понять почему если я шлю 1 tcp поток (iperf) rMBP -> LAN у меня под 80MB/s, а если наоборот то всего 40MB/s. Выглядит так что если шлю с rMBP у меня 2 ss используется, а если наоборот то только 1ss?
В принципе основная проблема в том что когда я качаю что-то по SMB по Wi-Fi не используется весь доступный канал, а только часть… Хотелось бы разумеется использовать весь :(((
Конфиг — 802.11AC, 36 Channel, 80Mhz
iperf в 32 потока выжимает максимум, под 115MB/s… а вот в 1 поток работает уже не так грандиозно.
Обычно эти девочки потом воспитывают 10 детей без отца и побираются на пособиях.
Но хватит лирики, тема для других мест.
А «малацы» в мировой политике никогда не было и не будет, у всех свои цели и они не такие ангельские как можно подумать.