- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Да ему пофиг, у меня все картинки сжимаются gzip через htaccess, лишь бы он был у пхп. Попробуйте.
Если не поможет то придется ковыряться в конфиге апача/пхп, видимо там лимит памяти кончается или еще что-то подобное
да кстати а jpeg не пробовали?)) Может все дело в размере тупо?
тупо jpeg и gif давно попробовал... :)
сейчас попробую перехват со сжатием проверить...
возможно при "глючном" зуме идут очень большие расчеты, которые на локалке проходят, а сервак просто завершает скрипт по таймауту... попробуйте:
1. если есть доступ - увеличить память для скрипта + время таймаута (не 15 сек., а 60 например)
2. сталкивался с этим сам - обрабатывал картинку на основе созданной из Png - по ходу дела этот формат кушает памяти немерянно. на локалке ок, на сервере - не успевал отработать скрипт. решение - п.1
3. ну и радикальное - изменить поход к генерации картинок. т.е. написать скрипт, который сгенерит все варианты картинок для всех зумов и выдавать их уже пользователю в готовом виде в зависимости от координат и зума.
возможно при "глючном" зуме идут очень большие расчеты, которые на локалке проходят, а сервак просто завершает скрипт по таймауту... попробуйте:
1. если есть доступ - увеличить память для скрипта + время таймаута (не 15 сек., а 60 например)
2. сталкивался с этим сам - обрабатывал картинку на основе созданной из Png - по ходу дела этот формат кушает памяти немерянно. на локалке ок, на сервере - не успевал отработать скрипт. решение - п.1
3. ну и радикальное - изменить поход к генерации картинок. т.е. написать скрипт, который сгенерит все варианты картинок для всех зумов и выдавать их уже пользователю в готовом виде в зависимости от координат и зума.
Если это карта, то вообще, malls, добро пожаловать в прекрасный мир SVG, который отлично парсится jQuery 😂
1. сжатие не работает - правда изменилась реакция бразера - в случае с сжатием через gzencode пишет что в файле ошибки обнаружены.
2. Таймаут стоит 600 об этом тоже думал уже...
2. сталкивался с этим сам - обрабатывал картинку на основе созданной из Png - по ходу дела этот формат кушает памяти немерянно. на локалке ок, на сервере - не успевал отработать скрипт. решение - п.1
Тут не совсем то... Файл превращается в png только на этапе imagepng(), т.е. до этого он просто обычный поток и все... Как хочешь так и выводи. PNG в два раза легче GIF получается...
Если это карта, то вообще, malls, добро пожаловать в прекрасный мир SVG, который отлично парсится jQuery 😂
Еслиб jquery еще умел для нее данные парсить с инета и хранить их в базе, а оттуда уже выдавать в виде SVG - то тогда да! А так нет! :)
1. сжатие не работает - правда изменилась реакция бразера - в случае с сжатием через gzencode пишет что в файле ошибки обнаружены.
уберите header content-type и увидите что за ошибки (это ошибки рантайм либо парсер однозначно)
уберите header content-type и увидите что за ошибки (это ошибки рантайм либо парсер однозначно)
Убрал - дебильность в том, что:
Локалка:
1. на больших масштабах выдает PNG текст (внутрянку файла)
2. на маленьких выдает PNG
Сервер:
1. на больших масштабах выдает пустой файл, т.е. ничего
2. на маленьких выдает PNG
т.е. трабла получается в сервере - но где?
памяти на пхп не хватает 99%
если пустой файл, возможно "error_reporting 0" блокирует вывод инфы о проблеме, в логах посмотрите, наверняка какие-нить варнинг или фатал-ерроры должны затесаться, бывает когда ошибки php выдает, браузер про файл говорит "невозможно отобразить картинку", можно сделать "просмотр хтмл кода" и там увидеть "error on line...", суть в том, что если файл пустой - где-то ошибки, но их надо найти, хотя бы в логах
про память - если png 100 КБ, то в памяти он должен весить как соответствующий bmp, может не хватать, плюс вам надо глянуть как работает все, может несколько объектов (картинок) дублируются и память забивают (a=5, b=a+2, c=b+3 и т.п. только с графикой)
Zlo_606ep добавил 24.02.2009 в 19:53
Допустим все карта (zoom=1) это 100х100 клеток в размере 500х500px, при zoom=10 это будет 10х10 клеток в размере 500х500px.
тут случайно логика не такая: увеличить картинку в 10 раз, вырезать квадрат 10х10?
тут случайно логика не такая: увеличить картинку в 10 раз, вырезать квадрат 10х10?
именно такая.
Сам уже думаю про память - разбираюсь с этим...
malls, точно памяти нема. переделай алгоритм
bearman добавил 24.02.2009 в 20:26
или используй внешние программы типа imagemagic