Здравствуйте,
Пообщавшись с людьми и послушав доклады на РИТ-е и Хайлоаде, я пришёл
к выводу, что одновременно несколько компаний изобретают одни и те же
велосипеды, считая, что это даёт им какую-то коммерческую выгоду. При
этом открытость только декларируется, а исходники выкладывать никто не
спешит, ибо "начальство не разрешает". Одновременно с этим много людей
реализует кастомные патчи и также не может их сделать общедоступныими
из-за того, что заказчики им этого не позволяют.
По этим причинам я решил попробовать в силу своих возможностей
проспонсировать разные полезные веб-разработчикам и мне лично
мини-проекты, с условием, что их исходники будут доступны в инете с
сохранением авторства их разработчиков.
ИМХО, это позволит сделать что-то полезное с минимумом багов, ибо эти
мини-проекты подразумевают востребованность, а следовательно и
баг-репорты. А самим разработчикам кроме морального удовлетворения
получить полезный бэкграунд, влияющий на их ЗП.
Первый подобный опыт увенчался успехом и сейчас в основной ветке
memcached-а добавился APPEND и PREPEND
( перловый
клиент с APPEND и PREPEND пока доступен только здесь
, но скорее
всего его тоже закомитят). Также исправлена работа по unix-сокету под
FreeBSD . Всё
это сделал Максим Дунин, за что ему огромное спасибо.
Вот несколько задач, которые ждут своей реализации и дадут небольшие
полезности веб-разработчику:
- отдача nginx-ом из memcached-а сжатых ключиков. HTML хранить в
memcached-е лучше сжатым и отдавать его браузеру также сжатым, если
браузер может принять сжатый ответ и разархивированным, если браузер
не хочет сжатые ответы. По статистике большиство браузеров и половина
поисковых ботов хотят именно сжатый контент. Было бы логично хранить
контент сжатым заранее. Кроме того сжатие более ресурсоёмко, чем
разсжатие.
- доработка APPEND и PREPEND для более гибкой работы со списками.
Значение хранимого значения ключика рассматривается как список и
хочется добавлять в этот список строчки с в начало и конец, так,
чтобы не было дублирования строчек в этом списке. В частном случае
можно применять для удаления строчки из списка.
- не ожидающий ответа от memcached-а перловый клиент. Выполняя
операцию, например, удаления ключика, мы не хотим ждать ответа от
memcached, ибо нам не интересен . Поэтому соединение можно закрыть
сразу после отправки команды memcached -у , а не ждать ответа.
- delete_multi() для memcached-а и перлового клиента.
- в nginx корректно устанавливать $upstream_response_time для ответов
из memcached-а. Полезно для логирования $upstream_response_time в
аксес-лог и последующего анализа залогированных значений.
Сайт с trac-ом и листом рассылки для этого проекта будет сделан при
первой необходимости. Это дело 5-ти минут.
Если Вам интересно реализовать вышеописанное, то напишите пожалуйста
мне об этом на аську 166233339 или мыло postmaster softsearch ru .
--
С уважением,
Михаил Монашёв, SoftSearch.ru
mailto:postmaster@xxxxxxxxxxxxx
ICQ# 166233339
Без бэкапа по жизни.
