Все началось с того, что нам понадобилось увеличить количество пользователей на нашем аккаунте partner edition.
Количество пользователей почты росло довольно быстро. Вскоре оно дошло до лимита выданного гуглем после первого запроса. Мы начали удалять неактивные аккаунты, но вскоре неактивных почти не осталось — все удалили. И мы решили повторно запросить увеличения лимита, но то ли у них глюк какой то, то ли политика такая, одним словом не нашли как, все соотвествующие линки пропали, информацию не нашли, и мы решили обратится в тех. поддержку гугля.

Нашли линк «Связи с нами»:
www.google.com/support/a/bin/request.py?contact_type=pre_only

Пробовали с ними связаться из этой формы? Тут прежде всего требуют Customer PIN и Support PIN. Как эти данные найти? А найти их практически невозможно — в разделе помощи ни чего вразумительного, инструкция по ссылке на странице «Связи с нами» не верная (нет пинов там где они пишут), в форумах пишут какие то нерабочие посказки. Связаться с гуглем и спросить по понятным причинам невозможно.
Мы решили не отступать. И нашли эти данные. Оказывается с помощью API их можно вытащить:
code.google.com/apis/apps/admin_settings/docs/1.0/admin_settings_developers_guide_protocol.html

Прямо квест какой-то! Но на этом не закончилось.

Открываем новый новостной проект, идея вроде интересная, движок уже готов, тех. дизайн тоже. Осталось дело за малым — подпилить напильником, добавить картинок к дизайну, и счастливого плавания!

И вот тут, на последнем этапе, появляется проблемка, с которой раньше не встречались — картинки и иллюстрации. Где их брать? Данный дизайн требует массу иллюстраций (фото). Сама концепция проекта так же — иллюстрации к новостям. Конечно, нарушением авторских прав у нас в стране уже давно ни кто не занимается. Поэтому начали выбирать фотобанки. Вот, что мы нашли:

На Хабре существует огромное количество интересных и полезных, для многих из нас, статей, на тему защиты веб-сайтов от спам-ботов, новых разработок всем известной нам captcha, и т.д и т.п, разбросанных по разным блогам, написанны тонны комментариев, и мнений.

Программa на основе платы за действие прекратит свою работу в последнюю неделю августа 2008 года. Вот, что Гугль сообщает по этому вопросу пользователям Adwords:

Google не перестает работать над новыми функциями, обеспечивающими широкие возможности для пользователей. В результате недавней покупки компании DoubleClick компанией Google партнерская сеть Performics теперь является частью Google. Чтобы объединить наши предложения, бета-версия программы на основе платы за действие прекратит свою работу. Если Вы хотите продолжать рекламу на основе платы за действие, Вы можете воспользоваться одним из предложений Google на основе цены за приобретение: Оптимизатором конверсий и партнерской сетью Performics.

Подробнее об этом в справочном центре Adwords

А зря. Конечно, не настолько эффективная функция, как хотелось бы, но зачастую очень полезная, да и удобная. Теперь сиди, разбирайся с этим Performics.

Почти всегда на крупных проектах, особенно сообществах, приходится очень много кешировать данные, такие, как количество сообщений, данные пользователя, общая информация…

На наших проектах мы уже несколько лет использовали файловое кеширование. Т.е., данные каждого пользователя заносились в файл, и по мере надобности изменялись. Проблема нагрузки была всегда, особенно на БД Mysql.

Изменили файловое кеширование на кеширование Memcached. Результаты просто потрясающие. Нагрузка сошла на нет, очередь коннектов к базе данных ушла. Сайты начали работать в разы быстрее.

Почему нагрузка на Mysql уменьшилась? Мое мнение — уменьшилось количество запросов на чтение и запись на жесткий диск, от этого разгрузился Mysql. Скорость работы диска, как и загруженность диска запросами на чтение-запись, как известно, одни из параметров, которые влияют на производительность Mysql.

UPD:

Что было:
1. Около 250 000 файлов кеша.
2. Около 2ГБ занято под кеш.
3. Около ~ 30 запросов/секунду (в пике ~ 50) на чтение-запись кеша с диска.

Что стало:
1. 0 файлов кеша
2. 400 МГ выделено под memcached (срок хранения данных в кеше — неделя)
3. 0 запросов на чтение-запись кеша.