Розмаїття дошок оголошень іноді вражає. На перший погляд, не завжди очевидно, що портал є дошкою оголошень. Наприклад, сайти з працевлаштування типу grc.ua (колишній hh.ua) або фрілансерські сайти, такі як kabanchik.ua, по суті є дошками оголошень. Таких прикладів можна знайти дуже багато, визначальним фактором є ідентична суть технічного ядра системи: надання майданчика для взаємодії користувачів двох типів: які створюють пропозицію та попит.
Що Важливо розуміти, плануючи розробку дошки оголошень
Якщо дошка оголошень робиться не для обмеженої аудиторії, кількість користувачів та оголошень на ній обчислюється мільйонами. Отже, потрібна технічна база, здатна справлятися з таким навантаженням та забезпечити високу швидкість роботи такого сайту.
Якщо цього не врахувати, то сайт не впорається з відвідуваністю, сильно гальмуватиме і буде дуже вразливим для DDOS-атак.
Ми маємо в своєму розпорядженні технічну базу, яка зможе справлятися з 5000 одночасних звернень до сервера без втрат швидкості на сервері середньої потужності.
Це, мабуть, найскладніше питання для власника дошки оголошень. На досвід наших спостережень, власникам часто складно утриматися від збору максимальної вигоди для себе. Так, часто дошку оголошень завішують усіма видами реклами, продають десятки закріплень у топі, що знецінюють самі себе, та інше.
У випадку з дошкою оголошень завжди є три сторони: продавець, покупець, власник майданчика. І завжди потрібно враховувати інтереси всіх сторін. Якщо одній із сторін стане не вигідно чи незручно, вона може піти. А успіх такого проекту неможливий без жодної сторони.
Вартість розробки дошки оголошень
Мінімальний обсяг робіт
Мінімальна оцінка дошки оголошень враховує роботи з проектування інтерфейсів, дизайну, верстки та програмування функціоналу для наступних типів сторінок системи:
- Глобальні налаштування системи
- Управління адміністраторами
- Керування клієнтами
- Керування категоріями (рубриками)
- Управління меню
- Керування текстовим контентом
- Модерація оголошень
- Управління системними повідомленнями
- Аналітика
- Головна сторінка
- Категорія / рубрика оголошень
- Сторінка оголошення
- Сторінка створення оголошення
- Реєстрація та авторизація
- Особистий кабінет клієнта
Переваги розробки дошки оголошень у WEB ROOM
Відгуки про нашу роботу
Процес розробки дошки оголошень
Ми вивчаємо суть проблем компанії з обігом даних та бізнес-процесами. З'ясовуємо побажання замовника. На основі цієї інформації ми пропонуємо стратегію вирішення поставлених завдань. Після узгодження стратегії ми складаємо функціональне завдання, яке включає список основних і супутніх інтерфейсів майбутньої системи обліку і коротко описуємо їх призначення. На основі функціонального завдання ми можемо приблизно передбачити вартість та терміни реалізації системи.
Після затвердження функціонального завдання підписується договір на розробку Технічного завдання (High Level).
Розробка технічного завдання для дошки оголошень включає прототипування інтерфейсів системи та опис всього функціоналу.
На підставі технічного завдання ми визначаємо вартість та терміни реалізації проекту, а також ймовірну похибку в оцінці.
Спільно із замовником визначаємо MVP (Minimum Viable Product – мінімально життєздатний продукт). Іншими словами, визначається мінімально-можливий функціонал для запуску системи. Запуск MVP дуже важливий для систем з багатомісячною реалізацією: не тільки для того, щоб якнайшвидше дати замовнику можливість окупати свої інвестиції, але іноді при тестуванні MVP стають очевидними помилки у постановці завдання розробнику, і це вимагає коригування функціонального завдання.
Розробка системи починається з розробки дизайну. Дизайнер малює частину сторінки в кількох варіантах та показує Вам. Після затвердження концепції, дизайнер домальовує одну сторінку і ще раз показує замовнику цілісний вид обраної концепції. Після затвердження малюються решта сторінок системи.
Для зниження вартості розробки дошки оголошень іноді замовники відмовляються від розробки дизайну адміністративних інтерфейсів. В цьому випадку, верстальник буде працювати не за дизайном, а за прототипом, використовуючи стандартне оформлення. Існує також проміжний варіант, коли дизайнер малює лише кілька основних інтерфейсів та елементи для інших сторінок (наприклад, іконки), а верстальник працює, використовуючи прототипи та дизайн відмальованих сторінок.
Після затвердження дизайну наші програмісти приступають до найскладнішої та найтривалішої роботи з розробки функціоналу та створення органів управління системою.
Коли система готова, ми тестуємо її та запускаємо.
Як ми робимо дошки оголошень?
Для розробки дошки оголошень ми використовуємо стандартний набір технологій WEB-розробок, а саме: PHP, MySQL, JavaScript, HTML, CSS. Це дає Вам незалежність від розробника, систему зможе підтримувати будь-який розумний WEB-програміст.
Чи варто використовувати готовий двигун для дошки оголошень?
Це залежить від цілей проекту. Якщо дошка оголошень створюється під дуже обмежену аудиторію та зі стандартним функціоналом, то використання готової системи буде правильним рішенням, але якщо у вас більш амбітні плани, то такий варіант вам не підійде.
На що варто звертати увагу при виборі готової системи?
Відкритий або закритий вихідний код
Якщо вихідний код зашифрований, доробляти систему неможливо. Майже всі готові платні системи, які продають ліцензію, мають зашифрований код. Але одні шифрують лише частину, що захищає систему від незаконного копіювання, інші шифрують все чи майже все. Це питання варто проясняти одразу.
З яким навантаженням може впоратися дошка оголошень?
Особисто я не зустрічав ще жодної «коробкової» системи будь-якого призначення, яка готова до великих навантажень. Це свого роду мас-маркет, і від нього годі чекати високих технічних показників. Однак, деякі розробники двигунів пишуть, що система готова до більших навантажень. Зокрема, на сайті одного двигуна написано наступне: «при рівномірному навантаженні дошка оголошень здатна витримати понад 50 тис. користувачів, 500 тис. сесій на день при 1,5 млн. активних оголошень».
Спробуймо розібратися, виходячи з цих даних, чи готова система до навантажень.
Для початку потрібно зрозуміти, що створює навантаження.
У нас є база даних, де зберігається 1,5 млн. оголошень, уявімо їх у вигляді архіву. Є сервер, який ми уявимо у ролі архіваріуса. І є програмний код, який ми уявимо як інструкції для архіваріуса.
Отже, відкриваючи сторінку категорії оголошень, на якій має відображатися 20 оголошень, серверу потрібно зрозуміти, які саме 20 оголошень з 1,5 млн. потрібно показати. Він бере інструкцію та починає збирати потрібний контент. Від того, наскільки якістною буде ця інструкція, залежить, скільки часу він витратить на вибір потрібного контенту. Також ми маємо обмежені можливості архіваріуса, виражені в параметрах процесора сервера. Частота процесора відповідає за швидкість роботи архіваріуса, а кількість ядер (обчислювальних потоків) – це, по суті, кількість архівірусів, які можуть паралельно обробляти кілька звернень. Тут важливо розуміти, що кілька архіваріусів не можуть допомогти швидше обробити один запит, це паралельна обробка різних запитів.
Сподіваюся, що аналогія вийшла зрозумілою, і тепер ми можемо розпочати обчислення.
Нам пишуть про 50 тис. користувачів та 500 тис. сесій на добу. Ні те, ні інше не є параметром, що говорить про навантаження. Користувач може бути цілий день відкритим сайт, але він з ним не працює. Тобто фактично він на сайті, але звернень до сервера не робить. В рамках однієї сесії (від відкриття до закриття сайту), користувач може зробити багато звернень до сервера. У цьому випадку нас цікавить кількість звернень або так званих хітів.
Нам нічого не залишається, крім як припустити, що йшлося про 500 тис. звернень. Це 5,8 звернень за секунду.
В описі зазначено, що процесор має 8 обчислювальних потоків, але не вказано частоту.
Поділимо 5,8 звернень за секунду на 8 потоків і отримаємо, що одне ядро за секунду обробляє 0,7 звернень. Тобто, середній час відповіді сервера (час обробки програмного коду, збору контенту та відправки в браузер користувача) становить 1,4 с.
Подальше погіршення ситуації відбувається досить просто. При одночасному зверненні 8 користувачів відразу в роботу включаються всі ядра і звільняться вони через 1,4 секунди. Якщо з'являється 9 запит, то він стає в чергу і дев'ятому серверу відповість вже приблизно через 2,8 секунди. Так при зростанні відвідуваності сайт починає сповільнюватися доти, доки сервер не перестає відповідати частині користувачів (видає помилку 500), або поки взагалі не «падає».
Подібний показник ми вважаємо великою проблемою, а не готовністю до навантажень. Але переглянувши очима кілька сайтів, створених на цьому движку, ми побачили сумніші показники, хоча ми не знаємо про кількість серверних ресурсів цих сайтів та їх навантаження.
Чому ми можемо бачити такі дивні та неповні описи результатів навантажувального тестування?
Ми та наші колеги схильні до проф. деформації. Іноді ми думаємо, що те, що для нас є очевидним, є очевидним для всіх і описуємо щось не повним або складним чином. Але якщо описане не зрозуміло навіть фахівцю, то, на мій погляд, це навмисне введення в оману.
Тепер про те, що ми вважаємо хорошим показником, на прикладі наших досягнень:
100 запитів на секунду (більше 8,5 млн. запитів на добу) з часом відповіді сервера близько 40 мілісекунд на віртуальному сервері вартістю 10 USD/місяць (4 ядра по 3,3 ГГц).
Так як зрозуміти, з яким навантаженням впорається система?
Вихід лише один – проводити своє навантажувальне тестування. Можна написати програму, яка згенерує потрібну кількість контенту та проведе імітацію навантаження на сервер.
Чим загрожує не з'ясування цього питання?
Ви можете займатися розвитком проекту, вкладати гроші в маркетинг, і одного разу система «ляже». Для оперативного вирішення питання Вам доведеться докуповувати серверні ресурси. І цілком можливий сценарій, що купивши готову систему за 1500 USD, Ви платитимете 3000 USD на рік за сервери.
Одного разу до нас звернувся замовник, у якого сайт почав падати від навантаження, і він уже мав максимальну конфігурацію сервера. І швидко допомогти у цій ситуації не вдасться. Пощастить, якщо сайт доведеться вимкнути на тиждень, а може, й на кілька місяців. І відповідно будуть великі втрати, як фінансові, так і репутаційні.
Ліцензійні умови
Іноді ліцензійні умови використання системи суперечать рекламним заявам.
Так, наприклад, на сайті системи може бути зазначено, що ви можете її доопрацьовувати, а за ліцензійних умов це забороняється.
Також звертайте увагу на те, чи стаєте Ви власником системи та можете розпоряджатися їй, як Вам завгодно, чи Ви отримуєте право на використання у певних рамках, а власником залишається розробник.
Відгуки
Рекомендуємо пошукати в мережі відгуки про систему. Особливо приділіть увагу відгукам про безпеку.
Одного разу до нас за доробками звернувся клієнт із дошкою оголошень, створеною на одному з найпопулярніших спеціалізованих двигунів. Розробник двигуна відмовився вести доопрацювання і у них виник конфлікт. Допомогти в тій ситуації ми не могли, оскільки 90% програмного коду було зашифровано, проте ми стали свідками цікавих подій. Зважаючи на все, у системі було безліч бекдорів (можливість отримувати контроль над системою без логінів та паролів). І щодня відбувалися скидання даних та налаштувань, а потім взагалі виявився заблокованим розділ із налаштуваннями. І ні зміна доступів, ні відновлення резервної копії не допомагали, оскільки за кілька годин все знову скидалося та блокувалося.
Окрім того, що розробник, таким чином, не давав продовжити роботу із системою, система містила персональні дані клієнтів, які вони вказували при реєстрації, і, відповідно, немає жодного договору про нерозголошення персональних даних із розробником, який несанкціоновано отримує доступ до цієї системи, що підставляє власника системи під юридичну відповідальність.
Будьте уважнішими, вибираючи технічну платформу для дошки оголошень.
Залишилися питання?
Якщо ви хочете отримати консультацію або дізнатися трохи більше про наші послуги, будь ласка, напишіть нам, і хтось із нашої команди зв'яжеться з вами найближчим часом.