Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [php] Upload - jak zrobić to optymalnie
Forum PHP.pl > Forum > Przedszkole
PawelC
Planuję zrobić serwis z darmowy hostingiem fotek, ponieważ mam domenę i serwer z dobrymi parametrami, a wykorzystuje z tego tylko 1GB transferu na miesiąc. I moje pytanie brzmi jak najlepiej zaprojektować zaplecze takiego skryptu, tak aby było to optymalnie zrobione. Rozumież że zamiast pisać strukturanie lepiej jest napisać to obiektowo, z wykorzystaniem sterownika bazy danych + kilka innych rzeczy. Chcę to wykonać optymalnie aby bez sensu nie obciążać serwera, co może doprowadzić do jego padu, a wykorzystanie do tego OOP to już jakiś krok w dobrym kierunku. I moje pytanie brzmi jak zrobić żeby było to optymalnie wykonane, czego się przestrzegać, a co wykorzystać? Zaznaczam że serwis będzie stał bardzo długo ponieważ domene mam jeszcze ważną przez pare lat, serwer to samo, przynajmniej wykorzystam możliwości serwera. Serwer ma włączoną bibliotekę GD i wiele innych, co może się przydać do tworzenia miniatur jak ktoś będzie chciał wykorzystać uploadowaną fotkę jako avatar.

Będę wdzięczny za opinie, sugestie i wasze pomysły w szczególności od osób które miały z tym do czynienie.

P.S. Jeżeli zły działa, to przepraszam i proszę o przeniesienie do odpowiedniego działu.
Cezar708
Witam,

Jeśli to ma być "serwis z darmowy hostingiem fotek" to szybko się przekonasz, że nie kod będzie Twoim problemem.

Podobna sytuacja jest w allegro. Tam nie jest problem z wydajnością skryptów, tylko z uploadem i downloadem plików graficznych, więc szczerze mówiąc musisz logistycznie wymyślić co, który i ile dany użytkownik może wrzucać fotek. Tak, aby nie przeciążać serwera, bo przy plikach graficznych 1GB transferu to się bardzo szybko skończy.

A jeśli chodzi o kod jako taki, to wg nie warto wyważać otwartych drzwi i wg mnie lepiej użyć jakiegoś gotowego frameworka do budowy serwisu.


Powodzenia i pozdrawiam
Cezar708
PawelC
Co do tego uploadu fotek chciałem zrobić coś takiego że podczas uploadu fotki, zrobić jakieś ograniczenie na jego wielkość i dać użytkownikowi do wyboru:
- czy plik będzie wrzucony tymczasowo czyli po określonym czasie zostanie skasowany automatycznie z serwera
- czy będzie z niego cały czas korzystał jeżeli tak to w jakim celu np. avatar etc.. wtedy zostanie z niego utowrzona odpowiednia miniatura i zostanie na stałe na serwerze z możliwością jej skasowania przez usera
- wrzucenie tymczasowe i usunięcie po czasie ustalonym przez użytkownika.

Co do ograniczeń to chciałem wprowadzić maksymalny rozmiar pliku w kb, a co do ilości to dla nie zarejestrowanych maks jedna dziennie dla zarejestrowanych np 5.

Cytat
A jeśli chodzi o kod jako taki, to wg nie warto wyważać drugi raz drzwi i wg mnie lepiej użyć jakiegoś gotowego frameworka do budowy serwisu.

Co do tego się z Tobą zgadzam, tylko akurat jestem osobą która lubi uczyć się na własnych błędach, co za tym idzie zdobywać doświadczenie poprzez pisanie kodu od zera i testowanie różnych rozwiązań, czyli gotowce raczej odpadają winksmiley.jpg Choć nie zawsze idzie się bez nich obejść.
Design będzie lekki wykonany tylko w xhtml i css co odciąży z leksza serwer.
Cezar708
Cytat(ExPlOiT @ 28.04.2008, 14:36:14 ) *
Co do tego się z Tobą zgadzam, tylko akurat jestem osobą która lubi uczyć się na własnych błędach, co za tym idzie zdobywać doświadczenie poprzez pisanie kodu od zera i testowanie różnych rozwiązań, czyli gotowce raczej odpadają winksmiley.jpg Choć nie zawsze idzie się bez nich obejść.



Twoja idea jak najbardziej słuszna, można (a czasem nawet trzeba) uczyć się na własnych błędach. Pamiętaj tylko, że nauka na obcych błędach również jest bardzo dobrym rozwiązaniem. winksmiley.jpg

Poza tym, własne błędy (jakże częste) można śmiało popełniać używając gotowych frameworków. Do tego przyjdzie opanowanie tego, którego używasz... a dzięki używaniu czegoś co wszyscy używają, otwierasz sobie szersze możliwości na rynku pracy.

Podsumowując... lepiej uczyć się na czyiś błędach... więc proponuję korzystać z frameworków (które naprawdę teraz już są świetne)
PawelC
Cytat
Podsumowując... lepiej uczyć się na czyiś błędach... więc proponuję korzystać z frameworków (które naprawdę teraz już są świetne)

No ok przyjrze się temu dokładniej, a który framework byś polecił?
I wielki dzięki za dotychczasową pomoc.
mike
Cytat(ExPlOiT @ 28.04.2008, 16:49:21 ) *
No ok przyjrze się temu dokładniej, a który framework byś polecił?
Wyszukiwarka Ci nie działa?
Wątków w stylu jaki framework było już wiele.
PawelC
Cytat
Wyszukiwarka Ci nie działa?

Czasami nie działa, tylko pokazuje się biała strona i w górnym lewym rogu <? smile.gif Już znalazłem ciekawy temat o frameworkach.
MMPrime
Nie wiem z jakiego systemu plików będziesz korzystał, ale generalnie w każdym nie można dopuścić by w jednym folderze była duża ilość plików, czyli wysyłane pliki nie mogą trafiać zawsze do jednego folderu.
PawelC
Rozumiem że najlepszym rozwiązaniem jest zrobienie kilku folderów np. zostanie wrzuconych np 1000 plików do jednego folderu, i zamiast wrzucać do niego, skrypt automatycznie utworzy drugi i do niego będą szły pliki i tak cały czas, a ścieżka do pliku zostanie zapisana przykładowo do bazy.
Crozin
Cytat
Co do ograniczeń to chciałem wprowadzić maksymalny rozmiar pliku w kb, a co do ilości to dla nie zarejestrowanych maks jedna dziennie dla zarejestrowanych np 5.
Rynek hostingu obrazków jest już nieco rozbudowany. Dlaczego miałbym skłonić się do Twojego? Rejestrować tylko po to, aby dodać obrazek - nie chce mi się. Ograniczenie jednego na dobe? Odpada. Zdecydowanie wolę użyć wtedy np. imageshack'a.
Musisz jeszcze pomyśleć co zrobić, aby użytkowników przyciągnąć.

Co do optymalności - w większości wypadków OOP jest nieco wolniejsze od strukturalnego - ale o ile wygodniejsze winksmiley.jpg
bim2
Najoptymalniej to 500 plików na folder =] Testowane na foteka.pl snitch.gif
PawelC
Cytat(bim2 @ 28.04.2008, 23:12:17 ) *
Najoptymalniej to 500 plików na folder =] Testowane na foteka.pl snitch.gif

Dzięki za info smile.gif A mógłbyś mi jeszcze powiedzieć jak z zużyciem transferu?


Crozin co do tego co powiedziałeś, dało to do myślenia. Mogę zrobić bez ograniczeń, tylko wtedy będzie potrzeby spory transfer + usunięcie wymogu rejestracji, i kilka innych bajerków. Skoro już o tym rozmawiamy to powiedz co musi mieć serwis na którym byś z chęcią uploadował fortki?
Cytat
Co do optymalności - w większości wypadków OOP jest nieco wolniejsze od strukturalnego - ale o ile wygodniejsze

A ja zawsze myślałem że to OOP jest szybsze od strukturalnego i bardziej wydajne. Co do wygodności to akurat się z Tobą zgodzę, po paru dniach zabawy z OOP widać od razu wygodę w pisaniu aplikacji.
Crozin
Czego ja bym oczekiwał?
1) Możliwości wgyrania każdego formatu graficznego, tekstowego - miło by było jakby .doc, .pdf też się dało (tak aby potem ktoś mógł to odczytać w wygodnej formie)
2) Limit taki, abym go nigdy nie przekroczył jako "niedzielny użytkownik". Czyli obrazy do 2-3mb, ilość kilkanaście na dzień (chociaż ilościwoe w ogóle bym zniósł)
3) Rejestracja może co najwyżej umożliwiach zarządzenia swoimi zdjęciami - chociaż ja z czegoś takiego osobiście nie korzystam
PawelC
Każdy format pliku graficznego mam w planach smile.gif co do txt i pdf można tylko musiałbym połóżyć duży nacisk na bezpieczeństwo, żeby ktoś poprzez plik nie wrzucił jakiegoś złośliwego kodu. Co do ograniczeń na ilość fotek, kto wiem mocniejszy serwer i kłopot z głowy. I tam jak mówisz rejestracje chciałem umieścić między innymi po to aby zarządzać swoimi fotkami winksmiley.jpg
bim2
Co do transferu to nie wiem, bo akurat mi foteka jako projekt nie przypadła, ale wiem, że serwer kupiony pod fotekę to 6000gb transferu miesiecznie snitch.gif (słownie: sześćdziesiąt tysięcy)
marcio
Cytat
6000gb transferu miesiecznie snitch.gif (słownie: sześćdziesiąt tysięcy)

A napisales szesc tysiecy smile.gif

P.S zalezy o co ci chodzilo a tab btw to wydajna sa uploady w ajax??
bim2
Przepraszam, Sześćtysięcy snitch.gif

Co do zabezpiecze, poprostu imagestring('dane z pliku .txt lub pdf'); smile.gif
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.