У меня была небольшая служба сокращения URL-адресов, ориентированная на японский язык. Он был отключен, потому что он использовал слишком много ресурсов (процессорного времени и, возможно, памяти) на общем сервере. Это было пару лет назад, но я заинтересован в возвращении к жизни, если я могу себе это позволить.
Я планирую использовать http://tighturl.com/project/ на этот раз, и мне было интересно, сможет ли самый маленький VPS из, скажем, линода справиться с рабочей нагрузкой. Большая часть работы - это просто mod_rewrites.
Это нормально, если сайт становится медленным, но не невыносимо. Если есть интерес к проекту, я могу обновить VPS. Но правильно ли я предполагаю, что даже если VPS будет перегружен, он не отключится из-за влияния на производительность других пользователей?
Нет, Линод не отключит вас за использование ресурсов. Они просто ограничат ваш процессор вашим процентом. Если никто другой не использует их ЦП, вы также можете использовать их, пока их VPS не запросит его, так что есть вероятность, что вы почти всегда получите больше, чем ваша доля. Вы можете максимально использовать оперативную память и процессор в течение всего дня, а если ваш сайт становится медленным, просто обновите линод.
Единственное, в чем они заинтересованы, - это доступ к HD, так как это мог влиять на других, но, похоже, в вашей ситуации это не применимо.
Очень рекомендую линод.
Это действительно зависит от того, как вы пишете сайт. Я вижу, как VPS забивается. Если ваш VPS использует больше ресурсов, чем выделено, он может отключиться. Чем легче и быстрее будет ваш сервис (возможно, пользовательский бэкэнд fastcgi на C ++), тем лучше.
Как вы планируете это реализовать?
Как долго URL-адреса остаются активными?
Если вы убиваете их через X-много дней / месяцев / чего угодно, и вы получаете всего несколько сотен тысяч запросов в день, я бы ожидал, что VPS начального уровня откуда угодно справится с этим.
Лично меня больше всего беспокоит использование полосы пропускания. Я бы предпочел "безлимитную", но ограниченную по скорости услугу действительно быстрому, но "измеренному" соединению - затраты легче предсказать :)
Если это действительно простая реализация, скажем, сокращенный элемент просматривается в базе данных, и вы возвращаете перенаправление на исходный URL-адрес - вероятно, он не будет использовать много ЦП или ОЗУ - ваша единственная проблема действительно должна заключаться в хранении. Если средний URL + shortID составляет, скажем, 1 КБ, и у вас есть миллион URL-адресов, вы уже просматриваете 1 ГБ хранилища. Увеличьте объем хранилища на 1 ГБ для каждого миллиона URL-адресов и VPS начального уровня от провайдера хостинга, который я использую (http://tektonic.net) будет достигать ~ 18 миллионов записей.
Сайт сжатия URL-адресов Tinyurl. оптимизация для лучшей производительности на VPS
Многие VPS поставляются с более низким ЦП и более медленными ресурсами выгружаемой памяти по сравнению с тем, что вы можете получить в выделенном решении. Даже место на жестком диске может быть дорогостоящим. Однако вы можете попытаться улучшить C ++ или даже Perl и т. Д. Любое приложение, которое использует для этой цели справедливый алгоритм.
Вы можете подумать о лучшей оптимизации алгоритма вашей программы, а не просто попытаться получить более дорогостоящую платформу или просто переписать алгоритм на более быстром языке (однако прежний и последующий в некоторой степени помогают).
Некоторые идеи, которые вы можете рассмотреть, - это устаревание всех записей с низким рейтингом и некоторых самых старых записей. U может получить счетчик посещений, хранящийся в базе данных, однако его не рекомендуется хранить там даты, а просто удалить все совпадающие записи в текущей базе данных со снимком за несколько старых месяцев (вам не нужно хранить даты таким образом, просто удалите все совпадающие записи, которые были в старом снимке и с низким коэффициентом попадания). Кроме того, вы можете отделить старые данные и сохранить их в сильно сжатой форме «архив» - например, используя префикс для времени хранения и т. Д. U может просто обнулить старые записи, таким образом сохраняя идентификаторы, и перенести их во вторую «автономную» базу данных для оптимизации запросов.
Также рассмотрите возможность изменения алгоритма хеширования, однако это создает некоторые проблемы (например, поиск лучшего способа сжатия строк или сохранения наиболее часто используемых URL-адресов или их частей в некоторой быстрой таблице префиксов, дающей «супер» идентификаторы). практически вы можете бросить вызов (как Википедия со своим 100-мегабайтным случайным текстом) или задать вопрос здесь ;-), или провести собственное исследование, или даже оставить как есть, так как это будет работать в любом случае p;
-gl