Najvažnije pitanje je "koliko smeš da pošalješ a da ne naljutiš hosting admina" a ne "koliko može da izdrži".

Prvo vidi sa adminitratorom koliko sme, i koji ritam slanja preporučuje, kao i metod (mail(),SMTP,...),
implementacija je tek na drugom mestu.

U principu je dovoljno samo pauzama usporiti slanje i sve će proći.
Preporučujem upotrebu SMTP protokola da izbegao opterećivanje http servera,
na www.swiftmailer.org imaš free klasu koja sve to radi.

Hvala na odgovorima, @mVeliki.
Sad sam dobio podatke od klijenta kako to funkcionise na drugom njegovom sajtu, na istom serveru.
Ima oko 600 korisnika,koristi mail() funkciju,salje se po 50 mejlova(s pauzama izmedju slanja,kako on kaze).

E sad, kako napraviti pauze tokom slanja?Dakle, implementacija :)
Unapred hvala!

Evo ti jedno glupo resenje, ali pouzdano. Smesti sve mailove u tmp tabelu, posalje prvih 50, odma ih obrisi, ponudi korisniku dugme "Send next 50" pa nek klikne 5 puta, ako nema puno mail-ova, nece mu biti posebno tesko. Ili, naravno, cron, ali ako bi mogao cron da pokrenes onog trenutka ka korisnik posalje prvu turu mailova. Nisam siguran da ovo moze.

Jako je prosto odraditi pauzu. Ovako sam ja radio kod mog CoolMailer-a: U principu je jaaaako slično kao kada radiš paginaciju: Iz baze selektuješ prvih 50 mejlova i pošalješ ih, a onda podesiš meta refresh da otvara tu istu stranicu za 10ak sekundi sa parametrom mail.php?strana=2. Posle toga selektuješ od 51. do 100. adrese i šalješ mejl na te adrese.. onda ideš na ?strana=3 i tako do kraja.

Hvala svima!

Tema je stara ali i dalje aktuelna.
Molim vas da mi kažete koju php skrptu preporučujete za slanje maila kada su u pitanju sajtovi sa nekoliko hiljada članova?
Šta je dakle ono što "radi posao" a da nije suviše komplikovano?
Hvala.

http://www.google.ba/search?q=php+newsletter

phplist nije los, pogledaj i ostale

Pa ti u principu posao možeš da završiš i sa standardnom mail() funkcijom, mada je naravno preporučljivije da to bude neka naprednija biblioteka, kao što je već bezbroj puta spominjani SwiftMailer, koji nudi raznovrsne opcije za slanje email poruka, npr. batch email slanje i mnoge druge.

Ali tu nije u pitanju konkretna PHP biblioteka koja bi se koristila za te namene, već se u te svrhe preporučuje sasvim drugačija arhitektura. Npr. ako imaš case da nakon neke akcije, recimo submit-a neke forme, treba hiljadama korisnika da šalješ email-ove, i to svakom zasebno, a pritom taj sajt/aplikacija ima dosta velik load, onda će taj koji bude submit-ovao tu neku formu morati dosta da se načeka dok njegov browser ne kompletira taj zahtev. U tom slučaju je najbolje mail-ove najpre poslati u neki queue, pa da ih onda neki nezavisan proces šalje kad stigne. E sad to queue može da bude i obična tabela u bazi, pa da onda neki cron samo isčitava tu tabelu i šalje email-ove, ali uglavnom, ideja je to asinhrono slanje poruka. Postoji i jedna PEAR klasa - Mail_Queue, koja radi baš po tom principu. Naravno, još bolja (brža) varijanta su rešenja namenjena baš za ostvarivanje te queueing funkcionalnosti, kao što je Gearman, ili recimo predlog opisan na ovoj stranici, baziran na Zend Server Job Queue-u.

Trenutno postoji ograničenje, pa prilikom slanja "email all members" mail dobije samo odredjeni broj osoba (do odredjene cifre).
Preko te cifre ostali poslati mailovi se odbacuju "Messages discarded".
Hvala vam na sugestijama.
Nadam se da će još neko ko ima iskustva sa ovim sugerisati nešto efikasno i praktično.

ako mail dobije samo odredjeni broj osoba, to jest, postoji ogranicenje.

nije do skripte nego ti je provajder lupio limit.

na primer, ja kod mog provajdera imam ogranicenje na 500 mailova na sat.
inace ako ti to toliko znaci i ako ti je toliko potrebno pogledaj http://sendgrid.com/

Upravo tako,i upravo zbog toga tražim nešto bolje, jer na ovaj način mail dobije samo deo registrovanih članova, a svi ostali nemaju pojma da je išta poslato.

Ps.
Naravno, provajder mora da postavi limit da bi samog sebe zaštitio da nebi dospeo na "crnu listu" i da se nebi tretirao kao spamer, ili neko ko dozvoljava spam.

Zasto jednostavno ne postavis da umjesto mail() funkcije puni tabelu npr. mailq gdje imas rcpt-a i id content-a (iz druge tabele)

Postavis onda cron koji ce okidati po 100 ili 50 komada svakih 10 minuta.

Takvo resenje sam radio za jednu banku, gdje cak nisam imao direktan smtp pristup nego sam slao content enkodiran preko njihovog proxy na public server koji je dekodirao i slao korisnicima bez store-anja podataka.

Korišćenje mail funkcije u petlji nije preporučljivo. Zašto ne koristiš BCC?

Primer:



Dakle, uvek prvo "pripremiš" funkciju ili upit pa tek onda izvršiš van petlje. Isto tako radiš i sa UPDATE funkcijom kada označiš koji su mailovi poslati i datum slanja (pošto je preporučljivo stavljati do 50-100 maila u jednom ciklusu).
UPDATE može da izgleda ovako. Prvo izvučeš mailove korisnika iz baze gde je datum slanja manji od određenog vremena, ili ako koristiš newsletter možeš staviti ID newslettera (last_newsletter_id) i tada tražiš korisnike koji su označeni za slanje tog newslettera (vrednost 1 poslato, vrednost 0 na čekanju za slanje).
Pošalješ 50 mailova i pripremiš upit za UPDATE funkciju.