Вебмастерское

Где-то год назад, я выдал хостинг за спасибо, какому-то челу, как и многим.

На примере этого человека можно было отлично видеть, как чел опускается все ниже и ниже. Как в реале люди выбирают неверные пути, так и в инете тоже.
Сначала он меня обманул, мои же раздачи это акции анти-сеонисты или анти-мудаки, кто в инете все только за бабки делает.

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

Таких случаев, где меня обманывали, говорили много красивых слов, чтобы только халявный хостинг получить было много.
НО вот таких, чтобы качественно пронаблюдать как человек опускается, не часто увидишь всю логическую цепочку.

Я кстати тоже говорил.

Зачастую, «бутылочным горлышком» вашего приложения является база данных, таким образом перво-наперво включаем slow query log и смотрим какой запрос у нас самый медленный, и думаем что с ним делать, если не можем вкурить проблему — зовём старших, пусть тоже повтыкают в EXPLAIN (хабр) вашего чудо-запроса.

Но, опять же ссылаясь к моему опыту, большинство проблем с БД решают правильные индексы. Легко запомнить, что индексировать следует внешние ключи, и всё что у вас в WHERE, ORDER BY, GROUP BY (список не полон, для начала – самое оно).

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

Поиск с использованием LIKE это плохо. Полнотекстовый с MyISAM уже лучше. Внешний аля Sphinx — рулит и бибикает для MySQL и PostgreSQL, инфа достоверная 100%.

Но это полбеды, проблем в БД может подкинуть и само приложение — обращение к БД в цикле/рекурсии или еще каким извращенным способом могут привносить удивительные поправки в результаты нагрузочного тестирования. Сделайте простой профайлер ваших запрос и проследите на каких страницах количество запросов начинает зашкаливать (особенно это касается типа-ORM и почти-Active Record, когда один объект = один запрос, или даже не один). Всем кто уповает на магию фреймворков, иль каких-нить gem-ов — не надейтесь, всё о чём я написал в равной степени относится к большинству языков web-программирования, г… код есть везде, он вездесущ.

Ну, а теперь о главном, нет о главной странице в 1,5 метра — дождется ли её загрузки пользователь со скоростью доступа в 256кбит? Клиентская оптимизация должна проводиться в обязательном порядке: YSlow да Page Speed вам в зубы. Да если погуглить, то даже небольшая правка htaccess для apache улучшит ситуацию:

# Enable ETag
FileETag MTime Size

# Enable Deflate
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/x-javascript

<ifModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 1 seconds"
  ExpiresByType text/html "access plus 1 seconds"
  ExpiresByType image/x-icon "access plus 2592000 seconds"
  ExpiresByType image/gif "access plus 2592000 seconds"
  ExpiresByType image/jpeg "access plus 2592000 seconds"
  ExpiresByType image/png "access plus 2592000 seconds"
  ExpiresByType text/css "access plus 604800 seconds"
  ExpiresByType text/javascript "access plus 216000 seconds"
  ExpiresByType application/x-javascript "access plus 216000 seconds"
</ifModule>

Пожмите JavaScript и CSS, да переключите jQuery на Google CDN.

anton.shevchuk.name/php/highload-optimization-for-children/

*чища свой гугл ридер в 2012, листая избранное в нем*

Если у вас есть vds какой-ниб лишний, где-ниб и у него классный ip. Ну или там повторяющиеся цифры подряд, типо xyz.qwe.asd.222 Или наоборот наиболее короткий, например не более 2х символов типо xy.yf.z.eo какой-ниб. То если меня сама контора устроит, то я легко его заберу вместе с аккаунтом. Для всяких технических хуевень пригодится мне в будущем. Пишите мне.

теперь можно регистрироваться
и имеется возможность удалять свои изображения.

update 04/2023

у кого была почта на домене @1nya.ru
yandex pdd умирает и закрывается 17 апреля 2023
hosting.show/tag/pdd.yandex.ru/

если же вам нужен ваш ящик, напишите на mail@alice2k.com и я создам вам ящик но уже с почты на собственном сервере

в прошлом году такое уже было, после того как он сменил свой дешевый лимитный шаред sweb.ru, на vds от fastvps.ru
я тогда ему писал, типо могу захостить за спасибо, как многих. но конечно же мне не поверили.

ну, пост для истории.





у меня еще есть кстати скрин, как сам домен, 26 сентября 2011 был так же похуистично не оплачен, подобным образом в прошлом году.

я тут последние дни, решил сменить один ресурс на другой. соточку доменов чужих всяких перенес, обновил движки у похуистов и блабла.
остались уже токо свои фановые, пару десятков. и тут, как на зло сломался pdd.yandex.ru и нихуя там нельзя отредактировать.
абсолютно все домены. хоть они и работают и блабла, но редактора зоны нету :)
а я уж думал седня наконец перенесу доконца все. а вот хуй из-за яндекса.

вот чисто судьба.