Попробуйте вместе с ab использовать так же и wrk. Например: wrk -t100 -c500 -d30s http://127.0.0.1:8000/. С помощью wrk можно задать продолжительность тестирования, а так же написать на lua собственный сценарий.
В плане Go можно попробовать использовать: https://github.com/valyala/fasthttp, https://github.com/celrenheit/lion, https://github.com/labstack/echo
Потребление памяти и цпу в связке echo + fasthttp + quicktemplate должно быть ниже. Для REST-а можно заменить encoding/json на ffjson.
В Go 1.6 планировщик более оптимизирован. Если лень ставить руками, то можно использовать gvm (https://github.com/moovweb/gvm). Таким образом сравнить производительность в разных версиях языка.
Было бы правильнее, если бы он восстановил все из копии, после воспроизвел баг, и записал бы к примеру скринкаст. Не в защиту, но с точки зрения тестирования — действительно нужно доказать наличие бага и воспроизвести его независимо. В итоге и он не доказал, и они воспроизвести не смогли.
На лаптопе — полностью согласен. Достаточно стабильно и консервативно. Если же говорить как минимум о стейджинг серверах, то это очень дешевый вариант создания контейнеров за несколько секунд. Недавно внедрил в проект LXC (опционально) в качестве замены VirtualBox-у. Речь идет о Vagrant-е. Разработчики использующие Linux ликуют:)
Может кому так же будет полезна маленькая тулза, для доставки списка избранного для отложенного чтения на Kindle. Репозиторий на GitHub. Сам Kindle не обязателен.
Согласен, можно и так. Но дело в том, что Vagrant у меня не всегда и не везде. Куда проще порою иметь исходный эталонный образ, с которого просто создается машина или группа машин. При этом не заморачиваясь с боксами вагранта. 2-3 клика у меня уже клоны образов. Тем более на прошках SSD и так является узким местом в плане места. Потому эталонный образ оставляет всегда за собою 200-400 Мб, а в клоне только то, что доустановил поверх, и не отъедают место на харде. Здесь уже идет совокупность разных факторов (не говоря уже о переносимости).
Мне очень не нравится в Parallels Desktop то, что никак нельзя виртуальные машины сгруппировать. Я к примеру работаю с кластерами и складываю все ноды в группу, названную по смыслу. Далее запускаю разом все машины в группе или же останавливаю их. Есть возможность сделать образы или же сбросить состояния, ну и тд. Все это к тому, что мне как разработчику неудобно пока еще пользоваться Parallels. В этом отношении пока еще VirtualBox со всеми его минусами более юзабильный для админов и разработчиков. Жду подобных возможностей и в Parallels.
Меня сегодня расширение заспамило алертами о том, что старая версия не поддерживается. В итоге просто отключил. Одного алерта на мой взгляд вполне достаточно.
У django-sphinx есть множество форков, которые работают с dj1.4+. Например этот.
Меня больше смущает другой вопрос: Почему вы не используете к примеру Real-time indexes?
В IT не принято подкидывать монетку при выборе стека. Нужно как минимум аргументировать и взвесить все варианты разумно.
1. В данной статье нет замеров производительности, нет реальных доводов, кроме тех, что официальная батарейка не работает.
2. Темная магия — это плохо. Зачем когда есть CheckInstall ну и dpkg build?
В смысле, шелл-провиженинг с командой, которая запускает Ansible на целевом хосте?
Именно так. Сначала ставим ansible и после запускаем.
Разве что провиженить так что-то кроме dev-окружения на вагрантовской виртуалке не получится (ну, или получится, но будет решительно неудобно).
Почему же не получится? С той же VM можно запустить ansible на прод. Делается в 2 команды.
Ну и да, целью тут было скорее поделиться опытом, а не рассказать, как надо делать. Потому что если бы я что-то такое прочитал в самом начале, то вряд ли бы пошел тем путем, которым пошел :-)
Теперь можете попробовать такой вариант и это спасет кучу времени вам и другим разработчикам.
В плане Go можно попробовать использовать: https://github.com/valyala/fasthttp, https://github.com/celrenheit/lion, https://github.com/labstack/echo
Потребление памяти и цпу в связке echo + fasthttp + quicktemplate должно быть ниже. Для REST-а можно заменить encoding/json на ffjson.
В Go 1.6 планировщик более оптимизирован. Если лень ставить руками, то можно использовать gvm (https://github.com/moovweb/gvm). Таким образом сравнить производительность в разных версиях языка.
Меня больше смущает другой вопрос: Почему вы не используете к примеру Real-time indexes?
В IT не принято подкидывать монетку при выборе стека. Нужно как минимум аргументировать и взвесить все варианты разумно.
1. В данной статье нет замеров производительности, нет реальных доводов, кроме тех, что официальная батарейка не работает.
2. Темная магия — это плохо. Зачем когда есть CheckInstall ну и dpkg build?
Именно так. Сначала ставим ansible и после запускаем.
Почему же не получится? С той же VM можно запустить ansible на прод. Делается в 2 команды.
Теперь можете попробовать такой вариант и это спасет кучу времени вам и другим разработчикам.