Комментарии 46
Не знал, что почта у вас на перле работает. С чем это, кстати связано? Исторически или есть какие-то преимущества по сравнению с питоном, например? Еще вопрос — вы deamon tools используете или что-то еще?
Причины исторические
А как вообще, работой с Perl довольны? Нет ли желания мигрировать на другой язык? Если есть, то какие основные преимущества других языков видите? Если нет — то хорошо :)
Мы вполне довольны перлом. Есть свои нюансы.
Преимуществ у языков разных множество, на каждом можно написать высокопроизводительные и качественные продукты.
У нас есть продкуты которые с нуля написаны на перле за последний год. Есть также и на питоне. Каждый тимлид хвалит свой язык и им доволен.
Преимуществ у языков разных множество, на каждом можно написать высокопроизводительные и качественные продукты.
У нас есть продкуты которые с нуля написаны на перле за последний год. Есть также и на питоне. Каждый тимлид хвалит свой язык и им доволен.
Из крупных компаний очень многие используют perl, не только для админки.
А если инет компания ещё и относительно старая, то у неё будет perl в 99,9%
А если инет компания ещё и относительно старая, то у неё будет perl в 99,9%
Еще вопрос есть про бинарные протоколы — у вас свой велосипед или что-то подобное google protobuf/Thrift?
НЛО прилетело и опубликовало эту надпись здесь
по сравнению с мучительным переходом с 5.8.8.
А какие были проблемы с 5.8.8 на 5.10? Не связанные с 32bit vs 64 bit?
my $crypted_userid = $user->{'ID'} ^ 41262125215;
если о существовании кода с побитывыми операциями, кода использующего use integer и кода, работающего с числами больше 2**31, 2**32, или 2**53 было известно до миграции, то можно было просто написать интеграционные тесты, тупо проверив md5 результата для диапазона чисел, и внеся ожидаемый результат как фикстуру в тест.
по крайней мере так делаю в своём коде — никаких проблем не имею. пишут тест для каждой подозрительной строчки.
можно тестировать псевдослучайными числами (взять 100_000 числел) только последовательность должна быть одна и та же всегда.
perl -MDigest::MD5=md5_hex -e'print md5_hex(join(",", map { $_ ^ 41262125215 } map { $_ - 1, $_ + 1, $_ - 100, $_ + 100 } map { 2**$_ } map { $_, $_ -1 } (32, 53)))'
perl-5.8.8-64int ========== bb45f30d7271d4e70f8ea43240215e69 perl-5.8.8 ========== d28324accda448de64f77fd2d8739140
Когда я увидел, что в моем первом почтовом ящике mail.ru была уничтожена вся переписка старше нескольких лет, включающая милейшие письма типа переписки с первым работадателем, и другие памятные моменты, я был в полнейшем шоке. Второе десятилетие 21 века… Как?! А потом узнал, что почту в двух других моих ящиках, куда не заходил год, убили под чистую.
Рад, что внедряете российскую изюммнку в современные сервисы. Всяческих успехов и лучей добра вам!!!
Рад, что внедряете российскую изюммнку в современные сервисы. Всяческих успехов и лучей добра вам!!!
За лучи спасибо, конечно.
Мы действительно удаляем письма из ящика, если он не используется в течении длительного времени (в него нету заходов, с него не забирается почта).
Мы действительно удаляем письма из ящика, если он не используется в течении длительного времени (в него нету заходов, с него не забирается почта).
Эм, а как быть с массивом переписки на основных ящиках? Ну скажите, что я просто не заметил папку «Архив», где они все благополучно складированы…
И посоветуйте, как часто нужно заходить на почту, чтобы ящик не удалили?
И посоветуйте, как часто нужно заходить на почту, чтобы ящик не удалили?
Так, стоп. Почта цела на основном. Видимо был глюк, тогда менялся итерфейс ящика и листалка заканчивалась где-то на 2007 году. Мои извинения.
Добавлю вам за это своих лучей.
Подходил к концу 2013 год…
Планируется ли изменение бизнес-модели почты mail.ru с заработка на спаме на другие способы монетизации?
А чем обусловлен выбор именно 5.10? Он точно так же снят с поддержки много лет назад как и 5.8. Почему не мигрировали на 5.14 или 5.16, глобальных проблем миграции, по сравнению с 5.10, там не должно было добавиться.
Я думаю тем что он в CentOS6 и поддерживается RHEL (по крайней мере они должны делать security фиксы, а так же изредка портируют куски кода из остальных версий perl, что делает его не совсем 5.10).
Можно было и сразу на 5.18, только лучше же маленькими шажками.
Опять же можно было ещё уменьшить шаг и попробовать 5.8.8 64bit (только обязательно из CentOS5, ведь это фактически не 5.8.8 а нечто среднее между 5.8.8 и 5.8.9)
Можно было и сразу на 5.18, только лучше же маленькими шажками.
Опять же можно было ещё уменьшить шаг и попробовать 5.8.8 64bit (только обязательно из CentOS5, ведь это фактически не 5.8.8 а нечто среднее между 5.8.8 и 5.8.9)
полная поддержка CentOS 5 прекращается в 2014 году
So wut? Веб-фронтенды не торчат голым апачем наружу (к слову, разве первый апач не перешел уже в неподдерживаемые пакеты, собираемые вручную давным-давно?), поэтому практически все проблемы ядра не беспокоят, апач уже самосборный, про перл см ниже.
Perl 5.10 на некоторых задачах показывает 30% прирост скорости
Опять-таки, если это так важно, то можно организовать свой репозиторий с нужной версией perl.
32-битная архитектура в XXI веке несколько отстает от желаемого
Отстает от чего? Конечно, для всяких кешей вроде memcached неплохо иметь возможность адресовать более 3гб с процесса, но таких процессов можно запустить несколько — заодно и ядра простаивать не будут.
Apache 2
Неужели жизнь на apache 1.x из собственных репозиториев была бы сложнее, чем переписывание кучи все, завязанного на этот самый первый апач?
Ну и самый главный вопрос: зачем на веб-фронтах 64 бита, когда можно поставить 32-битную систему, или хотя бы 32-битные perl и apache2? Адресовать огромные объемы памяти на фронтах реально ни к чему, баги связанные с размерностью целых числе в перле не пришлось бы огребать, потребление памяти было бы чуть ниже при неизменной скорости работы?
Это я не к тому, что не надо ничего было делать — молодцы, что проапгрейдились, однако из рассказа кажется, что апгрейд шел по пути: сначала создаем себе проблемы, потом мужественно их решаем.
Ну если таким путём следовать, то можно, ещё через 5-7 лет, полностью закрыть компанию в связи с невозможностью разобраться в древнем софте и мигрировать вообще.
фикс этих багов является ликвидацией технического долга же, что же в этом плохого.
баги связанные с размерностью целых числе в перле не пришлось бы огребать,
фикс этих багов является ликвидацией технического долга же, что же в этом плохого.
полная поддержка CentOS 5 прекращается в 2014 году
Кстати всё же в 2017 году wiki.centos.org/FAQ/General#head-fe8a0be91ee3e7dea812e8694491e1dde5b75e6d и RHEL5 и CentOS5, а платная RHEL5 в 2020
Статья претендует на самое скучное из всех возможных названий, что подтверждается фактом полного отсутствия кода. Где код?!?
Ха, perl. Молодцы. Значит, мы не одни такие, это радует =)
У самого порядка 50 сервисов различной степени сложности, всё размазано по ~ 30 серверам… Где-то год назад ушли от использования системного перла, собираем свой, в отдельную папочку, там же все нужные либы, и свои пакеты, и пр. Зато теперь никакое обновление ОС не затронет работу наших скриптов.
Мы даже опакетили вспомогательное ПО — lighttpd, redis, и тп. Теперь почти любой наш внутренний сервис можно поднять практически одной командой yum из своего репозитория — всё необходимое, скрипты и либы поставятся по зависимостям :]
У самого порядка 50 сервисов различной степени сложности, всё размазано по ~ 30 серверам… Где-то год назад ушли от использования системного перла, собираем свой, в отдельную папочку, там же все нужные либы, и свои пакеты, и пр. Зато теперь никакое обновление ОС не затронет работу наших скриптов.
Мы даже опакетили вспомогательное ПО — lighttpd, redis, и тп. Теперь почти любой наш внутренний сервис можно поднять практически одной командой yum из своего репозитория — всё необходимое, скрипты и либы поставятся по зависимостям :]
[lol]
Mail Guard и прочие Mail *** теперь тоже работают только на x64?
[/lol]
Mail Guard и прочие Mail *** теперь тоже работают только на x64?
[/lol]
Не за горами CentOS 7, есть ли планы насчёт него?
Да вы что, тут коечто позначительней случилось — почта на км.ру перешла на веб 2,0 интерфейс. Вот событие — я думал ети ребята навечно застряли в епохе первого веба, аннет — ни шатко ни валко — а обновили.
А чем пользовались до пупета, cfengine?
А подстроку в строке обязательно регэкспом искать? Функция index недостаточно хороша?
А зачем index? Регэксп недостаточно хорош?
Скорость же.
Разница в скорости меньше 10%, проигрыш в скорости ничтожен по сравнению с любой операций ввода-вывода.
В таком коде подавляющее большинство использует регэксп, он понятнее выглядит, его легче модифицировать если что-то понадобится изменить в коде.
В таком коде подавляющее большинство использует регэксп, он понятнее выглядит, его легче модифицировать если что-то понадобится изменить в коде.
Писать index вместо регекспа там, где это возможно — хорошая привычка.
P.S.: только что померил и получил разницу в 28%.
P.S.: только что померил и получил разницу в 28%.
наоборот, плохая привычка.
а по поводу бенчмарка, 10% максимум.
а по поводу бенчмарка, 10% максимум.
use warnings;
use strict;
my $text = 'hello world';
sub index_find {
my $x;
for (1..100) {
$x = index($text, 'world') >= 0;
}
}
sub regex_find {
my $x;
for (1..100) {
$x = $text =~ /world/;
}
}
use Benchmark qw( cmpthese );
cmpthese -1, {
'index' => \&index_find,
'regex' => \®ex_find,
};
Хорошая попытка, но всё равно нет, спасибо
Раз это крайняя запись, посвященная почте, то спрошу здесь. Известно ли что-нибудь о реализации трехколоночного веб-интерфейса, наподобие того, что у «Яндекс.Почты» или Gmail?
Коллеги, переход на x64 Вашей почты — это здорово. Но лучше бы Вы сделали корректной работу своих анти-спам фильтров + оперативной и качественной работу Вашей поддержки по abuse@. Это Вашим клиентам и коллегам по цеху было бы куда полезнее, чем переход на x64.
Я представляю сервис рассылок Smartresponder.ru и мы в числе самых крупных отправщиков почты в Рунете. Сейчас у нас 60% рассылок уходит на адреса Mail.ru. В прошлом году в середине Января Mail.ru заблокировало полностью все наши отправляющие рассылки сервера, а теперь уже в новом 2014 году в тот же период — Ваш антиспам отдел снова повторил бан большей части наших отправляющих серверов.
Учитывая тот факт, что мы соблюдаем все Ваши правила для массовых рассылок, знаем их уже наизусть, постоянно следим за нашей репутацией (нажатия на «спам» через postmaster, sender score), то такие Ваши действия просто обескураживают и наводят на печальные мысли о происходящем в отделе антиспама Mail.ru.
Примите пожалуйста меры по этой ситуации.
Все описано в тикете к Вам в abuse@ - Ticket#2014010921040847
Я представляю сервис рассылок Smartresponder.ru и мы в числе самых крупных отправщиков почты в Рунете. Сейчас у нас 60% рассылок уходит на адреса Mail.ru. В прошлом году в середине Января Mail.ru заблокировало полностью все наши отправляющие рассылки сервера, а теперь уже в новом 2014 году в тот же период — Ваш антиспам отдел снова повторил бан большей части наших отправляющих серверов.
Учитывая тот факт, что мы соблюдаем все Ваши правила для массовых рассылок, знаем их уже наизусть, постоянно следим за нашей репутацией (нажатия на «спам» через postmaster, sender score), то такие Ваши действия просто обескураживают и наводят на печальные мысли о происходящем в отделе антиспама Mail.ru.
Примите пожалуйста меры по этой ситуации.
Все описано в тикете к Вам в abuse@ - Ticket#2014010921040847
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Переход Почты Mail.Ru на 64-битную архитектуру: как это было