Разработчик независимой от Google открытой Android-прошивки для сотовых телефонов и планшетов CyanogenMod, Cyanogen, рассказал сегодня, что закрыл очередной раунд финансирования, по результатам которого привлек $80 млн, пишет re/code.
Инвесторами выступили крупнейшие участники рынка, такие как Twitter Ventures, Читать полностью »
Для тех кто еще не знаком с тестами веб фреймворков которые регулярно проводит Techempower очень рекомендую сделать это сейчас заглянув по ссылке www.techempower.com/benchmarks/
Пока что для широкого доступа опубликованы только результаты 6-го раунда. С этого времени добавились несколько новых ферймворков к каждой из платформ (кстати включая и PHPixie) и разработчики уже больше двух месяцев ждали следующего раунда, который вот-вот будет иметь место.
Прочитал статью о разгоне производительности операций вставок в СУБД Oracle при помощи транзакций на Java. Так как в данный момент я работаю с postgresql, то решил проверить, сколько выдаст эта СУБД в связке с голангом.
Используемый стек: golang-1.1.2 + postgresql-9.3.1.
Для запуска программы понадобится голанговский драйвер для postgresql. Я пользуюсь драйвером github.com/lib/pq, который установил при помощи команды go get -u github.com/lib/pq.
Читать полностью »
Заинтересовал меня топик о многопоточности в Go: habrahabr.ru/post/195574/.
Внимательно перечитал автора и комментарии сообщества и решил, что тема все же раскрыта не полностью.
В дальнейшем, дабы не было непонимания, попрошу принять, что здесь и далее термин «поток» используется исключительно в значении «thread», а не в значении «stream». Спасибо.
Читать полностью »
Люблю Go, люблю его хвалить (бывает даже, привираю слега), люблю о нем статьи. Прочитал статью “Go: Два года в продакшне ”, потом комменты. Стало понятно, на хабре — оптимисты! Хотят верить в лучшее.
Читать полностью »
В интернете не так много статей о производительности GridFS, вот одна из них Serving files out of GridFS которая показывает, что отдача файлов из GridFS медленнее чем с диска в 6 раз.
Но в той статье есть недочет — в тестировании обращение идет к одному файлу, а при этом файл кешируется на уровне nginx либо файловой системы что дает отрыв по сравнению с GridFS. Да и неплохо проверить свежий GridFS, 3 года прошло как никак.
Поэтому я решил провести собственное тестирование, с обращением по разным именам файлов.
Есть 52 тыс файлов — постеры к фильмам, общий объем 2Гб, средняя картинка весит 40кб. Копия файлов на ext4, копия в GridFS.
Виртуалка 512Мб с 1 ядром. Ubuntu server 12.04 LTS 64bit, настройки Nginx/1.4.1 стандартные.
Тест рассчитан на low-cost сервер, для мощных серверов результаты будут другие.
Способы отдачи файлов:
1) Nginx — статика
2) Gevent через nginx
3) 2 x Gevent через nginx (балансировка)
4) Gevent напрямую
5) Gevent через nginx (unix socket)
для пунктов 2-5 использовался http сервер на Python + Gevent который отдавал файлы из GridFS
Способы нагрузки:
1) ol, t2 — Обращение к одному url, 2 потока
2) ol, t10 — Обращение к одному url, 10 потоков
3) t2 — Обращение к разным url, 2 потока
4) t10 — Обращение к разным url, 10 потоков
При работе с Amazon многое остается за кадром. Для обычного пользователя это даже хорошо, ему нужен работающий сервис и не имеет значение, как этот сервис реализован. Но для тех, кто проектирует системы для Amazon или других облачных провайдеров это может быть проблемой. Некоторые внутренние аспекты работы выясняются при общении с тех. поддержкой, но в большинстве случаев для лучшего понимания приходится проводить различные тесты и эксперименты.
Возьмем, к примеру, производительность сети. Гарантирует ли Amazon определенную пропускную способность сети для любой машины или нет, как зависит скорость сети от ресурсов сервера, от региона или времени суток. Скажу сразу, что поддержка Amazon настоятельно рекомендует использовать машины больших размеров, если скорость сети является важным критерием и то, что максимально скорость 1G/s. Но всё всегда лучше проверить на практике.
Читать полностью »
Мне предстоит проект, модуль которого будет большую часть времени работать с другим сервером, отправляя ему GET запросы.
Я провел тесты чтобы определить каким способом получать страницу будет быстрее (в рамках предполагаемых технологий проекта).
Первые 3 теста: каждым из способов выполнялось по 50 запросов подряд к одному сайту.
Прим. переводчика: перевод выполнялся для erlanger.ru. Заранее приношу извинения за возможные неточности.
Этот бенчмарк производит следующие действия:
Тестовая программа создает 20 колец по 50 актеров в каждом. Токен с начальным значением 10 000 передается по кольцу и его значение уменьшается на единицу при каждой итерации. Клиент, получивший токен, обязательно передает его следующему клиенту в кольце и завершает работу, если значение токена равно 0.
Читать полностью »
Переписывал на работе кусок одного сервиса с Python на Erlang. Сам сервис занимается тем, что скачивает по HTTP значительное количество однотипных HTML страниц и извлекает из них некоторую информацию. Основная CPU нагрузка сервиса приходится на парсинг HTML в DOM дерево.
Сперва захотелось сравнить производительность Erlang парсера mochiweb_html с используемым из Python lxml.etree.HTML(). Провел простейший бенчмарк, нужные выводы сделал, а потом подумал что неплохо было бы добавить в бенчмарк ещё парочку-другую парсеров и платформ, оформить покрасивее, опубликовать код и написать статью.
На данный момент успел написать бенчмарки на Erlang, Python, PyPy, NodeJS и С в следующих комбинациях:
В тесте сравниваются скорость обработки N итераций парсера и пиковое потребление памяти.
Интрига: кто быстрее — Python или PyPy? Как сказывается иммутабельность Erlang на скорости парсинга и потреблении памяти? Насколько быстра V8 NodeJS? И как на всё это смотрит код на чистом C.
Читать полностью »
