H2o: Отсутствует задержка (сон, Thread.sleep) в mruby?

Созданный на 2 мая 2017 · 6Комментарии · Источник: h2o/h2o

Я написал обработчик mruby, который использует http_request, чтобы мой кеш оставался свежим в wordpress, но поскольку я не знаю никакого способа усыпить обработчик, и он выполняет слишком много запросов, он не выполняет запрос, потому что php не может справиться.

Есть ли способ заснуть на несколько секунд в воде с помощью mruby (я попытался установить собственное расширение Thread mruby, но я не могу получить дату для ответа вне потока)?

Ошибка:
[lib/handler/fastcgi.c] in request:/index.php/tag/science:connection failed:failed to connect to host

Код:

if request_is_from_self and links_file_exist and req_is_get
    links = `php #{links_filepath}`

    for link in links.split(' ') do
        req = http_request(link)
        _, _, _ = req.join
    end
end

enhancement mruby

Источник

taosx

Все 6 Комментарий

привет @taosx
Я несколько сомневаюсь, что это действительно php, который не успевает.
вы отправляете http-запросы собственному экземпляру h2o, который затем запускает fastcgi?

не уверен, что вы сделали это намеренно, чтобы имитировать паузы, но из того, что я читал, вы присоединяетесь к каждому запросу последовательно. Идея заключается в том, что запросы отправляются параллельно, поэтому вы начинаете присоединяться только после того, как все запросы будут запущены.

можешь попробовать что-нибудь вроде

links.split(' ').map{|l| http_request }.to_a.map{|r| r.join}

и выложить более подробное описание ошибки?

также, если это всегда одни и те же ссылки и они более или менее статичны, вы можете быстро реализовать дешевый кеш памяти.

yannick 2 мая 2017

👍1

Я считаю, что ваш код не предоставляет аргумент для http_request, я изменил его так:
links.split(' ').map{|l| http_request(l) }.map{|r| r.join}
но он по-прежнему работает хуже, чем код, который я опубликовал выше.
Я решил решение, установив и активировав opcache на php, и теперь время, необходимое для выполнения всех запросов, упало с 27 секунд до 3,1 секунды без ошибок. Используя ваш код, вы получите 4 секунды.

После того, как я проведу еще несколько тестов, я хотел бы открыть исходный код всего кода для моего сайта wordpress с помощью h2o, который кеширует страницы каждые 2 минуты, предварительно сжимает как gzip, так и brottli при максимальных настройках и обслуживает из кеша. Пока что люблю h2o, спасибо всем, кто внес вклад в h2o !!

В будущем мне бы хотелось увидеть больше скриптовых функций для h2o, таких как openresty, но основанных на h2o: D

taosx 2 мая 2017

@taosx извини. я забыл важную часть: .to_a

links.split(' ').map{|l| http_request }.to_a.map{|r| r.join}

просто из любопытства, можешь попробовать еще раз. и сколько запросов вы делаете / насколько велик массив ссылок?

yannick 2 мая 2017

@yannick Я попробовал еще раз, мне пришлось изменить http_request, чтобы передать его аргумент (l).
Скорость упала до 3,06 сек: D и иногда до 2,9+ при прогреве кеша.
В массиве ссылок 41 элемент (aws ec2 t2.micro).

Каждый раз, когда я добавляю еще один пост, я получаю 1 ссылку из самого сообщения + ~ 5 ссылок из добавленных тегов ...
Думаю, в ближайшее время у меня возникнет небольшая проблема. Думаю, что сейчас я откажусь от mruby и выберу другой подход в будущем.

Как вы думаете, я мог бы использовать h2o с mruby в качестве обратного прокси-кеша для wp, я считаю, что это возможно.

taosx 2 мая 2017

👍1

кажется, что вы выходите на php через links = php #{links_filepath} . это, вероятно, очень медленно, вы удалили то время?
только для воды t2.micro должно быть в порядке, но если вы также запустите PHP-материал на этой машине, они будут конкурировать за один процессор, и производительность упадет еще больше. так что, по крайней мере, для тестирования я бы взял что-то вроде c4.large или c4.xlarge.

да, кеширование через mruby должно быть возможно, либо вы делаете это в памяти, либо используете redis (который в настоящее время все еще нуждается в патче, но должен быть вскоре объединен, см. https://github.com/h2o/h2o/pull/1152)

yannick 3 мая 2017

👍1

Это интересное обсуждение!

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