Verimli birkaç yüz twitter profilleri tweets getiriliyor ve depolamak?

2 Cevap php

Sitesi I, 150-300 insanlardan tweets getir lokal bunları saklamak ve daha sonra ön sayfada bunları listelemek için ihtiyaçlar üzerinde çalışıyorum. Profilleri gruplar halinde oturmak.

Sayfaları gösteriyor olacak

  • tarih, profiller grup, tek bir profil, arama, ya da "özne" ile son 20 tweets (veya 21-40, vb) (farklı grup tür .. sanırım ..)
  • (gösterilen geçerli arama, profillerin grup veya tek bir profilin son 300 tweets dayanan) bir canlı, bağlam bilinçli etiket bulutu
  • gösterilen sayfanın türüne bağlıdır çeşitli istatistikler (en aktif grubu maddeleri, vb.)

Biz trafik adil biraz bekliyoruz. Son, benzer bir site günde neredeyse 40K ziyaretleri doruğa ve ben önbelleğe alma sayfaları gibi statik dosyaları başlamadan önce intro sorun koştu, ve bazı özellikleri (Yanlışlıkla bazı, ..) devre dışı. Bu bir sayfa yükleme also uzun güncellenmiş olmasaydı 3-6 profillerinden son x tweets kavusacaktı gerçeği çoğunlukla neden oldu ..

Yardımcı olur bu yüzden bu yeni site ile ben neyse, tweets getirmek için cron kullanabilirsiniz. Daha az yerine boyutu daha hızlı seçtiği için optimize katılır gerekiyor bu yüzden de db biraz denormalizing olacak.

Now, main question: how do I figure out which profiles to check for new tweets in an efficient manner? Some people will be tweeting more often than others, some will tweet in bursts (this happens a lot). I want to keep the front page of the site as "current" as possible. If it comes to, say, 300 profiles, and I check 5 every minute, some tweets will only appear an hour after the fact. I can check more often (up to 20K) but want to optimize this as much as possible, both to not hit the rate limit and to not run out of resources on the local server (it hit mysql's connection limit with that other site).
Question 2: since cron only "runs" once a minute, I figure I have to check multiple profiles each minute - as stated, at least 5, possibly more. To try and spread it out over that minute I could have it sleep a few seconds between batches or even single profiles. But then if it takes longer than 60 seconds altogether, the script will run into itself. Is this a problem? If so, how can I avoid that?
Question 3: any other tips? Readmes? URLs?

2 Cevap

Ben sadece 150-300 twitter kullanıcıları için Twitter'ın streaming API with a filter kullanmak, cron kullanmak olmaz.

statuses/filter

Bir veya daha fazla filtre yüklemleri neticesinde kamu durumları döndürür. En az bir yüklem parametre, takip yerleri, veya parça belirtilmelidir. Birden çok parametre en müşteriler Akış API tek bir bağlantı kullanmanızı sağlar hangi belirtilebilir. URL uzun parametreleri yerleştirme isteği aşırı URL uzunluğu için reddedilmesine neden olabilir. Uzun URL'ler önlemek için bir POST isteği başlık parametresini kullanın.

Varsayılan erişim seviyesi 200 parça anahtar kelimeler, 400 takip kullanıcı kodları ve 10 1 derece yer kutularına kadar izin verir. Artan erişim seviyeleri izin 80,000 takip userids ("gölge" rolü), 400,000 takip userids ("birddog" rolü), 10.000 parça anahtar kelimeler ("kısıtlı track" rolü), 200.000 parça anahtar kelimeler ("ortak parça" rolü) ve 200 - 10 derecesi konum kutuları ("locRestricted" rolü). Artan parça erişim seviyeleri de akış sınırlayıcı önce durumların daha yüksek bir oranda geçmektedir.

Ben userids belirtirken, infact akarsu API gelen tüm tweet'leri olsun inanıyorum:

Kullanıcı kimliği tarafından seçilen değil, tüm akışları çıkarıldı, düşük-kaliteli kullanıcıların durumları var. Kullanıcı kimliği tarafından seçilir Sonuçları, şu anda takip yüklemi sadece sonuçları, düşük-kaliteli kullanıcıların durumları geçmesine izin verir.

Yani oran sınırlayıcı hakkında endişelenmenize gerek kalmadan, gerçek zamanlı sonuçlar almak için izin Semester. Sen sadece yeterince hızlı veri kabul edebilir emin olmak gerekir. Ama 300 kullanıcılar ile bu bir problem olmamalı.

Update - How to use the API: Ne yazık ki akış API ile oynamak için bir şans vardı hiç. Ben, ancak, (yaptığın her şey php ise evet, ben bir php gücü olmadığını biliyorum, ama, bu yapılabilir) önce php komut dosyaları daemon var.

Ben Kurulum Durumu sonra bir mesaj kuyruğuna (çiğ json) onları dökümü tüketmek için basit bir php script olur. Daha sonra durumları kapmak ve veritabanındaki koymak için mesaj kuyruğuna başka bir komut işaret ediyorum. Bu şekilde ve db bağlantı ve işlem süresi sadece akan verileri kabul engel değildir.

Görünüşe bakılırsa o phirehose bu çözümün ilk bölümünde uygun olsaydı. beanstalkd gibi bir şey ile (pheanstalk) mesaj kuyruğuna olarak çalışacak.

I http://corp.topsy.com/developers/api/ bir göz olurdu

Ben API ile oynuyorum dışında onlarla hiçbir ilişkisi yoktur. Ben api sınırı daha yüksek bir düzeyde, tam olarak ne istediğinizi size verecektir düşünüyorum.