Char[] to Byte[] для оптимизации вывода в Интернете (java)

Я просто нашел в презентацию обмена опытом от infoq. Он утверждает, что если вы преобразуете строку в byte[] в сервлете, это увеличит QPS (запросов в секунду?). В примере кода показано сравнение:

До

private static String content = “…94k…”;
protected doGet(…){
response.getWrite().print(content);
}

После

private static String content = “…94k…”;
Private static byte[] bytes = content.getBytes();
protected doGet(…){
response.getOutputStream().write(bytes);
}

Результат до

  • размер страницы (К) 94
  • максимальное количество запросов в секунду 1800

Результат после

  • размер страницы (К) 94
  • максимальное количество запросов в секунду 3500

Кто-нибудь может объяснить, почему он был оптимизирован? Я верю, что это правда.

ОБНОВЛЕНИЕ

На случай, если я введу в заблуждение. Мне нужно объяснить, что в оригинальной презентации это используется только в качестве примера. Таким образом они рефакторят двигатель скорости. НО этот исходный код немного длинный.

Собственно в презентации не подразумевалось, как они это делают подробно. Но я нашел свинец.

В ASTText.java они кэшировали byte[] ctext вместо char[] ctext , что значительно повышает производительность~!

Так же, как и выше. В этом есть смысл, верно?

(НО, безусловно, они также должны провести рефакторинг интерфейса Node. Writer не может записывать byte[]. Что означает использование вместо этого OutputStream!)

Как советовал Perception, на самом деле Write finally делегирует StreamEncoder. И запись StreamEncoder сначала изменит char[] на byte[]. А затем делегируйте это OutputSteam для реальной записи. Вы можете легко обратиться к исходному коду и доказать это. Учитывая, что метод рендеринга будет вызываться каждый раз для показа страницы, экономия средств будет значительной.

StreamEncoder.класс

 public class ASTText extends SimpleNode {
            private char[] ctext;
        /**
         * @param id
         */
        public ASTText(int id) {
            super (id);
        }

        /**
         * @param p
         * @param id
         */
        public ASTText(Parser p, int id) {
            super (p, id);
        }

        /**
         * @see org.apache.velocity.runtime.parser.node.SimpleNode#jjtAccept(org.apache.velocity.runtime.parser.node.ParserVisitor, java.lang.Object)
         */
        public Object jjtAccept(ParserVisitor visitor, Object data) {
            return visitor.visit(this , data);
        }

    /**
     * @see org.apache.velocity.runtime.parser.node.SimpleNode#init(org.apache.velocity.context.InternalContextAdapter, java.lang.Object)
     */
    public Object init(InternalContextAdapter context, Object data)
            throws TemplateInitException {
        Token t = getFirstToken();

        String text = NodeUtils.tokenLiteral(t);

        ctext = text.toCharArray();

        return data;
    }

    /**
     * @see org.apache.velocity.runtime.parser.node.SimpleNode#render(org.apache.velocity.context.InternalContextAdapter, java.io.Writer)
     */
    public boolean render(InternalContextAdapter context, Writer writer)
            throws IOException {
        if (context.getAllowRendering()) {
            writer.write(ctext);
        }
        return true;
    }
}

person Clark Bao    schedule 13.08.2011    source источник
comment
@Oli: en.wikipedia.org/wiki/Queries_per_second   -  person BalusC    schedule 13.08.2011


Ответы (1)


Помимо того, что вы не вызываете одни и те же методы вывода, во втором примере вы избегаете накладных расходов на преобразование строки в байты перед ее записью в выходной поток. Однако эти сценарии не очень реалистичны, поскольку динамическая природа веб-приложений исключает предварительное преобразование всех ваших моделей данных в потоки байтов. И сейчас не существует серьезных архитектур, в которых вы будете писать напрямую в выходной поток HTTP, как эта.

person Perception    schedule 13.08.2011
comment
Это только пример. Он утверждает, что они рефакторят движок скорости, чтобы оптимизировать производительность. - person Clark Bao; 13.08.2011