Самый верный способ запомнить, воспользоваться полученными заниями в практических целях — в этом случае занния становятся опытом.
Я знаю людей которые получаю красные дипломы и всё помнят (возможно пока помнят), но воспользоваться этим не могут, если немного расширить мысль то получается что эти знания бесполезны для человека и возможно ему не следовало их получать.
Да бывает, что приходится править недоделки своими руками
помоему поиск на работат ру ограничен городом и отказаться от этого без удаления этого элемента фотрмы невозможно
Фаербаг в руки всё ок
да владелец впринципе виноват
1) допустил к управлению нейми кого
2) не обеспечил безопасность
за это владелец перед пострадавшими отвечает деньгами. (те несёт материальную ответственность, и в ряде случаев уголовную)
Водитель тоже несёт ответственность как правило административную и уголовную (те могут выписать штрафа, могут отправить в вытрезвитель, могут прав лишить, а могут и посадить)
Вот именно об этом вопрос — потрачено на поиски приличное время — а нужного результата нет. То ли проблема эта надуманная, толи я смотрю не те скрипты, то ли я чего-то не знаю об этой проблеме.
Есть золотые слова одного из моих знакомых — решать проблемы по мере поступления. Правда он владелец успешной компании и юрист по образованию. Думаю ему можно поверить.
Если очень хотите, проведите исследование и нагрузочное тестирование, выложите результат — мне будет интересно посмотреть :)
C ReiserFS — дела не имел, но судя по тому что читал должно быть примерно также как с ext4
Если Вам нужна расфасовка, то можно написать скриптик который выполнит команду ln file1 sorted/1/1/1/1/file1 для пачки файлов (это небудет съедать много места на диске, но выглядит как костыль)
Если Вы загружаете файлы через ftp (я в фото движках не силён, но как-то сомнительно что фото загружаются через ftp) то можно написать скриптик проделывающий операцию обратную тоё что в предыдущем предложении (но тоже выглядит как костыль, но поменьше ))
Есть ещё вариант, отказаться от Windows и ftp, и начать использовать ssh и rsync
Вообще потратьте день или два на поиски движка и будьте готовы к тому что найденный движок не будет вас устраивать без допиливаний — это обычная практика, так я начал программировать ))
Если хост будет на linux и количество фотографий измеряется в сотнях тысяч и ФС ext4 — то вероятно проблема для вас не актуальна.
Единственный момент, не должно быть запросов типа ls — в этом случае как бы быстро всё не работало, а прогнать сотни тысяч названий займёт какое-то время.
rm * тоже не сработает тк есть ограничение на 256 файлов, если я правильно помню ))
я к тому, что подход просто неправильный показан. Gzip дает выигрыш в 80%. После него стоит жать YUI / JSMin скрипты и CSS Tidy / YUI стили. Но выигрыш в этом случае будет не больше 5-8%. 800Кб * 0,05 = 40 Кб. Естественно, что более действенным методом оказался выброс неиспользуемых скриптов. Но это работает далеко не всегда (и советовать выбрасывать неиспользуемую функциональность вредно: это ведет ко всяким «урезанным» версиями jQuery / Mootools и т.д.). Хотя куда проще взять тот же Sizzle / YASS, прикрутить к нему пара реально нужных модулей и запустить все это в продакшен.
По этому поводу написано, и даже приведён листинг. В моём случае при использовании yui размер увеличился. Подробности в тексте.
Далее. Тема «нагрузки на сервер от сжатия» совершенно не раскрыта. Я так понимаю, что Java — это backend? Тогда скрипты и стили можно замечательно жать при деплое, а сам Amazon (я более чем уверен) может gzip-ипить самостоятеьно. Или у вас запросы напрямую к Tomcat для HTML-динамики? Тогда стоило упомянуть про альтернативные методы, типа minify — когда мы из HTML-кода выбрасываем все, причем именно в момент деплоя рабочей версии на рабочий сервер, чтобы «на лету» этим не заниматься.
1) Да можно жать, на эту тему есть в статье заметка, в конце
2) Амазон не жмёт контент, но позволяет пользователю сжать, закачать и выставить соответствующие заголовки. И этот момент я действительно не упоянул.
3) Статика хранится на S3 динамика на Tomcat. К Tomcat идут только rpc запросы и там хранятся файлы который изменются при обновлениях. Например js (с очень большой вероятностью это в дальнейшем изменится). Я действитель забыл на это указать. И это важный момент.
— про minify почитаю
Я могу долго так продолжать. Просто мне грустно, что микроскопом гвозди забивают. Что экономят: сначала работодатели, не желающие решать задачи с помощью тех сотрудников, которые для этого предназначены, например, клиентских архитекторов; а затем и сами сотрудники, потому что сроки поджимают, потому что попалась «новая интересная задача», потому что такой подход к самообразованию — неструктурированный. Грустно от того, что независимо от количества информации на тему клиентской оптимизации (сотни, если уже не тысячи статей, несколько полноценных книг, десятки докладов) все равно 90% разгона будет осуществляться именно так, «на коленке», на скорую руку, чтобы только работало. А что это не масштабируемо, что это будет не актуально через год, например. Что это, ускоряя в одном месте, будет замедлять в другом — никого не волнует.
Очень хорошо. Пределов совершенству нет. Я внимательно читаю.
Это из раздела экономики и ограниченности ресурсов. Я незнаю лучшего пути и если Вы его предложете я готов по нему пойти :)
По поводу мастабируемости можно по подробнее.
Замедление в другом месте(сжатие на коннекторе) сейчас наиболее дёшево, и через год это станет не актуальным. По одной из 2х причин.
1) Эта установка будет стоять за кэширующим балансировщиком (он закэшируетс файлы с расширением js, html, xml, ..., как следствие сжатие на коннекторе будет производиться один раз)
2) Это будте сделано средствами приложения (в моём понимании на этом этапе это не требуется, тк есть более важные задачи и ограниченные ресуры)
отличная статья. Показательная. На тему того, как НЕ надо решать проблемы, но как они решаются в 99% случаях :)
Обычно, если не знают, как справиться с проблемой, то читают фундаментальные основы (например, той же клиентской оптимизации). Выясняют, как работает Tomcat. Выясняют, какая выгода от конкретных методик и приемов. А потом выбирают наиболее действенные и начинают их использовать. Здесь же был обратный подход: у нас есть непонятная в решении проблема, давайте ее бить всем, что под руку попадется — авось, сработает. Ну да, с пятого раза сработало. Повезло :)
Я забыл сказать что я администратор :), и с Томкатом немного знаком. Правда больше приходилось работь с Apache 1.3 те больше работал с C/C++ программами. Сейчас же преключаюсь на Java
По выгодам я вроде показал где и от чего сколько, если вы с чем-то несогласны я готов изучить этот вопрос и внести изменения или конструктивно ответить.
По поводу картинок: 9Мб / 600 ~= 15 Кб. Если у вас на странице заканчиваются потоки (а при таком объеме они 100% будут заканчиваться), то реально стоит смотреть в сторону решений а-ля DURIS — через data:URI (mhtml) объединяем картинки в чанки (по 100Кб, например, которые еще и архивироваться умеют, общие потери на размер = 5-10%, выигрыш от канала +50%), затем на каждую страницу выливаем свое количество чанков (через файлы стилей, например).
Спасибо за разъяснение, эта часть очень полезна и я её обязатьельно изучу. К соожалению высказывание автора выше не было стольже понятным.
Может быть, также сильно помогут множественные хосты: не увидел этого в заметке — они используются?
Если я правильно понимаю документацию, и моя документация не устарела то этот подход не позволяет освободить память от предыдущего контекста, как следствие out of memory остаётся в силе
А зачем массив с картинками в глобальную область видимости класть?
fixed
А with(img) зачем использовать?
fixed
Всем, кто начинает изучать Javascript: вот отличный пример того, как НЕ НАДО делать.
беспользный комент, хотя возможно и отражет сложившуюся ситуацию
Вы забыли обозначить ошибки, по этой причине я не могу вам аргументированно ответить или исправить ошибку
Здесь надо обратить на ключевую фразу «файла прошедшего через обфускацию средствами GWT», те если скрипт рукописный то он возможно очень сильно поможет
Как сейчас помню, лет 10 назад, когда я впервые сел за компьютер подключенный к интернету. Эти магические http://, ftp://, https:// — повергали меня в шок от мысли что это часть названия сайта и их тоже надо помнить
Хотя и названия сайтов мне не казались интуитивно понятными тк английский я незнал совсем ))
По поводу 304, у амазона это автоматически сделано. На Tomcat для статических файлов 304 работает по умолчанию. У Apache 2.2.9-10+lenny4 тоже 304 при повторной закачке.
По поводу кэширование через background — на сколько мне известно это хороший способ при небольшом количестве картинок.
При большом количестве картинок всплывают некоторые особенности
1) Невозможно остановить закачку
2) Невозможно контролировать количество потоков(прибито гвоздём в браузере)
Как следствие это может вызвать проблемы при большом количестве файлов(600 файлов — 10Мб).
Например все выделенные потоки для данного домена у браузера заняты, и запросы посланные js будут поставлены в очередь. В то время как картинки могли бы и подождать 0,01 секунды. А получается что будет ждать пользователь тк ресурсы браузера исчерпаны.
У нас эта проблема решена 2раза :)
1) разнос статики и динамики на разные сервера (статика у Амазона)
2) сокращение конкурирующих потоков в канале на стороне пользователя, чрез контролирование количества потоков прелоадера
У подхода с использование js есть свой минус, неработает при отсутствии js. Для нашего проекта данный пункт не актуален по причине аяксовости приложения — те если js у клиента отключен, это не наш клиент.
В приведённом кусочке js есть неявная возможность контролировать количество потоков. Изменив количество вызовов функции cacheImage(); в 8-ой строке.
Я знаю людей которые получаю красные дипломы и всё помнят (возможно пока помнят), но воспользоваться этим не могут, если немного расширить мысль то получается что эти знания бесполезны для человека и возможно ему не следовало их получать.
помоему поиск на работат ру ограничен городом и отказаться от этого без удаления этого элемента фотрмы невозможно
Фаербаг в руки всё ок
1) допустил к управлению нейми кого
2) не обеспечил безопасность
за это владелец перед пострадавшими отвечает деньгами. (те несёт материальную ответственность, и в ряде случаев уголовную)
Водитель тоже несёт ответственность как правило административную и уголовную (те могут выписать штрафа, могут отправить в вытрезвитель, могут прав лишить, а могут и посадить)
Есть золотые слова одного из моих знакомых — решать проблемы по мере поступления. Правда он владелец успешной компании и юрист по образованию. Думаю ему можно поверить.
Если очень хотите, проведите исследование и нагрузочное тестирование, выложите результат — мне будет интересно посмотреть :)
Да прибудут с Вами деньги
Если Вам нужна расфасовка, то можно написать скриптик который выполнит команду ln file1 sorted/1/1/1/1/file1 для пачки файлов (это небудет съедать много места на диске, но выглядит как костыль)
Если Вы загружаете файлы через ftp (я в фото движках не силён, но как-то сомнительно что фото загружаются через ftp) то можно написать скриптик проделывающий операцию обратную тоё что в предыдущем предложении (но тоже выглядит как костыль, но поменьше ))
Есть ещё вариант, отказаться от Windows и ftp, и начать использовать ssh и rsync
Вообще потратьте день или два на поиски движка и будьте готовы к тому что найденный движок не будет вас устраивать без допиливаний — это обычная практика, так я начал программировать ))
Единственный момент, не должно быть запросов типа ls — в этом случае как бы быстро всё не работало, а прогнать сотни тысяч названий займёт какое-то время.
rm * тоже не сработает тк есть ограничение на 256 файлов, если я правильно помню ))
Готов дать Вам контакты моего руководства прямо сейчас, и я не беспокоюсь остаться без работы. Моя работа станет ещё более интересной и насыщенной.
С уважением к Вам и вашим трудам.
зы: оч жаль что не вличку
По этому поводу написано, и даже приведён листинг. В моём случае при использовании yui размер увеличился. Подробности в тексте.
1) Да можно жать, на эту тему есть в статье заметка, в конце
2) Амазон не жмёт контент, но позволяет пользователю сжать, закачать и выставить соответствующие заголовки. И этот момент я действительно не упоянул.
3) Статика хранится на S3 динамика на Tomcat. К Tomcat идут только rpc запросы и там хранятся файлы который изменются при обновлениях. Например js (с очень большой вероятностью это в дальнейшем изменится). Я действитель забыл на это указать. И это важный момент.
— про minify почитаю
Очень хорошо. Пределов совершенству нет. Я внимательно читаю.
Это из раздела экономики и ограниченности ресурсов. Я незнаю лучшего пути и если Вы его предложете я готов по нему пойти :)
По поводу мастабируемости можно по подробнее.
Замедление в другом месте(сжатие на коннекторе) сейчас наиболее дёшево, и через год это станет не актуальным. По одной из 2х причин.
1) Эта установка будет стоять за кэширующим балансировщиком (он закэшируетс файлы с расширением js, html, xml, ..., как следствие сжатие на коннекторе будет производиться один раз)
2) Это будте сделано средствами приложения (в моём понимании на этом этапе это не требуется, тк есть более важные задачи и ограниченные ресуры)
«невешать нос Гардемарины… » :)
Я забыл сказать что я администратор :), и с Томкатом немного знаком. Правда больше приходилось работь с Apache 1.3 те больше работал с C/C++ программами. Сейчас же преключаюсь на Java
По выгодам я вроде показал где и от чего сколько, если вы с чем-то несогласны я готов изучить этот вопрос и внести изменения или конструктивно ответить.
Спасибо за разъяснение, эта часть очень полезна и я её обязатьельно изучу. К соожалению высказывание автора выше не было стольже понятным.
Да такое есть и встатье есть упоминание.
Если я правильно понимаю документацию, и моя документация не устарела то этот подход не позволяет освободить память от предыдущего контекста, как следствие out of memory остаётся в силе
fixed
fixed
что-то ещё :)
Вы забыли обозначить ошибки, по этой причине я не могу вам аргументированно ответить или исправить ошибку
Конец прошлого и начало этого — итого: второе подряд
Хотя и названия сайтов мне не казались интуитивно понятными тк английский я незнал совсем ))
По поводу кэширование через background — на сколько мне известно это хороший способ при небольшом количестве картинок.
При большом количестве картинок всплывают некоторые особенности
1) Невозможно остановить закачку
2) Невозможно контролировать количество потоков(прибито гвоздём в браузере)
Как следствие это может вызвать проблемы при большом количестве файлов(600 файлов — 10Мб).
Например все выделенные потоки для данного домена у браузера заняты, и запросы посланные js будут поставлены в очередь. В то время как картинки могли бы и подождать 0,01 секунды. А получается что будет ждать пользователь тк ресурсы браузера исчерпаны.
У нас эта проблема решена 2раза :)
1) разнос статики и динамики на разные сервера (статика у Амазона)
2) сокращение конкурирующих потоков в канале на стороне пользователя, чрез контролирование количества потоков прелоадера
У подхода с использование js есть свой минус, неработает при отсутствии js. Для нашего проекта данный пункт не актуален по причине аяксовости приложения — те если js у клиента отключен, это не наш клиент.
В приведённом кусочке js есть неявная возможность контролировать количество потоков. Изменив количество вызовов функции cacheImage(); в 8-ой строке.