Pull to refresh
5
0
Andrey Chernomyrdin @chernomyrdin

User

Send message
Просто сталкивался с токенами от Гос.Услуг — там тоже заявлено что работать будет из под linux-а, но .deb пакет собран настолько криво что пользоваться не возможно. А исходников что-бы собрать прямо и под i386 и под amd64 — нету :-(

Касаемо Рутокена — .deb пакет который частично ставится в /opt и отсутствие зависимостей навивает тоску.
Печаль :-(

Но это скорее беда всего отечественного крипто-софта — ни каких исходников, никакого удобства использования не-windows пользователей.
А для рутокена существет-ли ubuntu репозитарий для более удобной загрузки броузерного плагина?
Просто руками что-то куда-то копировать… при этом головой отслеживать зависимости
А если-бы репозитарии с контрольными суммами, подключаемые через ppa
Есть еще bloglines.com, и у них есть еще эксперементальны интерфейс beta.bloglines.com/
По удобству соизмеримо с googleReader, единственное _но_ хуже интегрируется.
Решал схожую проблему, то есть у меня была конструкция вида:

UPDATE posts SET open = open + 1 WHERE id = 1;

При большом количестве запросов к базе данных (то есть когда qps подскакивал до 500 и выше) имел большие тормоза, это было связано с тем что базы MyISAM (соответственно — table lock) и отказаться от них не получаться (используется Full Text Search).

Потом пробывал разрулить ситуацию с HIGH_PRIORITY и LOW_PRIORITY, то есть UPDATE LOW_PRIORITY и SELECT HIGH_PRIORITY, но все равно сталкивался с проблемами медленно выполняемых запросов

Решил проблему с помощью следующей конструкции:
Вместо UPDATE делаем INSERT в другую таблицу:
INSERT post_cnt (id,dtime) VALUES (1,now())

А при SELECT-е делаем:
SELECT *, (SELECT COUNT(*) AS cnt FROM post_cnt c WHERE c.id = p.id) AS open_add
FROM posts p WHERE id=%id%

Единственное _но_ в бизнес логике страниц пришлось делать что-то типа:
$post = GetPostID( $id );
// После проверки, что с $post все нормально делаем:
$post['open'] += $post['open_add'];

И регулярно (раз в несколько часов) делаю:
set @n=subtime(now(),'01:00:00');
UPDATE posts p
SET p.open=p.open+(SELECT COUNT(*) AS cnt FROM posts_cnt c WHERE c.id=p.id AND dtime<=@n )
WHERE p.id IN (select pc.id from post_cnt pc WHERE dtime<=@n);
DELETE FROM post_cnt;

В Вашем случае можно написать
INSERT INTO user_la( lastactivity, id, dtime) VALUES (1226505039,1,now());

Вместо SELECT-а:
SELECT *, (SELECT MAX(lastactivity) AS la FROM user_la l WHERE l.id = u.id) AS user_lastactivity
FROM user u WHERE id=%id%

в бизнес-логике
$user['lastactivity']=$user['user_lastactivity'];

Ну и переодически можно делать:
set @n=subtime(now(),'01:00:00');
UPDATE user u
SET u.lastactivity=(SELECT MAX(lastactivity) AS ula FROM user_la l WHERE l.id=u.id AND dtime<=@n )
WHERE u.id IN (select la.id from user_la la WHERE dtime<=@n);
DELETE FROM post_cnt;

Хотя конечно с memcache получается в чем-то красивее
То есть говоря на Perl-е :-), то:
s/\s+//mg;
В данном конкретном случае это не совсем правильно, хотелось-бы заменить два и более "пробельных" символов (пробел, табуляция, перевод каретки, перенос стоки, вертикальная табуляция и пр.) на один пробел.
следовательно можно записать как:
s/\s{2,}/ /mg;
Просто на продакшене php собран без preg :-/
Как следствие везде используются POSIX regular expression, благо они есть практически везде.
По производительности preg vs ereg, говорят что preg быстрее, но на каких-то конкретных примерах...
Коктейль взялся из-за того что разработка происходит на nginx, а основной сайт крутится под своеобразно собранным апачем.

В дальнейшем хотелось-бы переползти сначала на nginx+apache а затем совсем отказаться от apache в пользу nginx + php in FastCGI mode.

Поэтому и родился такой гибрид :-)

Да а уменьшение HTML кода путем удаления пробелов - таки не все мобильники умеют gzip, следовательно хотелось-бы хоть что-то для этих клиентов уменьшить. :-)

Потом при использовании еще нескольких сайтов на виртуальных хостингах столкнулись с тем что трафик передаваемый в сторону клиента хотелось-бы уменьшить, при добавлении этих классов эта проблема решилась. То есть php был собран с zlib, но исходящий трафик не сжимался.

Следовательно инструмент получился не для конкретного сочетания сайт-сервер, но остались сомнения что все что сделано - сделано правильно, поэтому был создан данный топик на предмет узнать где могут быть грабли и куда смотреть дальше. :-)
Использование компрессии естественно влияет на скорость выполнения скрипта и на нагрузку создаваемую на сервере, но окупается тем что пользователь, для примера, при получении HTML кода размером 7355 байт затрачивает 2541 байт GPRS трафика. Ресурсов на клиенте потребляется существенно меньше, т.к. декомпрессия - существенно менее ресурсоемкий процесс.
В принципе то-же самое делает и ob_gzhandler, Другое дело что в документации есть:
If a browser doesn't support compressed pages this function returns FALSE
Что в моем примере кода не учтено, с другой стороны есть
Conteg Content Negotiation:
http://www.phpclasses.org/browse/package…
который предусматривает очень много, но написан не очень понятно и хорошо, хотя есть большое желание поковырятся в нем и взять кое-какие вещи для использования
Про комментариях в описании ob_gzhandler - да, там много всего написано и большей частью по-существу, но данный код создавался как небольшое изменение текущего сайта дабы снизить трафик в сторону клиента.

Про nginx - в курсе, он сейчас активно тестируется и скорее всего пойдет вскоре на продакшен, но на данный момент на production-е стоит достаточно своеобразно собранный apache без mod_deflate, причем админских прав там нету. То есть совсем. Единственное что могу - остановить/запустить апач :-( объяснять админу что и как нужно собрать в апаче - достаточно заморочно (с административной стороны, да и ленив, он, как и все админы без меры :-)

И в основном предназначен для того что-бы понять как можно добавив 20 строк в свой сайт получить экономию трафика. Понятно, что этот код покроет 80-90% пользователей сайта, понятно что будут недовольные у которых что-то не будет работать...

Именно для этого и был создан данный пост, что-бы выяснить у почтенной публики где могут быть грабли, и подстелить соломку :-)
Да, я знаю о том что функция filter написана не оптимально, о чем я писал в своем посте, здесь она просто для демонстрации того что конкретно происходит.
Ну а про smarty - Большое спасибо за информаци, буду посмотреть на код.
tidy хорош когда нужно однократно переформатировать код, а мне-бы хотелось иметь красиво сформированный код внутри проекта, и код с минимальным оверхедом на выходе (или на входе в пользовательский броузер :-)
Сложно сказать, пока тестировалось все было ОК. Но особенность мобильных сайтов в том, что слишком много устройств для которых нужно тестировать. Вторая проблема это не сколько броузеры сколько кеширующие/некеширующие прокси, в основном проблемы именно с ними.

В данном исходнике используется достаточно стандартный и рекомендованный метод, сжатия, так что по-идее это должно снять какие-то проблемы с тестированием и совместимостью, но все равно хотелось-бы потестировать даный код по-больше.
Можно, но ob_gzhandler работает только на тех устройствах где есть поддержка gzip transfer encoding, а если этой поддержки нет - то в моем случае работает уменьшение HTML-кода путём удаления лишних пробелов.
Да это не много (не более 10%), но все-таки лучше уменьшить отдаваемый HTML на 10%, чем не уменьшать его вообще.
1

Information

Rating
Does not participate
Location
Санкт-Петербург и область, Россия
Date of birth
Registered
Activity