Хранить в базе, а в папке делать кэш.
Там было очень много разных толстых контролов. определять каждый раз необходимый набор контролов было в лом + разные зависимости.
Нащет того как это все организовывалось не скажу, я трудился на серверной стороне.
Ну что то типа майкрософтовских вебпродуктов. Ну очень жирный был клиент
Исходники то были разделены, просто во время выкладывания на сервак сливались в один
На каком движке если не секрет.
А если по теме: то весь сайт всего лишь набор справочников. Мне например непонятно зачем марки нужно вбивать в нескольких местах
Да как обычный html жмете gzipом также и js. Протокол то один: HTTP
Был тут проект с богатым клиентом (имеется ввиду что сайт в браузере как нормальное приложение работает). Ясное дело ajax js по полной использовался. Файлов JS было на 1 мегабайт. Разбили все это хозяйство на красивые маленькие структурированные кусочки. Итого получилось 1000 файлов;-))
Вообщем первая страница грузилась полчаса:-). Покумекали, на этапе сборки слили 1000 файлов в один и его подключали из страницы. Страница стала грузится очень быстро (относительно конечно: получилось что нужно грузить один сжатый файл весом 100кило).
Но это крайний случай, а так конечно лучше дробить.
Вы надо мной издеваетесь? Вам ergo привел пример что у него разное время.
Насчет двух потоков: ясное дело что отсылает данные другой поток. но размер промежуточного буфера не бесконечен и пока он полный исполняющийся поток будет ожидать освобождения этого буфера.
Попробуйте хотя бы написать скрипт отдающий пользователю гигабайтный файл. За какое время отработает данный скрипт? За время необходимое для прочтение данного файла с диска?
ЗЫ. Нужно понимать что буферы ввода/выводе нерезиновые.
ЗЫЫ. Любой вебсервер при определенных размерах генерируемого вывода заставит генерирующий поток ожидать (при условии что скорость генерации данных больше скорости передачи)
На псевдо языке можно?
засечь время
записать в вывод 10 мульенов нулей
вывести время
могу на жабе
long t1 = System.currentTimeMillis();
byte[] data = new byte[10*1024*1024];
response.getOutputStream().write(data);
logger.info("Время: "+(System.currentTimeMillis()-t1));
Все верно только не понял почему вешалка?:-)) поток то обсуживающий данного клиента будет 99% времени своего исполнения ожидать доступности канала (т.е ничего не делать)
Хотелось бы все таки узнать поподробнее.
в utf-8 вроде размер html больше получается чем в 1251 изза того что русские буквы занимают 2 байта вместо одного. Но может и ошибаюсь
Слово многопотчность вам знакомо? А понятие блокирующей операции?
Если да.
Предположим что вы читаете из сокета. что будет если вы вызвали метод read а данных нет.
Предположим что вы пишете в сокет, что будет если вы вызвали метод write а исходящий буфер переполнен?
Правильный ответ: текущий поток перейдет в состояние ожидания.
ЗЫ. Кстати 6 лимонов показов в час это на одной машине или на кластере? Поподробнее пожалуйста. Уж очень интересно как добились такой производительности 7 лет назад
