Pull to refresh
91
0
Leonid Bugaev @buger

User

Send message

Я думаю резонный вопрос, почему вы решили реализовать все сами, а не использовать множество из текущий решений вроде Kong или Tyk?

Я автор GoReplay, спасибо за упоминание :)


Да, для вашей цели post_action пожалуй неплохое решение.


Стоит добавить что задача добавления uuid в GoReplay решается довольно просто с помощью middleware https://github.com/buger/goreplay/tree/master/middleware


Например такая NodeJS программа


var uuidV4 = require('uuid/v4');
var gor = require("goreplay_middleware");
gor.init()

gor.on('request', function(req) {
   req.http = gor.setHttpHeader(req.http, "X-Request-ID", uuidV4()); 
   return req;
})

Главный плюс GoReplay в данном случае что это не прокси, он просто анализирует входящий траффик. Не нужно беспокоится что из-за ошибки в прокси будут проблемы у бользователя. Но nginx в этом плане конечно очень надежный.


Ну и конечно GoReplay также может записывать и ответы сервера, и при их проигрывании на другую среду, можно сравнивать ответы оригильные и новые.


Как то так https://goreplay.org :)

У нас немного другая нагрузка, но результат тестирования схожий. Еще много проблем с индексами, строятся гораздо медленнее, и пару раз попадали на segfaults при их постройке. При подаче багрепорта, ответили только через неделю…

В общем очень сыро, и с поддержкой пока не очень.
На самом деле есть очень простой способ проверить, запустить вашу программу с --race параметром.
blog.golang.org/race-detector
Многопоточность встроена в net/http пакет. На каждый запрос создается новая goroutine: golang.org/src/pkg/net/http/server.go?s=43127:43198#L1564
Ну при большой нагрузке тут явно будут проблемы. Так допустим счетчик opencntr не будет работать как надо, он не thread-safe. Либо используйте mutex либо sync/atomic, еще лучше на channels переписать. Но как я уже сказал на небольшой нагрузке эти проблемы не будут заметны.

UPD: не заметил комментарий что цель считать примерно
Тут варианта два:
1) Индексации AJAX интерфейсов (если страницу запрашивает бот, система отдает ему HTML отрендеренный в PhanotmJS).
2) Или для интеграционных тестов.
Это совсем не проблема, темболее если аутсорсить CI на сервис типа circleci.com (рекомендую).
Купите дешевый VPS и поставте туда btsync для linux :)
Тоже верно, поживем увидим :)
Спасибо за развернутый комментарий.

Да, такая схемя явно подойдет не под любое приложение. Staging действительно должен иметь актуальную версию, а ошибки которые связаны с тем что в базе не найдена запись прийдется обрабатывать (что не так уж и плохо).

Плюс я старался сделать акцент на том что не стоит путать нагрузочное тестирование с повседневным. Load testing не запускается на каждое изменение (обычно), и имеет определенные минусы, о чем упоминается в статье.

Например как выглядит workflow обычно, разработчик делает в своей ветке изменение, заливает его на staging и тестирует руками. Так вот Gor это скорее дополнение к тестированию руками.
Ну формально вам ничего не мешает написать свою небольшую прослойку, которая будет получать трафик от Gor, и запускать эти запросы в phontomjs. Что то типа reverse proxy.
Нет, просто посекундная статистика о количестве запросов, общая и в контексте статус кода. Так будет понятней: github.com/buger/gor/blob/master/replay/request_stats.go#L47
Хотя я предвижу что Gor вполне можно будет использовать и для нагрузочного тестирования, особенно если production с большим трафиком.
На данный момент есть зачатки статистики, но пока просто вывод в консоль.
В следующей версии планирую значительно улучшить эту часть.

Я решил не включать расширенную статистику в этот релиз, так как эта программа не для нагрузочного тестирования, а повседневного.
Вполне вероятная история
Чем то похоже на эту тему coderwall.com/p/5cafjw :)

Ну на самом деле они просто выбрали неправильный инструмент. Если нужна производительность то нужно использовать сервера с неблокирующим IO, либо параллелизировать через акторы, нарпимер celluloid.io/. А лучше все вместе. Ну и конечно же jRuby и Rubinius с нормальными threads.

На своем проекте мы используем Goliath и он работает очень шустро.

Ссылки в тему:

celluloid.io/
github.com/celluloid/reel

goliath.io
github.com/mperham/rack-fiber_pool

jruby.org/
rubini.us/
Создайте бранч gh-pages, тогда проект станет доступен по адресу PaulSmith220.github.com/htrack
1
23 ...

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity