Рад представить вашему вниманию новую версию расширения для хабры (предыдущий топик), которое научилось показывать вопросы и ответы (QA), а также оповещать обо всех событиях в них.
И самое главное — теперь можно отвечать прямо в расширении, в том числе и в Опере.
Теперь можно создавать личную переписку и удалять её.
Исправлено много багов, сделано много улучшений и оптимизаций.
Понадобилось как-то в проекте сделать автообновление для клиентского приложения. Так как работало оно с отечественными криптопровайдерами, доступ к которым проще получить из .Net, написано оно было на IronPython. При этом C# выбран не был, так как на стороне сервера уже активно использовался python и сильно переучиваться не хотелось.
Казалось бы всё просто. Был набросан скрипт, который вычисляет md5-хеши для файлов входящих в состав приложения, сводит всё в один файл со строками вида “относительный путь”:”md5” и выкладывает в директорию раздачи статики nginx. Клиентское приложение при запуске забирает файлик, прогоняет аналогичный скрипт, и сверяет полученный результат с эталоном.
Но тут обнаружилась маленькая деталь. В IronPython скрипт выполнялся в несколько раз медленнее. И это на достаточно быстром железе. У пользователя же оно могло быть значительно слабее. Началась оптимизация, в ходе которой родилась мысль провести сравнение производительности Python и IronPython на этом примере. В статье, соответственно, рассматриваются три отдельных результата: для Python, IronPython и IronPython с адаптированным скриптом.
Результаты под катом.
Читать полностью »
Понадобилось как-то в проекте сделать автообновление для клиентского приложения. Так как работало оно с отечественными криптопровайдерами, доступ к которым проще получить из .Net, написано оно было на IronPython. При этом C# выбран не был, так как на стороне сервера уже активно использовался python и сильно переучиваться не хотелось.
Казалось бы всё просто. Был набросан скрипт, который вычисляет md5-хеши для файлов входящих в состав приложения, сводит всё в один файл со строками вида “относительный путь”:”md5” и выкладывает в директорию раздачи статики nginx. Клиентское приложение при запуске забирает файлик, прогоняет аналогичный скрипт, и сверяет полученный результат с эталоном.
Но тут обнаружилась маленькая деталь. В IronPython скрипт выполнялся в несколько раз медленнее. И это на достаточно быстром железе. У пользователя же оно могло быть значительно слабее. Началась оптимизация, в ходе которой родилась мысль провести сравнение производительности CPython и IronPython на этом примере. В статье, соответственно, рассматриваются три отдельных результата: для CPython, IronPython и IronPython с адаптированным скриптом.
Результаты под катом.
Читать полностью »
Наглухо застряв в пробке за рулем машины, теоретически способной развивать скорость более 200 кмч, и глядя, как меня обгоняют велосипедисты на трехколесных велосипедах, я задумалась… нет, не о том, как пересадить всех на велосипеды, и не о решении транспортных проблем человечества с помощью телепортации, а… о процессорах Intel Core и Intel Atom. А именно — Atom по сравнению с Core — это, фактически, мотороллер по сравнению с автомобилем. Он потребляет меньше топлива и стоит заметно дешевле. Но зато и скорость скутера столь же заметно уступает авто (несмотря даже на способы «разогнать» мотороллер выше заводских установок). Но, все же, в пробках или на узких улочках скутер оказывается быстрее. Недаром скутер получил свое название от английского «to scoot» — удирать, так как успешно использовался английскими подростками для спасения от полиции.
Теперь вернемся к CPU. Заменим «топливо» на «электричество», а «скорость» на «производительность», и получим полную аналогию поведения Inel Atom и Intel Core. Но тогда разумно предположить, что существуют такие «пробки»и «закоулки», в которых Atom обгонит Core. Давайте их поищем.
От переводчика: Это перевод заметки товарища по имени Steve Souders, который очень плотно занимается вопросами производительности веб-сайтов и даже написал пару неплохих книг на эту тему.
Вчера я проводил семинар в Google Ventures для некоторых из инвестируемых ими компаний. Я не знал насколько подготовленной в вопросах производительности будет аудитория, так что я сделал обзор вопросов, связанных с производительностью, начиная с первых моих выступлений в 2007 году. Уже несколько лет я не рассказывал о методах улчшения производительности, описаных в моем блоге "High Performance Web Sites". Я прошелся по таким вещам, как Меньше HTTP-запросов, Добавление заголовка Expires и Gzip.
Но мне надо было вернуться еще дальше. Думая о тех временах, когда еще не существовало конференции Velocity и самого понятия WPO, я решил, что должен пояснить почему я занялся именно клиентской оптимизацией. Я нашел слайды, поясняющие «Золотое правило производительности»: 80-90% времени ожидания пользователем занимает работа браузера.
На слайдах были данные по времени отработки сервера и клиента для популярных сайтов, но данные были устаревшими и ограниченными, так что я решил обновить их. Вот, что получилось.
Довольно часто на семинарах или при аудите существующей у заказчика виртуальной среды мне приходилось слышать упреки: «Виртуализация тормозит», «Мы попробовали перевести сервер в виртуальную среду, и он встал», «Виртуальные серверы работают медленнее физических». При этом девять из десяти таких проблем с «торможением» виртуальных серверов решались простой оптимизацией устройств в составе виртуальной машины.
Большое количество вопросов, как повысить быстродействие виртуальной среды, побудило меня к написанию небольшого FAQ по оптимизации виртуальных машин на основе VMware vSphere – платформы используемой большинством наших корпоративных клиентов. При этом хочется отметить, что для решений на основе Hyper-V и Xen Server корректный выбор устройств также способен ускорить работу виртуальных серверов.
Анализ некоторых python ORM на непроизводительные расходы
При разработке приложения на python django, я столкнулся с его неадекватным торможением.
После нескольких попыток улучшить довольно сложные алгоритмы расчетов, я обратил внимание, что существенные улучшения этих алгоритмов приводили к весьма скромному результату — из чего я сделал вывод, что узкое место вовсе не в алгоритмах.
Последующий анализ показал, что действительно, основным непроизводительным потребителем ресурсов процессора оказался django ORM, который был использован для доступа к данным, необходимым при расчетах.Читать полностью »
Краткий анонс
Собирался добавить пару предположений на счет авторизации и регистрации на сайте, но то ли от недосыпания, то ли от многочисленных выпитых сегодня чашек кофе меня потянуло в дебри. Набросал некоторые заметки. Возможно кто-то из Вас найдет что-то новое для себя, возможно кто-то подскажет новое правило для кого-то, возможно кто-то поправит меня тем самым дав и мне урок, и другим. Ниже идут некоторые заметки работы с БД, еще ниже уже несколько заметок про работу самого сервера и т.д.
Читать полностью »
Рад представить вашему вниманию новую версию расширения для хабры (предыдущий топик), которое научилось показывать вашу переписку с другими читателями, а также оповещать вас о новых личных сообщениях.
Также был доработан блок по приёму хабратопиков (для уменьшения трафика) и исправлено немного общих багов.
Читать полностью »
С тех пор,3 как в октябре 2010 среди разработчиков OpenOffice.org произошел раскол и от проекта отделился форк, названный LibreOffice, перед приверженцами opensource встал вопрос — какой же продукт теперь использовать?
Многие принципиально стали переходить именно на LibreOffice, назло Oracle, которая, по мнению большинства основных разработчиков, излишне контролировала развитие продукта. LibreOffice пообещал пользователям более динамичное развитие (новые версии действительно выходят чаще, чем у предка), разработку независимым сообществом, а так же предоставление программистам полной свободы без ограничений.Однако, это все лирика. Главным недостатком OpenOffice всегда была производительность, для того же госсектора, переходящего на opensource, с их гигантским парком старых машин — это главный критерий выбора офисного пакета.
В последних версиях LibreOffice разработчики заявляли о существенных оптимизациях кода и увеличении производительности пакета, но так ли все радужно?
Читать полностью »
