Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 37

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

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

По факту вы дополнительно нагружаете, как браузер пользователя сжатием, так и сервер — разжатием. Хотя и экономите немного времени, на медленном канале.
Всего голосов 7: ↑3 и ↓4-1
Ну для 15% можно сделать фэлбэк в виде стандартного POST запроса, а на остальных 85% экономить трафик и пользователя и сервера.
Всего голосов 5: ↑4 и ↓1+3
НЛО прилетело и опубликовало эту надпись здесь
15% Рунета могут загружать несжатые данные. В нашем проекте старые браузеры все равно пролетают из-за скорости работы, поэтому вопрос совместимости не стоял.
Нет проблемы увеличить максимальный размер запроса. Сжимая мы экономим трафик и ускоряем загрузку данных, особенно для пользователей с медленным соединением.

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

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

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

Если и есть ограничения для запроса, то они касаются конкретного веб-сервера или заданы в настройках веб-приложения.
Сжатие на клиенте сильно повысит нагрузку на процессор на клиенте же — тоже важно учитывать, надо ли вам оно.
Всего голосов 1: ↑1 и ↓0+1
Тут будет иметь значение баланс «время сжатия минус время передачи сжатого — время передачи несжатого». И это зависит от размера, канала и сжимаемости данных.
Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за наводку, не знал.
В таком случае, если есть подписанный ssl сертификат, то действительно выгоднее использовать сжатие на уровне протокола. Работать должно быстрее и эффективнее.
Всего голосов 1: ↑1 и ↓0+1
Для php не ставил, а рабочей реализации на браузерном javascript не видел. По ссылкам выше: первая для node.js, вторую можно запустить в браузере, но она не работает: lz4.uncompress(lz4.compress('test')) выдаст ошибку.
Комментарий пока не оценивали0
Попробуйте вместо 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== (повторение сохранилось)
Всего голосов 3: ↑3 и ↓0+3
Обновил статью и код примера. Экранировать unicode оказалось эффективнее, чем hex. И, тем более, чем base64. Спасибо за подсказку.
Всего голосов 1: ↑1 и ↓0+1
> 7872 Кб (сжатие 84%)

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

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

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

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

собственно 20 минут гугления — думаю это меньше чем изобретать велосипед. надеюсь моя «рукалицо» теперь понятны.
Всего голосов 2: ↑2 и ↓0+2
НЛО прилетело и опубликовало эту надпись здесь
Может быть вы знаете, как такое детектить на стороне сервера?
Комментарий пока не оценивали0
Что мешает воспользоваться готовым бинарным протоколом, который ко всему прочему еще и тормозить на сжатии не будет? Тем же Thrift, например?
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr