nllm

Проверьте, доставляются ли письма на сервера mail.ru и rambler. У меня была подобная проблема, оказалось, что с ip моего сервера mail.ru просто не доставлял письма. В спам они тоже не попадали, хотя в черных списках не находил айпишника.
Проблему разово можно решить сменой ip. Но если думать о будущем, то лучше изменить подход к рассылке.
Я пришел к другой схеме… С полной базы адресов \формирую рандомный новый список, чтобы каждая рассылка происходила в отличной очередности, чем прежняя. Рассылаю кроном по 1200 писем в час. Каждые 20 минут по 400 писем. В тему письма и в тело вставил имя пользователя.
Проблем больше не возникало.

Почему рынок должен быть захвачен? Рынок попилен
Я бы выбрал iOS, потому что при разработке с ней в разы меньше геморроя (кроме покупки мака или установки хакинтоша)
Или Windows Phone. Потому что есть в нём нечто необычное

На 500/503: попробуйте найти серверный корпус (на крайняк любой компьютерный корпус), наклеить на него лого сайта, поставить пару-тройку человек с зубилами/дрелями/паяльниками/любыми другими неайтишными инструментами и попросить их имитировать бурную деятельность. Эту деятельность снимите на видео и сделайте анимированную гифку буквально на 3-4 секунды, которую завершите подписью «у нас что-то сломалось, но мы чиним активно и старательно». Дополнить можно упомянутой автопроверкой, и если заработало — подменять анимированной гифкой с ликующими теми же рабочими и фразой «Ура, заработало», после чего возвращать человека на страницу. Гифку, естественно, надёжнее держать где-то на другом серваке.

На 404 можно фотку человека, заглядывающего в колодец/шахту/ущелье/что угодно ещё глубокое с припиской: «Эта страница исчезла в пучине» и ссылки на пару-тройку других, которые Вам выгодно показать.

На 403 — фотку секретного или охраняемого объекта за несколькими рядами заборов и колючей проволоки и ремаркой: «Вам сюда нельзя. Зато можно туда (...) и туда (...)». Под «туда» опять же выгодные Вам ссылки. Тематику «сюда нельзя» можно дополнить парой предложений о секретности страницы 403 и важности не попадать туда.

Если что-то из этого примете на вооружение, интересно было бы посмотреть.

" Предлагают услуги dedicated.
Пробывали VDS 4Гб памяти, 1 ядро 3.2Ггц, FreeBSD. — сайт не может проработать и 20 минут."

«99% нагрузки именно на то место, которое я указываю в вопросе.»

«Дело в том, что на одной странице в среднем подгружается 50 — 300 картинок. Один запрос на страницу = 50 — 300 запросов к apache+php.»

1. Берите VDS.
2. Переходите на Nginx с проксированием как вам говорили.
3. PROFIT! (99% нагрузки уже нет)

К сожалению, менеджеры хостинга нас ото всюду выгоняют из-за нагрузки. Предлагают услуги dedicated.
Пробывали VDS 4Гб памяти, 1 ядро 3.2Ггц, FreeBSD. — сайт не может проработать и 20 минут. Смотрим на сервере top — висит более 10 тысяч процессов httpd. На хостинге работает стабльнее, а главное — работает. Но со всех хостингов нас выгоняют вместо предложений вариантов решения проблемы.

Дело в том, что на одной странице в среднем подгружается 50 — 300 картинок. Один запрос на страницу = 50 — 300 запросов к apache+php.

Дык поставьте nginx на VDS вместо апача, не будет столько процессов плодить — раз, статику его средствами без PHP отдавать — два. Вашего тарифа за глаза хватит. Apache+php — пара процессов на каждое соединение, посчитайте что на ваших картинках получается — никаких физических серверов не хватит. Nginx'a будет несколько процессов висеть и последовательно запросы обрабатывать — и, спасибо гуглу, 2.5 Мб памяти жрать на 10к неактивных соединений. Ну а если одним nginx, что маловероятно, не обойдетесь — php-fpm за ним, дабы и пыха лишние процессы не плодила.

плюс один за гуглокалендарь, тем более и можно сделать несколько календарей и расписаний — по боксам, по мастерам и т.д.

Google Calendar можно настроить. Будет и с мобильника в т.ч. можно настроить права.

Сделайте наконец сканер, который будет показывать, как выглядит человек без одежды. Все ждут. Все будут рады. ;)

Я не пхп программер, но сделал бы так.
обернул бы каждую операцию, что хотим измерить в примерно такой код

$start = microtime(true);
 // Your code goes here.
$end = microtime(true);
 
echo 'Total script execution time: ', ($end - $start), '.';

вместо echo использовать какой-нибуть логгер. Вообщем обычный StopWatch.
Это если нужно быстрое решение, для более глубого анализа, наверняка есть хорошиие утилиты.

Смотрите как сделано в одном из самых крупных и старых магазинов цифровых товаров — plati.ru. Там при покупке файла дается ссылка, которую видит человек в своем личном кабинете, после залогинивания. Ссылка работает только для текущего пользователя и при передачи ее третьему лицу она работать не будет. Главное чтобы ваша ссылка на товар работала только для текущего, вошедшего пользователя. И совсем не обязательно ей быть временной при этом.

Электронная бухгалтерия бухгалтера не заменит. Она лишь частично автоматизирует всякую нудятину, но объем работы при этом не сильно уменьшается.

Моё дело, эльба — их основная функция документы рисовать. Для интернет-магазина это намного проще и удобнее делать средствами CMS магазина! Т.е. половина функций Вам просто не нужна. Смотреть что и когда сдавать, консультироваться можно например на клерке. Со временем наймете бухгалтера или отдадите на аутсорсинг.

Я пользуюсь «моим делом», но мне многого не хватает. Финансового модуля например. Или шаблонов документов, удобных фильтров. Несколько раз натыкался на косяки, когда по логике и законодательству надо что-то сделать, а их интерфейс это не позволяет. Электронной отчетностью пока не пользовался — но для ООО это будет более актуально. Попробуйте насколько удобны будут Вам эти системы, сколько функций востребовано будет.

Финансовый учет виду в экселе, приходится сверять с «Моим делом». Альтернатива — поставить 1С, о чем раздумываю периодически.

Я Эльбу юзаю уже год как ИП.

Достоинства — все просто, не надо самому вникать в тонкости законодательства.

Недостатки. Один раз в документах для оплаты страховых взносов проставились не те реквизиты (кажется был неверный КДК), пришлось искать самому. Еще был косяк когда Эльба мне говорила, что я могу заплатить налоги до 10 января. Я пошел 3 января и обнаружил, что ни один банк до 10 января не работает, т.к. праздники. Еще для меня недостаток это цена, мне надо в месяц создать всего лишь один акт и один счет, платить за это 400 руб дорогова-то. Поэтому сейчас я плачу только тогда когда нужно заплатить налоги.

В Эльбе на тарифе который 500 руб, еще можно консультироваться с бухгалтером.

В целом я доволен Эльбой.

Про «Мое Дело» ничего сказать не могу.

Советую ставить именно MediaWiki. Она является основой для Википедии, а это обеспечивает ей самое большое комьюнити.

К MediaWiki рекомендую поставить расширение Semantic MediaWiki
Это расширение позволяет указывать типизированные связи между страницами, и задавать странице типизированные атрибуты.

Например, на странице пользователя можно указать телефон пометив его типом телефон. Далее, используя простой запрос, на общей странице можно построить таблицу с контактами пользователей.

К Semantic MediaWiki, также есть множество расширений по форматированию данных.
Например, указав подчиненность можно также автоматически отображать OrgChart (пример)

Все в сумме и позволяет хранить не только документацию, но и знания.

Задача выбора Wiki никогда не вставала, т.к. использовалась та, что идет в комплекте с «трекером» (Trac, Redmine, etc)…

P.S. Технические проблемы с Wiki куда более проще по сравнению с организационными (когда кто-нибудь не хочет вести документацию или делает это «на оте… ись»). Поэтому берите ту, которую проще установить или с которой уже приходилось работать и не переживайте.

Все зависит от постановки задачи. Если вам нужно для бизнеса, то возьмите wordpress, в интернете масса советов по его ускорению и доточке. Прямо вот завтра у вас тысячи хитов в секунду не будет, а к тому времени, когда будет, вы доточите его до устраивающей вас производительности.

Если же just for fun, вам хочется сделать очень быстрый движок, и именно это является основной целью — только тогда есть смысл браться и писать его.

1. Используйте аналог SSI от nginx для сборки страницы из нескольких кусков. Это позволит сэкономить на записи (большая часть контента будет статична, и часто обновляться будут в основном навигационные элементы).

2. С раздачей статики великолепно справляется nginx, и упираться он будет исключительно в ширину канала и скорость дисковой подсистемы.

3. Следовательно, чтобы исключить влияние дисковой подсистемы — используйте сервер с SSD (они уже доступны), также часть, или даже весь контент можно дублировать в tmpfs.

4. Часто изменяемые данные (например список новых материалов на форуме, и т.д.) есть смысл держать в memcached. Благо nginx умеет раздавать прямо из memcached.

5. Выбор языка для разработки тут не существенен, на самом деле. А задача объемная. При этом раз вы завязываетесь на nginx со специфическими настройками — все равно «обычный хостинг» уже не подходит. А следовательно вы можете выбирать любой язык разработки, исходя из того на чем такое решение писать будет лучше. Ограничиваться PHP не обязательно.

6. Для подобных проектов главное — быстро выкатить концепт. После осознания результатов вы все равно будете вынуждены переписать 90% кода. Так что если вы знаете PHP — пишите на нем. Совмещать изучение совершенно нового языка, с продумыванием необычной архитектуры нового сервиса — тяжкая задача.

Хочу сразу все сделать правильно
Все хотят, да вот ни у кого не получается ;)

стоит ли тогда заморачиваться с выбором базы данных?
Разумеется, хранить надо в отдельной базе данных, можно и файловой. А то когда захочется шаблон html-ки поменять, будет не смешно.

Казалось бы, что может быть проще и легковеснее, чем отдавать статичные .html файлы
Собственно, ничего, поэтому для незалогиненых пользователей, которые генерируют 90% трафика, стоит использовать именно статичные .html файлы. Запросы пользователей, которым надо генерить индивидуальные странички, надо направлять на движок в обход кеша (например, по факту наличия соотв сесионной куки).

Где лучше хранить кэш с .html документами?
в соотв. documentroot, чтобы nginx мог их легко найти и отдать, прямо по запрашиваемому урлу. Крайне желательно поддерживать некоторую вложенность папок, чтобы в каждой папке было максимум несколько тысяч файлов или других папок.

Или может все хранить в тех же файлах?
Все нельзя. Только то что редко обновляется и долго остается валидным. Для короткоживущих данных лучше использовать все-таки memcached, во избежание лишней нагрузки на диск. Либо FS в памяти, если уж хочется работы с файлами. Для короткоживущих данных в php есть замечательное средство кеширования — pecl модуль APC (основное его предназначение opcode cacher, но данные он тоже может кешировать)

У работы с файловым кешем свои тонкости. Например, данные в нем менять надо атомарно, т.е. через временный файл и последующий rename(). Также желательно использовать блокировки чтобы избежать ситуации, когда несколько запросов паралельно начинают генерировать один и тот же элемент кеша. Часто нет необходимости немедленно перегенерировать элемент кеша при обновлении данных, достаточно его удалить, а генерация произойдет при запросе.

Всем спасибо, справился с помощью Сygwin.
Минуснувшим желаю чистых серваков.

Можно, нужно чтобы она была Saas и использовала на всю катушку возможности Google API как карт, переводов, видео, пикаса изображений, Гугл+ и конечноже Google Apps. Ну или нечто похожее но на площадях Amazone.

Nokia E52. Сам пользуюсь E51 — замечательный телефон. Wi-Fi, GPS, Skype, SIP, запись звонков — в общем, всё, что только может пригодиться, и ничего лишнего.
Не знаю, правда, легко ли будет найти в продаже — трубка не первой свежести. И последняя в своём роде.

У меня был HP iPAQ Voice Messenger, отличная штука была. Местами еще есть в продаже.

Адресная книга = Outlook.