Pull to refresh

Comments 37

Есть ли смысл сжимать вышеописанными способами, если от браузера на сервер передаются изображения?
По идее, нет. Большинство изображений и так пожаты.
Имеет смысл передавать в бинарном виде, а не в виде Base64 строки. А вот пережимать там уже нечего будет.
Как верно ответил Fesor, нужно передавать как бинарные данные. Вот небольшой пример для canvas.
Если вы пытаетесь несколько изображений передать, то сейчас с этим отлично справляются HTML5 и FIleApi. Просто файлы надо отправлять по одному, а не пачкой (собственно «очередь» загрузки реализуется на JavaScript без проблем).
Как-то грустно получается у.15% Рунета (Opera 12, IE8,9), это работать не будет.
15%, ИМХО, это слишком много, что бы использовать в продакшн.
Часто данные не умещаются в один post запрос из-за ограничений nginx/apache/php/etc.

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

По факту вы дополнительно нагружаете, как браузер пользователя сжатием, так и сервер — разжатием. Хотя и экономите немного времени, на медленном канале.
Ну для 15% можно сделать фэлбэк в виде стандартного POST запроса, а на остальных 85% экономить трафик и пользователя и сервера.
UFO just landed and posted this here
15% Рунета могут загружать несжатые данные. В нашем проекте старые браузеры все равно пролетают из-за скорости работы, поэтому вопрос совместимости не стоял.
Нет проблемы увеличить максимальный размер запроса. Сжимая мы экономим трафик и ускоряем загрузку данных, особенно для пользователей с медленным соединением.

А приведенная цитата про алгоритм относится к обработке ключевых слов в нашем проекте. Само сжатие вносит относительно незаметный overhead.
не 15 а более, не забывайте про мобильный трафик, который все более и более ощутим. Единственное что на андроиде не все так печально ибо на девайсах от 4.х часто в комплекте идет гугл хром а не стандартный браузер. И там webworkers работает очень даже хорошо.
В рамках того проекта про ключевики можно сказать с уверенностью, что мобильный трафик там еще долго не появится. Это я к тому, что инструменты и задача должны быть согласованы.
Есть подозрение, что подобный сервис не особо посещаем «всем Рунетом». Это не Вконтакт, и не mail.ru…

Те же, кто темой обработки ключевиков озаботился, скорее всего, имеет на машине больше одного браузера — ему просто можно показать совет, что «в вашем браузере обработка не так эффективна, как в таких-то браузерах», и люди сами потянутся к оптимальному для себя варианту.

Ну а уж сделать fallback в что-то более обычное (чистый POST) — это уж просто вежливость, как ни крути )
помещалось в один http запрос

Если и есть ограничения для запроса, то они касаются конкретного веб-сервера или заданы в настройках веб-приложения.
Сжатие на клиенте сильно повысит нагрузку на процессор на клиенте же — тоже важно учитывать, надо ли вам оно.
Тут будет иметь значение баланс «время сжатия минус время передачи сжатого — время передачи несжатого». И это зависит от размера, канала и сжимаемости данных.
UFO just landed and posted this here
Спасибо за наводку, не знал.
В таком случае, если есть подписанный ssl сертификат, то действительно выгоднее использовать сжатие на уровне протокола. Работать должно быстрее и эффективнее.
Для php не ставил, а рабочей реализации на браузерном javascript не видел. По ссылкам выше: первая для node.js, вторую можно запустить в браузере, но она не работает: lz4.uncompress(lz4.compress('test')) выдаст ошибку.
Попробуйте вместо base64 кодировать в шестнадцатиричную запись в виде строки, например, «ABC» -> байты с кодами 65 (0x41), 66 (0x42), 67 (0x43) -> шестнадцатиричная строка «414243», так чтобы каждому байту на входе соответствовало два символа на выходе.

Base64 кодирует каждые 3 байта на входе 4-мя на выходе. Это будет нарушать повторения во входных данных для алгоритма сжатия (на основе которых он и сжимает). Используя base64, вы понижаете качество сжатия. Например:

данные:«12345678901234567890»
base64: MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= (повторение потерялось)
hex: 3132333435363738393031323334353637383930 (повторение сохранилось)

данные:«123456789123456789»
base64: MTIzNDU2Nzg5MTIzNDU2Nzg5 (повторение сохранилось, потому что период кратен трем)
hex: 313233343536373839313233343536373839 (повторение сохранилось)

Или еще пример:
данные:12341234
base64: MTIzNDEyMzQ= (повторение потерялось)

данные:1234_1234
base64: MTIzNF8xMjM0 (повторение потерялось)

данные:1234__1234
base64: MTIzNF9fMTIzNA== (повторение сохранилось)
Обновил статью и код примера. Экранировать unicode оказалось эффективнее, чем hex. И, тем более, чем base64. Спасибо за подсказку.
> 7872 Кб (сжатие 84%)

Сжатие от исходных 9402 Кб будет не 84% (точнее, 83,73%), а как раз 100-83,73%=16,27%. Мы же говорим о сжатии, т.е. о величине, на которую размер уменьшается.
Имеется ввиду сколько осталось от первоначального объема, как пишут в архиваторах.
Вы закодировали unicode строку в base64 и затем её сжимаете компрессором? Но это же жесть какая то… Зачем base64? Сразу 33% оверхед. Закодируйте какой-нибудь кодировкой и потом сразу в компрессор.

Ну и саму задачу на мой взгляд можно эффективнее чем за O(n^2) решить. Не могли бы кратко описать алгоритм?
Обновил статью и код примера, заменил base64 на экранирование unicode символов. Получилось действительно намного эффективнее. Спасибо за подсказку.

Сам алгоритм обработки ключевиков выходит за рамки данной статьи. Возможно напишу о нем позже.
Попробуйте тогда уж вместо stringEscape такую конструкцию unescape(encodeURIComponent(data)).
Если интернет не врёт, то это самый простой способ получить UTF-8 из Unicode.
Если сконвертишь в cp1251, то можно ещё сэкономить.
Функции escape и unescape обозначены как deprecated. Стоит ли их использовать в новых проектах?
никак не остановлюсь ;)
github.com/imaya/zlib.js
www.php.net/manual/en/ref.zlib.php

минимальный оверхед
на стороне сервера нативная реализация (нефиг велосипед выдумывать)
использовать raw_deflate на клиенте
на сервере zlib_decode, параметр $max_decoded_len спасет от «gzip-бомбы»

собственно 20 минут гугления — думаю это меньше чем изобретать велосипед. надеюсь моя «рукалицо» теперь понятны.
UFO just landed and posted this here
Может быть вы знаете, как такое детектить на стороне сервера?
Что мешает воспользоваться готовым бинарным протоколом, который ко всему прочему еще и тормозить на сжатии не будет? Тем же Thrift, например?
Sign up to leave a comment.

Articles