На сайте есть отчеты, которые имеют сложный интерфейс (html).
Чтобы сократить время загружзки репорта, написал сервис который генерит html предварительно.
И когда юзер открывает репорт просто считываю html из текстового файла.
Ну вот незадача, в репортах может быть разные условия выборки. Я конечно создаю под каждый набор условий свой файл, но идея мне не очень нравиться.
Кто что может получше предложить?
Здравствуйте, <Аноним>, Вы писали:
А>Привет
А>На сайте есть отчеты, которые имеют сложный интерфейс (html). А>Чтобы сократить время загружзки репорта, написал сервис который генерит html предварительно. А>И когда юзер открывает репорт просто считываю html из текстового файла.
Готовь данные, а не html.
Генерация HTML по готовым данным занимает сотые доли секунды.
Данные к тому же легко фильтровать.
Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, <Аноним>, Вы писали:
А>>Привет
А>>На сайте есть отчеты, которые имеют сложный интерфейс (html). А>>Чтобы сократить время загружзки репорта, написал сервис который генерит html предварительно. А>>И когда юзер открывает репорт просто считываю html из текстового файла. A>Готовь данные, а не html. A>Генерация HTML по готовым данным занимает сотые доли секунды. A>Данные к тому же легко фильтровать.
Фильтровать — да, а вот генерация html — не доли секунды.
Данные разнородны. В итоге приходится строку склеивать циклическим проходом.
Даже StringBuilder работает 2-3 секунды
Здравствуйте, Аноним, Вы писали:
А>Фильтровать — да, а вот генерация html — не доли секунды. А>Данные разнородны. В итоге приходится строку склеивать циклическим проходом. А>Даже StringBuilder работает 2-3 секунды
Capacity заранее устанавливаете в приемлемое значение?
А вообще, без профайлера оптимизации производительности обречены на мучительный провал.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>А вообще, без профайлера оптимизации производительности обречены на мучительный провал.
Ну почему же, один совет можно дать и без профайлера. Использовать один из развитых и популярных шаблонизаторов вместо самопала. 90% оптимизаций, которые можно накопать профайлером у себя, там уже проведены.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Аноним, Вы писали:
А>>Фильтровать — да, а вот генерация html — не доли секунды. А>>Данные разнородны. В итоге приходится строку склеивать циклическим проходом. А>>Даже StringBuilder работает 2-3 секунды S>Capacity заранее устанавливаете в приемлемое значение? S>А вообще, без профайлера оптимизации производительности обречены на мучительный провал.
Да, Capacity значительно ускорил скорость.
А какие есть рекомендации по подбору параметра. Вот сейчас html — 33000 символов, я ставлю 40000.
Еще нашел один момент где можно ускорить скорость. У меня данные в хтмл склеиваются из 4 процедур, которые вызываются синхронно. Есть смысл сделать асинхронную загрузку?
Здравствуйте, Аноним, Вы писали:
А>А какие есть рекомендации по подбору параметра. Вот сейчас html — 33000 символов, я ставлю 40000.
Максимум достигнется при capacity больше, чем финальный размер.
А>Еще нашел один момент где можно ускорить скорость. У меня данные в хтмл склеиваются из 4 процедур, которые вызываются синхронно. Есть смысл сделать асинхронную загрузку?
Есть смысл всё-таки освоить профайлер. Без него вы не найдёте моментов, где "можно ускорить скорость".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Аноним, Вы писали:
А>Привет
А>На сайте есть отчеты, которые имеют сложный интерфейс (html). А>Чтобы сократить время загружзки репорта, написал сервис который генерит html предварительно. А>И когда юзер открывает репорт просто считываю html из текстового файла.
А>Ну вот незадача, в репортах может быть разные условия выборки. Я конечно создаю под каждый набор условий свой файл, но идея мне не очень нравиться. А>Кто что может получше предложить?
Я бы сделал инстанс БД под отчеты. Вектором оптимизации выбрал бы то, чтобы данные извлекались максимально быстро, а вот на вставку можно подзабить.
Первое что подходит для HTML сделать XML+XSLT->HTML более того при генерации инстансы шаблонов можно закэшировать. Вроде должно работать все очень быстро. Сериализацию в XML сделать руками, работать будет также моментально.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Aikin, Вы писали:
A>>Здравствуйте, <Аноним>, Вы писали:
А>>>Привет
А>>>На сайте есть отчеты, которые имеют сложный интерфейс (html). А>>>Чтобы сократить время загружзки репорта, написал сервис который генерит html предварительно. А>>>И когда юзер открывает репорт просто считываю html из текстового файла. A>>Готовь данные, а не html. A>>Генерация HTML по готовым данным занимает сотые доли секунды. A>>Данные к тому же легко фильтровать.
А>Фильтровать — да, а вот генерация html — не доли секунды. А>Данные разнородны. В итоге приходится строку склеивать циклическим проходом. А>Даже StringBuilder работает 2-3 секунды
Можете привести код и пример данных, просто какие-то совершенно фантастические цифры.
Здравствуйте, diez_p, Вы писали:
_>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, Aikin, Вы писали:
A>>>Здравствуйте, <Аноним>, Вы писали:
А>>>>Привет
А>>>>На сайте есть отчеты, которые имеют сложный интерфейс (html). А>>>>Чтобы сократить время загружзки репорта, написал сервис который генерит html предварительно. А>>>>И когда юзер открывает репорт просто считываю html из текстового файла. A>>>Готовь данные, а не html. A>>>Генерация HTML по готовым данным занимает сотые доли секунды. A>>>Данные к тому же легко фильтровать.
А>>Фильтровать — да, а вот генерация html — не доли секунды. А>>Данные разнородны. В итоге приходится строку склеивать циклическим проходом. А>>Даже StringBuilder работает 2-3 секунды
_>Можете привести код и пример данных, просто какие-то совершенно фантастические цифры.
Ошибься. Это ЛэйзиЛоад виноват. Сама функция StringBuilder-а работае почти мгновенно