- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Я бы рекомендовал автору сделать хранение кеша не в файлах, а в Memcache ну или на выбор пользователя.
Делается это крайне просто с точки зрения программирования.
Плюсы:
1. Нет лишней нагрузки на HDD так как все хранится в ОЗУ.
2. Старый кеш не нужно удалять так как по истечении времени жизни кеша (задается при создании кеша), он просто помечается как устаревший и на его место перезаписывается новый кеш.
3. Значительно более быстрое время доступа к кешу в отличие от файлов.
4. Значительно меньше места требуется на хранение кеша, так как Memcache сжимает данные перед помещением в память.
Минусы:
1. Нужно чтобы у вас было хотя бы 256 мег. ОЗУ свободных.
2. При перезагрузке сервера кеш теряется (но это не критично так как сервера на linux работают без перезагрузки годами)
Мемкешед дает выигрыш в скорости, если храниться много мелких данных, особенно если хранятся числа (их не приходиться переводить из десятичной системы в бинарную). Либо если хранятся часто изменяемые данные. В остальных случаях потребление памяти не оправдывает прирост производительности.
---------- Добавлено в 19:50 ---------- Предыдущее сообщение было в 19:48 ----------
Денис Георгица, в этом случае попробуйте подключить как плагин к WP. Либо воспользоваться другим плагином кеширования. Либо поставить в этом плагине меньшее время кеширования.
Привет всем.
Подскажите делает ли такое скрипт. Опишу как ранее делали перелинковку - руками:
1. Выбирали руками ключи из аналитики и подбирали те что еще хотели бы поднять в поиске.
2. Затем анализировали ключи и каждому присваивали вес.
3. Затем анализировали в гугле какие страницы релевантны ключу.
4. Потом ставили ссылки на самую релевантную страницу по гуглу с менее релевантных страницах.
5. Количество ссылок проставляемых регулировали в зависимости от веса из пункта 2.
6. Ссылки проставлялись и закреплялись по мере посещения посетителями страниц.
Эту работу раз в полгода повторяли.
Делает ли это ваш скрипт все, и есть ли еще какие тонкости кроме ускорения работы и автоматизации, из-за чего стоит купить скрипт а не мучатся с сетью вручную?
Спасибо большое за ответ
Мемкешед дает выигрыш в скорости, если храниться много мелких данных, особенно если хранятся числа (их не приходиться переводить из десятичной системы в бинарную). Либо если хранятся часто изменяемые данные. В остальных случаях потребление памяти не оправдывает прирост производительности.
Я хранил в мемкешед целые HTML страницы сгенерированные движком, чтобы их не приходилось повторно генерировать, так как была большая нагрузка на базу данных из-за высокой посещаемости. Я думаю вы понимаете что целая страница в памяти это далеко не мелкие данные и не числа. И тем не менее это значительно разгружало базу данных, а в сравнении с файловым кешированием, очевидным плюсом было то что не забивался диск, устаревший кеш не приходилось чистить и размер кеша был в 3 раза меньше так как мемкешед сжимает данные перед помещением в память.
Замеры скорости же показывали что страница из кеша отдается в 70(!) раз быстрее чем генерируется новая. И это при том что новая генерировалась за секунду примерно.
Hkey когда апдейт будет? вот эту опцию более 2 месяцев обещаете /ru/forum/comment/9621162
скидка еще есть? еслида, как купить
Привет всем.
Подскажите делает ли такое скрипт. Опишу как ранее делали перелинковку - руками:
1. Выбирали руками ключи из аналитики и подбирали те что еще хотели бы поднять в поиске.
2. Затем анализировали ключи и каждому присваивали вес.
3. Затем анализировали в гугле какие страницы релевантны ключу.
4. Потом ставили ссылки на самую релевантную страницу по гуглу с менее релевантных страницах.
5. Количество ссылок проставляемых регулировали в зависимости от веса из пункта 2.
6. Ссылки проставлялись и закреплялись по мере посещения посетителями страниц.
Эту работу раз в полгода повторяли.
Делает ли это ваш скрипт все, и есть ли еще какие тонкости кроме ускорения работы и автоматизации, из-за чего стоит купить скрипт а не мучатся с сетью вручную?
Спасибо большое за ответ
Может кто из тех кто пользуется подскажет делает ли тоже что описано выше скрипт?
Привет всем.
Подскажите делает ли такое скрипт. Опишу как ранее делали перелинковку - руками:
1. Выбирали руками ключи из аналитики и подбирали те что еще хотели бы поднять в поиске.
2. Затем анализировали ключи и каждому присваивали вес.
3. Затем анализировали в гугле какие страницы релевантны ключу.
4. Потом ставили ссылки на самую релевантную страницу по гуглу с менее релевантных страницах.
5. Количество ссылок проставляемых регулировали в зависимости от веса из пункта 2.
6. Ссылки проставлялись и закреплялись по мере посещения посетителями страниц.
Эту работу раз в полгода повторяли.
Делает ли это ваш скрипт все, и есть ли еще какие тонкости кроме ускорения работы и автоматизации, из-за чего стоит купить скрипт а не мучатся с сетью вручную?
Спасибо большое за ответ
Ну примерно это и делает HTracer. Тонкостей, вроде бы, нет.
---------- Добавлено в 04:48 ---------- Предыдущее сообщение было в 04:19 ----------
Я хранил в мемкешед целые HTML страницы сгенерированные движком, чтобы их не приходилось повторно генерировать, так как была большая нагрузка на базу данных из-за высокой посещаемости. Я думаю вы понимаете что целая страница в памяти это далеко не мелкие данные и не числа. И тем не менее это значительно разгружало базу данных, а в сравнении с файловым кешированием, очевидным плюсом было то что не забивался диск, устаревший кеш не приходилось чистить и размер кеша был в 3 раза меньше так как мемкешед сжимает данные перед помещением в память.
Замеры скорости же показывали что страница из кеша отдается в 70(!) раз быстрее чем генерируется новая. И это при том что новая генерировалась за секунду примерно.
Если бы вы хранили в файлах, то разница была бы не в 70 раз а в 69.99 раз. Поскольку файл с диска читается значительно быстрее, чем отдается пользователю через интернет.
Более того если используется сжатие в памяти, то с диска быстрее считается чем разархивируется в памяти.
Даже если бы не было архивации ваш вариант медленнее при нескольких потоках и ограниченных ресурсах. То что пхп сгенерировал страницу не значит, что он полностью освободил память, часть ресурсов не удаляется из памяти пока клиент до конца не получит страницу. Вы забиваете физическую память кешем и в какой-то момент системе приходится использовать файл подкачки. А диск существенно медленнее справляется с мелкими данными типа переменных, массивов и структур, которые использует ОСь, системные службы, аппач, интерпретатор пхп, поскольку диску приходиться часто туда-сюда дергать головкой, а это занимает намного больше времени, чем само считывание.
---------- Добавлено в 04:50 ---------- Предыдущее сообщение было в 04:48 ----------
скидка еще есть? еслида, как купить
нет скидка закончилась
---------- Добавлено в 04:52 ---------- Предыдущее сообщение было в 04:50 ----------
Hkey когда апдейт будет? вот эту опцию более 2 месяцев обещаете /ru/forum/comment/9621162
Постараюсь в этом месяце выпустить.
прошу не минусовать, может вопрос уже снят
просто видел на одном из форумов
этот пост ниже датирован 26 мая 2011 г
можете прокомментировать? или что делать чтобы избежать подобного?
-------------------------
Тема: Для всех клиентов. По поводу падения хостинга.
--------------------------------------------------------
Добрый вечер, уважаемые клиенты.
Как многие из Вас успели заметить, сегодня вечером было падение сервера.
Причиной был один из сайтов, на котором запустили HTracer. Это крайне безграмотно написанный продукт, который умудряется не закрывать коннекты к MySQL, чем вызывает взрывной рост очереди FastCGI процессов и как следствие скручивание MaxClients. По сути это самая настоящая fork-бомба, только направленная не на память, а на форки Apache. Многие клиенты, которые пробовали его запускать уже получали просьбы не использовать этот продукт. Видимо доброе отношение и просьбы от саппорта не являются основой для сотрудничества с ними.
В связи с этим, мы объявляем, что с сегодняшнего дня HTracer приравнивается к попытке нарушить работу хостинга. Клиент, который его запустил лишается всех своих сайтов без возможности восстановления.
Никакие жалобы после не принимаются. В связи с этим мы также вынуждены поменять условия договора, о чем ставим Вас в известность.
Спасибо за внимание и еще раз извиняемся за сбой в работе сервера.
-------------------------
еще раз повторюсь этот пост от 26 мая 11г
Более того если используется сжатие в памяти, то с диска быстрее считается чем разархивируется в памяти.
Даже если бы не было архивации ваш вариант медленнее при нескольких потоках и ограниченных ресурсах. То что пхп сгенерировал страницу не значит, что он полностью освободил память, часть ресурсов не удаляется из памяти пока клиент до конца не получит страницу. Вы забиваете физическую память кешем и в какой-то момент системе приходится использовать файл подкачки. А диск существенно медленнее справляется с мелкими данными типа переменных, массивов и структур, которые использует ОСь, системные службы, аппач, интерпретатор пхп, поскольку диску приходиться часто туда-сюда дергать головкой, а это занимает намного больше времени, чем само считывание.
Я думаю если уж на сервере установлен мемкешед, то ему отведено как минимум 512 мегов памяти, а этого более чем достаточно для хранения кеша посещаемого сайта (в моем случае, посещаемостью более 150к в сутки), кеша который в случае файлового размещения занимал бы полтора гигабайта на диске. Вопрос в скорости файлового кеша или кеширования в мемкешед тут не стоит, разница не столь значительна.
Я поднял эту тему из-за удобства использования мемкешеда в том что не надо будет чистить устаревший кеш, остальные плюсы как дополнение...
Просто сделайте на выбор куда кешировать в файлы или в память мемкешед, и всем будет счастье.
PS: В движке DLE кстати говоря в последней версии появилась поддержка мемкешед, и это радует. Хорошая практика!
ovechka
Вопрос уже давно снят. У меня на этом хостинге есть сайты и уже давно всё работает отлично.
Выше постом у человека 150к посещаемость тем не менее скрипт стоит.